Ok I had to to end up using a couple of lists instead of a dict.
So the following is what you are asking for?
--------------------------------------------------------
# layout.html
<h1>{{block title}}
Hello World
{{end}}</h1>
{{include}}
--------------------------------------------------------
# base.html
{{extend "layout.html"}}
<div id="content">
{{block content}}
Default Content
{{end}}
{{include}}
</div>
And I will be left over from the body
--------------------------------------------------------
# index.html
{{extend 'body.html'}}
{{block title}}
<a href="#"> {{super}} </a>
{{end}}
{{block content}}
I will get included inside the content div.
{{end}}
I am left over from index
--------------------------------------------------------
So you end up with something a little like this....
<h1><a href="#">Hello World</a></h1>
<div content>
I will get included inside the content div.
I am left over from index
</div>
I am left over from body
--
Thadeus
On Wed, May 5, 2010 at 11:45 PM, mdipierro <[email protected]> wrote:
> wow. what else can I say. wow.
>
> On May 5, 10:45 pm, Thadeus Burgess <[email protected]> wrote:
>> Yarko, I am done. No overhead, just an extra dictionary with pointers in
>> memory.
>>
>> Yes you can have nested blocks.
>>
>> --
>> Thadeus
>>
>> On Wed, May 5, 2010 at 10:43 PM, Yarko Tymciurak
>>
>> <[email protected]> wrote:
>> > I've said I think a lot of things will get easier, I think I see a
>> > fundamental (structure of responsibility) problem, and believe solving
>> > it will generate beneficial impact....
>>
>> > But this is experimentation, just a concept. Lets not worry too much
>> > about a realease, performance - it might not be worth worrying about
>> > yet -
>>
>> > If we get _some_ minimal working concept, we can start playing around
>> > (even if it's dog slow) to see if any of my expectations will hold
>> > up: if skinning gets easier, and more than one person can see that,
>> > THEN it will be worth worrying about this more, how to implement,
>> > performance, etc.
>>
>> > Now, lets try a concept - simply.
>>
>> > Thank you, thank you, thank you for all of you thinking about it this
>> > much, especially after just making a significant (and important)
>> > change. Hopefully, this will just amplify the changes you already
>> > made!
>>
>> > Kind regards,
>> > - Yarko
>>
>> > On May 5, 10:33 pm, Yarko Tymciurak <[email protected]>
>> > wrote:
>> >> On May 5, 10:14 pm, Thadeus Burgess <[email protected]> wrote:
>>
>> >> > I can't really say, we need some tests to analyze the effects of this.
>>
>> >> > I am thinking of a way that might not include any extra overhead at all.
>>
>> >> Yep - then you are on the right track; I predict it will be no
>> >> worse, or possibly faster... (some other things may simplify)
>>
>> >> The real benefit (I am hoping) will be opening the door to skinning;
>> >> we always thought "it should be easy", keep looking at sites that have
>> >> skins - get them, adapt them... sure, we can use them, but getting
>> >> them as useful design elements (i.e. being able to have them be _just
>> >> like we want them_) , especially by program, has been a little more
>> >> elusive.
>>
>> >> I am confident this will break some blocks to that., although I am not
>> >> sure how far, I am sure it's in the right direction.
>>
>> >> - Yarko
>>
>> >> > --
>> >> > Thadeus
>>
>> >> > On Wed, May 5, 2010 at 10:02 PM, mdipierro <[email protected]>
>> >> > wrote:
>> >> > > Before you go and implement this can you assess if this will affect
>> >> > > the speed of template processing?
>>
>> >> > > On May 5, 9:57 pm, Thadeus Burgess <[email protected]> wrote:
>> >> > >> It might be possible for the parent to look into its children, and
>> >> > >> analyze the child blocks, and if a block in the child contains a
>> >> > >> {{super <me>}} it can then take its own value and replace it into the
>> >> > >> {{super me}}.
>>
>> >> > >> --
>> >> > >> Thadeus
>>
>> >> > >> On Wed, May 5, 2010 at 9:56 PM, Thadeus Burgess
>> >> > >> <[email protected]> wrote:
>> >> > >> > Right.
>>
>> >> > >> > As much as I would like the functionality... This cannot be done as
>> >> > >> > the system stands. Child templates know nothing of their parent,
>> >> > >> > therefore they are unable to request anything from the parent
>> >> > >> > template.
>>
>> >> > >> > The way that you effectively override a block is by effort of the
>> >> > >> > parent looking at all its children and going "Hey, you have the
>> >> > >> > same
>> >> > >> > block I do, so I will use yours".
>>
>> >> > >> > So the way to do this, is for the child to know about its parent,
>> >> > >> > and
>> >> > >> > its parents parents, and parents parents parents (etc, depending on
>> >> > >> > the level of hierarchy.) The issue is, how does this element then
>> >> > >> > determine which parent it should pull from, assuming the
>> >> > >> > grandparent
>> >> > >> > defines a block, and the parent overrides the block, what is left
>> >> > >> > is
>> >> > >> > not what is intended.
>>
>> >> > >> > --
>> >> > >> > Thadeus
>>
>> >> > >> > On Wed, May 5, 2010 at 8:28 PM, Yarko Tymciurak
>> >> > >> > <[email protected]> wrote:
>> >> > >> >> nyway, I don't know what the right syntax / implementation
>> >> > >> >> (exactly)
>> >> > >> >> of a template "super" function is - I just know it makes sense,
>> >> > >> >> and I
>> >> > >> >> think we should have it (I am certainly investing a lot of effort
>> >> > >> >> in
>> >> > >> >> driving exploration of how it would work, look, and w
>
