Yes, your version works as well, and is what I meant by "Or some
variation thereof---it depends on how far apart you want to
put these two particular bits of related logic." I agree it's
readable, it's just not particularly logical or straightforward, and I
would suggest that anybody who isn't already intimately familiar with
the issue to come up with it without a heck of a lot of head
scratching. Or, maybe it's just me.

On Feb 24, 2:14 am, Valts <[email protected]> wrote:
> Hello,
>
> I think that the working code would look like:
>
> {% block head %}
>   {{block.super}}
>   {% if need_form %}
>     {{form.media}}
>   {% endif %}
> {% endblock %}
>
> {% block content %}
>   {% if need_form %}
>     {{form.as_p}}
>   {% endif %}
> {% endblock %}
>
> IMHO it is simple enough and readable.
>
> Best regards,
> Valts.
>
> On Feb 24, 5:19 am, joep <[email protected]> wrote:
>
> > Thanks, Russ. That makes some sense. However it leads to constructs
> > like this:
>
> > {% if need_form %}
> >   {block head %}
> >     {{block.super}}
> >     {% if need_form %}
> >       {{form.media}}
> >     {% endif %}
> >   {% endblock %}
> >   {{form.as_p}}
> > {% endif %}
>
> >  (Or some variation thereof---it depends on how far apart you want to
> > put these two particular bits of related logic.)  Which I only arrived
> > at after a few hours of first figuring out why the straightforward
> > solution didn't work as expected. (And I believe--though I don't know--
> > that my expectations would be pretty commonplace). The necessity of
> > doing it this way is so counter intuitive though, that I guess it was
> > a bit frustrating.
>
> > On Feb 23, 7:24 pm, Russell Keith-Magee <[email protected]>
> > wrote:
>
> > > 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.

Reply via email to