Yarko, I just remind you my attention span is 5 lines top. ;-) Good that Thadeus seems to be able to read further down.
On May 6, 12:02 pm, Yarko Tymciurak <[email protected]> wrote: > 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
