On Wed, Feb 24, 2010 at 2:53 AM, joep <[email protected]> wrote:
> This is in regard to this ticket, http://code.djangoproject.com/ticket/10975,
> which states, in response to the user's complaint, that 'A block
> cannot be defined conditionally within any sort of "if" construct, and
> this is by design; the structure of the template is the structure of
> the template. '
>
> I fail to see the logic here. To give an example of what I was trying
> to do, before I stumbled across this, is that I have a form with
> several widgets, each of which has media (css and js) attached. I
> include the form conditionally, which means I only also want to
> include the media in the 'header' block conditionally. What is the
> rationale for not
> allowing conditional blocks?
Think of it in terms of operator priority.
You're thinking of {% block %} as having the same priority as {% if
%}. It doesn't - {% block %} has a higher priority. In the same way
that 1 + 2 * 3 is 7, not 9, {% block %} is evaluated before {% if %}.
This is what James is driving at when he says "the structure of the
template is the structure of the template". In terms of the parsing
process, the {% block %} structure defines which files need to be
loaded, and which parts need to be overwritten. Once you have a single
template "page" loaded, you can evaluate the logic in that page - the
{% if %} and other tags that represent the page logic.
Yours,
Russ Magee %-)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
