On May 6, 12:14 pm, Thadeus Burgess <thade...@thadeusb.com> 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.
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 <mdipie...@cs.depaul.edu> 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 <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
