I am not familiar with plone but in general we have to make some
choices about programming models.
Some are push, some are pull. From wikipedia
"""
Most MVC frameworks follow a push-based architecture. These frameworks
use actions that do the required processing, and then "push" the data
to the view layer to render the results.[3] Struts, Django, Ruby on
Rails and Spring MVC are good examples of this architecture. An
alternative to this is pull-based architecture, sometimes also called
"component-based". These frameworks start with the view layer, which
can then "pull" results from multiple controllers as needed. In this
architecture, multiple controllers can be involved with a single view.
Struts2, Tapestry, JBoss Seam, Wicket and Stripes are examples of pull-
based architectures.
"""
They are not compatible.
web2py is Push but has the ability to do pull via {{=LOAD....}}}.
{{block...}} implements some of the pull functionality in a push
framework. Fine. But it should be used too much and in particular it
should not be used as a shortcut, as a a replacement for {{=LOAD}}
else it will make apps less modular.
Massimo
On May 6, 12:23 pm, Russ Ferriday <[email protected]> wrote:
> 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 <[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
>
> Russ Ferriday - Topia Systems - Open Source content management with Plone and
> Zope
> [email protected] - mobile: +1 805 234 6915 - skype: ferriday
