On May 6, 10:59 am, Thadeus Burgess <[email protected]> wrote:
> Ok. But the purpose of layout.html is to define the "layout". It is
> effectively the parent who pays for the house and determines what room
> the child gets.
I think that is the wrong metaphor:
When you are handed the keys (called by main()), it is your house.
The layout is by the architect / builder (in this case, the app says
here's my model for a view.... )
You pick the model, and decorate it as you want; even add bedrooms
etc. - skin it.
I think that is a more appropriate metaphor...
In any case, responsibility is the key anchor here: who is
responsible for collecting the view (decorating the house, if you
will) --- who got "called" by main? not layout ---- default/index;
if there were no default/index, main would have asked the "generic
standin" to take responsibility for generating this view: generic
(which, as it is in the default app, is given the "architect", the
helper in this construction, of layout - but _your_ app could pick
another file name as the builder - get it? you could even change
builders during construction --- i.e. customize views by extending a
different file; then enhance / decorate that particular view with
minor tweaks.
Does this make more sense? The "layout == parent" metaphor I don't
think is the correct one; the "responsibility lies with who was called
- they pick the builder (i.e. the {{extends}}) is more to the point.
>
> I don't think I am quite fully grasping the concept that you have.
> Could you provide me with a code example of how you would like it to
> look, and I hope that will give me a better idea of what you are
> thinking about.
I am certain of this: the metaphors, the structures, and the
orthogonality of operations and behaviors likely to be needed (what
should be in the mix)....
I am less clear on the code, because - Thadeus - as you ask questions,
and I try to answer, I realize issues.
For example, the concepts of $block, @block, &block I am fairly
certain are needed concepts; I am less certain about the notation
( $block particularly)...
Given the excellent suggestions you've made in response to my
"thinking out loud", I would ask you how you would like to write the
code.
I like (for example) block.super notation.
Have a look at the named tuple library, and see if you were to use
that (I'm not necessarily suggesting you do - but try it, for the
suggestion of notations that could be used). If you could actually
use the notation directly (i.e. from a named.tuple object) of
block.* to just give back the argument of that {{block.something
pair}}, how would you name:
- block.super ?
- block.position (change the address of the block in the tree, not
it's content)
- block.contents (override the value of a block, but not it's current
position in the tree)
- block.decorate (ammend the value of a block, but only decorate it's
value; do not change it's current position)
This suggests at least one more useful idiom:
- block.exists (only do the enclosed if the named block exists)
...i.e. don't decorate something if the user preferences said "I don't
want to display my calendar"; but if it is there, apply the colors to
it.
Now that I've written this, I like this notation, the look of it.
........
NOW I am starting to see skins, and dynamic ones. It will be up to
the application programmer to pick the right time to change builders
to most easily achieve results:
i.e. who will I extend?
and with the easy-css layout style content way of gross positioning of
major page pieces, how will I extend?
and with this: how will I "paint my house" ---- i.e., you will not
want to do too much in trying to layout the page from within, say, an
index file ---- but with this, you will have all the control you need
to go as far as you think is useful for you dynamically, before it
would just be simpler to change your extend file.
I like this.
But I also think it is experimental - and once we have a prototype
that will render something, we will need to gain some experience -
play around with it (obviously, I will want to - I am very interested
to see how this will affect ability of an app to apply skinning... but
I'll look at basics, and stuff under the covers; others will need to
play / try too).
- Yarko
>
> --
> Thadeus
>
> On Thu, May 6, 2010 at 2:45 AM, Yarko Tymciurak
>
> <[email protected]> wrote:
> > 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
