On May 6, 12:57 pm, Thadeus Burgess <[email protected]> wrote: > 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.
yes - a nasty exception is how response.files.append( some JavaScript file) is used now... this (actually) is what started me on this revelation (that, and less directly the surprise of the positive experience I had with using ez-css for layout control of existing layout). As for architecting: here are my major realizations: - templates, more generally blocks (thanks to your recent work) have 2 characteritics: content, and position. - responsibilities for composing those two aspects is in the wrong place, as is evidenced by how some things are hard to do. Other than fixing the point of responsibility point, and making the actions naturally there to try to enable effective skinning, I have no pre-insights... I am exploring... I think more than include is needed for dynamic skin behavior (at a higher level than simply manipulating css - you can do that "micro-skinning" with js). - Yarko > > -- > 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
