Russell Keith-Magee wrote:
> > 1. In the Python code, how can I access various Meta properties of a
> > model (e.g. verbose_name, etc). At the moment, I do it via
> > model._meta.verbose_name, but I always get chills down my spine when I
> > access properties beginning with a single underscore. Is there a
> > "proper" way?
>
> Yes - you pass the data you want in the context as a normal context variable.
I must have been unclear: The two questions are unrelated. I want to
know how to access the verbose_name for a model within the Python
code, not the template.
I have a function that takes in a model, and I want to get that
model's verbose_name (or plural, or some other Meta property). Is
there a way to do this other than model._meta.verbose_name?
> > 2. Can someone explain the rationale behind not allowing access to
> > properties of objects that begin with double underscores in the
> > template? It worked in 1.02, but with SVN I can't access anything like
> > object.__class__. I'm merely curious as to why this was restricted. In
> > one or two cases, life was easier for me when I could do it.
>
> To the best of my knowledge, you have _never_ been able to access
> 'protected and private' attributes(i.e., attributes starting with _)
> in a template. Are you certain you were able to do this in the past?
Yes. In fact, I only discovered that this was a problem when I
switched to the subversion from 1.02 recently and had the site fail to
work. It has been working fine on Webfaction's 1.02 for more than a
month with me accessing a protected variable (double underscore, I
believe).
Hmm...Tried it for another object, and it isn't working as well with
1.02. I'm 100% sure it worked for something else I was doing - but I
don't want to go through the trouble of duplicating it because I
changed quite a bit of the system to get it working with subversion
and it's probably not worth the bother. Probably an obscure bug.
> If this is true, it would be a major backwards incompatibility, and
> one that we will need to fix. However, I'm not aware of any changes
> that have been made to the template system since v1.0 was released -
> certainly none that would make this change.
Oh what the heck. Looked through my logs and managed to duplicate:
You're right, stuff like {{ object.__str__ }} doesn't work in either.
However, in 1.02, the following works:
{% ifequal object.__str__ some_string %}
<p>Look ma! It works!
{% endifequal %}
whereas I get an exception in subversion. I don't know if that's just
for ifequal or whether it'll occur with {% if %} and others, as well.
(And I don't recall whether the match actually worked or not - but
that's another story).
Since it fails under SVN, I'm assuming it was caught and fixed. I
haven't looked at the Incompatibility list to see if it's there.
Anyway, though, what's the rationale for not allowing double
underscored properties? I know single underscores are considered poor
practice, but I don't recall that accessing the double underscore
properties as being discouraged. After all, people do it all the time
in Python, and I'm sure Django's source makes heavy use of it...
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
