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 <resultsinsoftw...@gmail.com>
wrote:
> On May 6, 10:59 am, Thadeus Burgess <thade...@thadeusb.com> 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
>
> > <resultsinsoftw...@gmail.com> 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
