On May 6, 12:24 pm, Yarko Tymciurak <[email protected]>
wrote:
> On May 6, 12:14 pm, Thadeus Burgess <[email protected]> wrote:
>
> > But default/index.html does choose its builder! By {{extends}} it
> > CHOOSES to be included inside of layout.
>
> I don't think that is a useful metaphor - in fact, I don't believe it
> is strictly correct: to choose to be in layout, YOU would have to
> insert the include, and the include point (what we are trying to get
> to enable).
>
> As it is, you are not in your own house, but only "visiting" the
> builders home.
> With the current layout.html, and handling of {{include}} within it,
> layout has the responsibility - which is wrong: main() should then
> call layout.html to create the view, and pass it the parameter
> (default/index) so that layout can include it (or perhaps more than
> index...) I would not want to write an app that way, because to go
> this way, I think all of the machinery would become tedious (how much
> would your controller have to know about what is involved in composing
> a view!?!!!???? --- too much like decaying to global knowledge for
> everythings --- opposite of data hiding, which is needed, natural,
> appropriate).
>
> If you buy the house from the builder, you certainly do not move into
> his house, or invite your guests to his house.
... that is, your guests come to the address of your house (default/
index.html is what main() comes to ), NOT to the model the builder
showed you (main does not go to views/layout.html)...
> You buy a _model_ that he built, represented by his house ( {{extend
> layout.html}} ), but then you move in your furniture, add your
> carpets, paint your walls, and invite your friends to dinner at
> _your_ house, to walk on _your_ carpet, and see _your_ pictures on
> _your_ walls.... of the house that has the shape of {{extend
> layout.html}}....
>
> Hope this makes sense. I am sure it is the right (and needed) way to
> go.
>
> - Yarko
>
>
>
> > It does not have to, it can extend any other template, or none at all!
> > The choice is up to the originally called template.
>
> > By {{extends}} the template decides that it will subjugate itself to
> > the object of extension.
>
> > I see we can already do everything that you are thinking out loud ?
> > --
> > Thadeus
>
> > On Thu, May 6, 2010 at 12:06 PM, mdipierro <[email protected]> wrote:
> > > 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
