Re: nested block definitions

2009-09-21 Thread Brian Neal

On Sep 21, 10:37 am, Daniel Roseman  wrote:
>
> Anything in a child template that is outside of a
> {% block %} is ignored.
>

I usually have a few {% load %} tags in child templates above {% block
%} to bring in needed template tags.

BN
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---



Re: nested block definitions

2009-09-21 Thread Michael Feingold

> No, you are correct. Anything in a child template that is outside of a
> {% block %} is ignored

What about inside a {% block %}? Is it allowed to define an "override"
inside another block. In other words would wrapping the offending
construct in another block like in:

=== Derived Template ===
{%extends "Base Template" %)
<%block newblock%}
{% for i in list %}
{% block a %}
current value={{i}}
{% endblock %}
{% endfor %}
{% endblock %}
==
make it valid? I guess not, am I right?

To summarize, the {% extends %} can only consist of overriding blocks
- no new ones, and inside those, nested blocks are only allowed to
define new blocks - no override definitions. Would you agree?



On Sep 21, 10:37 am, Daniel Roseman  wrote:
> On Sep 21, 4:25 pm, Michael Feingold  wrote:
>
>
>
>
>
> > I am somewhat confused about the semantics for nested block
> > definitions.Let me explain:
> > {% block %} tag serves two purposes a) define a hole (along with the
> > default value) to be filled later and b) define the content to replace
> > the current value of the hole.
>
> > As long as we are talking about a) I perfectly understand and have no
> > problems with the block tag being nested inside any other tag -
> > including for, if, and block itself - anything. If a new value is
> > supplied for the block it just placed there instead of whatever is
> > already there.
>
> > Now with b) I am lost. For example, what is the meaning of this:
>
> > === Base Template ===
> > ...
> > {% block a %}
> > ...
> > {% endblock %}
> > ...
>
> > === Derived Template ===
> > {%extends "Base Template" %)
> > {% for i in list %}
> > {% block a %}
> > current value={{i}}
> > {% endblock %}
> > {% endfor %}
>
> > =
>
> > What value will be placed in the result? is this even a valid
> > construction?
>
> > It seems to me that the block tags defining the replacement values
> > should only be allowed on the top level of the template definition. In
> > other words the derived template from the above example should not be
> > considered a valid template.
> > Am I missing something here?
>
> No, you are correct. Anything in a child template that is outside of a
> {% block %} is ignored. Your derived template is not valid - it may
> not actually raise an error, but its behaviour is undefined.
> --
> DR.- Hide quoted text -
>
> - Show quoted text -
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---



Re: nested block definitions

2009-09-21 Thread Karen Tracey
On Mon, Sep 21, 2009 at 11:25 AM, Michael Feingold wrote:

>
> I am somewhat confused about the semantics for nested block
> definitions.Let me explain:
> {% block %} tag serves two purposes a) define a hole (along with the
> default value) to be filled later and b) define the content to replace
> the current value of the hole.
>
> As long as we are talking about a) I perfectly understand and have no
> problems with the block tag being nested inside any other tag -
> including for, if, and block itself - anything. If a new value is
> supplied for the block it just placed there instead of whatever is
> already there.
>
> Now with b) I am lost. For example, what is the meaning of this:
>
> === Base Template ===
> ...
> {% block a %}
> ...
> {% endblock %}
> ...
>
> === Derived Template ===
> {%extends "Base Template" %)
> {% for i in list %}
> {% block a %}
> current value={{i}}
> {% endblock %}
> {% endfor %}
>
> =
>
> What value will be placed in the result?


What happened when you tried it?  What I'd expect would be that you'd get an
"a" block placed in the proper spot in the parent template that contains:

current value=

The {% for %} and {% endfor %} appear outside of a {% block %} tag in the
child template, so they are for all intents and purposes not there.  Well,
they are there (you'll get a template syntax error, for example, if you
leave off the {% endfor %}) but they have no place to go in the parent
template.  Only the text contained in the {% block a %} from the child
template is placed in the parent template, and that text does not contain
anything that assigns a value to i, so unless i has a value from some other
assignment (for example if it is in the base context for rendering), there
will be no value found to render for {{i}} from the child template.


is this even a valid
> construction?
>
>
It won't be reported as an error but anything outside of a {% block %} tag
in a child template is usually a mistake.  I don't know enough about the
template engine to comment on why such stuff isn't reported as an error.
There may be a good reason for it, I don't know.

 Karen

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---



Re: nested block definitions

2009-09-21 Thread Daniel Roseman

On Sep 21, 4:25 pm, Michael Feingold  wrote:
> I am somewhat confused about the semantics for nested block
> definitions.Let me explain:
> {% block %} tag serves two purposes a) define a hole (along with the
> default value) to be filled later and b) define the content to replace
> the current value of the hole.
>
> As long as we are talking about a) I perfectly understand and have no
> problems with the block tag being nested inside any other tag -
> including for, if, and block itself - anything. If a new value is
> supplied for the block it just placed there instead of whatever is
> already there.
>
> Now with b) I am lost. For example, what is the meaning of this:
>
> === Base Template ===
> ...
> {% block a %}
> ...
> {% endblock %}
> ...
>
> === Derived Template ===
> {%extends "Base Template" %)
> {% for i in list %}
> {% block a %}
> current value={{i}}
> {% endblock %}
> {% endfor %}
>
> =
>
> What value will be placed in the result? is this even a valid
> construction?
>
> It seems to me that the block tags defining the replacement values
> should only be allowed on the top level of the template definition. In
> other words the derived template from the above example should not be
> considered a valid template.
> Am I missing something here?

No, you are correct. Anything in a child template that is outside of a
{% block %} is ignored. Your derived template is not valid - it may
not actually raise an error, but its behaviour is undefined.
--
DR.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---