I can't get deep into this discussion at the moment, but I would like to refer
you to Zope and Plone, and their TAL, and METAL Template Attribute Languages.
Plone is a CMS and, in general, a url causes traversal to a piece of content.
Based on the type of that content, a template is invoked for the center of the
page. Then progressively templates are invoked for containing elements, and
finally the page body. Normally a default template becomes the page wrapper,
but it's easy to switch which wrapper is used at any level, so that events
might appear in a different layout from documents, for example.
Anyway, I offer this as food for thought.
Best wishes,
--r.
On May 6, 2010, at 10:02 AM, Yarko Tymciurak 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
Russ Ferriday - Topia Systems - Open Source content management with Plone and
Zope
ru...@topia.com - mobile: +1 805 234 6915 - skype: ferriday
