I think Massimo is right, and now I "think" I understand what you are wanting?
You want the called view to be able to get all of the information it
wants from anywhere (ie: pull)
You can almost do this with the effect of the right functions and inclusions.
I do this at times, I declare a functions.html which contains common
code that I want my views to use, ie: functions.html contains a
template for a sub-navbar, a pagination of pages, etc... So all that
is needed is to {{include functions.html}} and I can then call the
functions defined in that file where they should go. I am not the
architect.
--
Thadeus
On Thu, May 6, 2010 at 12:35 PM, mdipierro <[email protected]> wrote:
> 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
>
