mmmmm......no.... this does not follow the rule that child, that is
progeny, or further down the timeline
is the last to affect output.
It did bring up some issues, and made me think about a few more
things.
I'm still thinking out loud. Here's where I think this is now.
I still need to think about this some more.
1. This makes it clear that to follow the new output rule, there must
be (and it is reasonable for there to be) an implicit block around the
entire content of each template file. It seems reasonable to call
that block the same as the file-name, for discussion here.
That solves your "left over" output examples, none of which were
explicit or intentional (unless we insist that all content must be in
a named block - and in effect, we have; I just make the outer
containing block of every template file implicit.
2. I'm thinking of this flow of events something like this:
main collects parameters, and gets a template - normally named "as"
the controller, so that's the "head" - the primary responsibility
point for assembling all the template stuff. If default/index.html
weren't the "boss" for collecting the output for default/index, why
would default/index controller "assigned" that to him? If "layout"
is going to act as boss, then main() should have called layout, with a
"modifier" - parameter - of [default/index], then layout can decide
how to modify itself based on this parameter, and decide what it will
or won't do - then layout has been handed responsibility for
collecting the template stuff, and should have it.
But it doesn't have it. So it shouldn't take it. This is an in-
congruency in the system that is killing this aspect of the system,
and what I am intent on sorting out.
Now that it is clear, and we all agree that default/index was called
from templates, so default/index has clearly been assigned the
responsibility of putting the template stuff together to send to the
"customer", so let's let him do it.
If I treat index as if a function, then I think something like this
(parsing index.html):
tokens: [ all the blocks, their values; where there is more than
one, that token has a "stack", i.e.:
{ body: [ index.body.stuff, base.body.stuff, layout.body.stuff ] }
when I want "body", I grab token['body'][0] --- that's the top of
the body token stack;
if I want {{super body}}, I would grab token['body'][1]
Ok - back to the story:
I have tokens I collect.
And I have output sequence I collect. It sort of looks like this:
output[i++] = { token : index } ... where the index is always 0, or
(for a super, its 1)
I scan the template - default/index.html, opening the extended and
included files as they come.
As I scan, I build the output tree and building the output token
representations.
When the tree is all collected (I've reached the end of the file), I
emit the current tokens, as directed by the tree I built.
----- That is what I had in mind.
That means {{extend}} are blocks, and have ends. The "boss" (index,
in this case) can assign a new value to a token, and emit it inside
the parent's stream.
I have to think about this some more. Right now, I can think of a
few ambiguities that are still dangling:
Here's the setup:
If an {{extend}} is a block, where is the output of anything inserted
within _that_ block? I think everything from the parent is at the
beginning if it's an implicit block, except the last "outer block"
chunk - which is at the end. So, Thadeus' "and I will be left over"
pieces happen at the end of the {{extend} block.
Ok - so that leaves these situations (and these obvious solutions):
by what mechanism can index honor the parent's positional location of
a block (remember - there are two parts: location in the tree, and
value of the block-token), i.e. redefine, but NOT reposition; or
honor the value, but override the location; we can already "wrap" the
value, while altering the output location, so the last piece left is
to wrap the value without altering the location.
Here are these three:
Location-only modification:
-1- {{&block name}} (reminsicent of C's "address of", to suggest
"this location ....
This block would insert it's location in the emit tree; it would
not alter the token's value
It would probably make sense to not have an {{end}} for this
occurrence.
Let's call having an {{end}} fore this an error!
Value-only modification:
-2- {{$block name}} (reminiscent of shell notation to emit value)
This block would alter the token for this block, but would not
alter the token's position on the emit tree.
This block would require and {{end}}
I have to think about this one, but think it is needed...
-3- {...@block name}} - this is the last uncovered case (reminiscent of
pythons wrapper notation)
This block would alter the value of the token for this block,
but would not alter the token's position on the emit tree.
While syntactically not required, stylistically, this token
belongs inside the {{extend}} block
I'm still thinkng out loud, but this is feeling like the concept is
solidifying.
On May 6, 12:22 am, Thadeus Burgess <[email protected]> wrote:
> 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}} #<== Deprecated; do not use in new code;
# since child (not parent) decides where this
goes, this is
# equiv. too: {{ block parent_include}}{{end
parent_include}}
>
> --------------------------------------------------------
> # base.html
>
> {{extend "layout.html"}}
{{end }} # <==need to add this; layout inserted here
>
> <div id="content">
> {{block content}}
> Default Content
> {{end}}
>
> {{include}} <== deprecated; see above comments;
> </div>
# NO: this will be output with the outer, implicit block
#
> And I will be left over from the body
>
> --------------------------------------------------------
> # index.html
>
> {{extend 'body.html'}} # inherit all of body's blocks;
{{ end }} # <== need to add this
>
> {{$block title}} <== if you don't want to move output point, add "$"
# ==> ERROR: unnamed block, SUPER;
# ==> MUST be reference to the first parent block on the stack
# prior to self, with name "name", e.g.:
# {{ super title}}, or {{ super menu }}
> <a href="#"> {{super}} </a>
> {{end}}
>
> {{$block content}} <== if you don't want to move output point, add "$"
> I will get included inside the content div.
> {{end}}
>
## NO ==> you are discarding my main point:
# that responsibility for shaping and emitting final output is the
template that was called (NOT the parent's)
## SO - this is the last line of all the output:
> I am left over from index
> --------------------------------------------------------
# ... not quite:
>
> So you end up with something a little like this....
>
# first, extend gets inserted to the front of index, like this:
> <h1><a href="#">Hello World</a></h1>
>
> <div id="content">
> I will get included inside the content div.
>
# the order of these should be like so:
</div>
I am left over from body
> I am left over from index
>
Yeah - that's pretty much it; I'm still thinking out loud.
>
> --
> 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
