Python vs PHP

[Valentino Volonghi aka Dialtone]

Alex Martelli <aleaxit at yahoo.com> wrote:
> OK, but the problem is, who supplies My_Fragment, and how is said
> fragment going to be parameterized.

My_Fragment is supplied by the programmer, with a content template from the
designer. A Fragment is Page's Superclass which doesn't implement
locateChild and Formless logic (which are not needed in a fragment). 

> Still, this doesn't let the author of the markup (only), who by
> definition is not going to touch the code, define his/her own macros.

The designer should simply provide some slots that need to be filled with a
fragment. Then, renders inside data marked tags (even if those slots are in
a fragment) inherit the same returned data, so you can parametrize the
rendered content through data passed from a directive, or through arguments
passed from url, or through instantiation.

> Nevertheless, I think you _could_, in nevow, define the renderers needed
> to let the markup-only person code, once:
>
> <div n:render="define_macro box">
>     <h5> <n:slot name="title"/> </h5>
>     <n:slot name="content"/>
> </div>
>
> which stashes away the contents and renders nothing, and then, as many
> time as desired, stuff such as:
>
> <n:invisible n:render="expand_macro box">
>     <n:invisible n:pattern="title">The title of this box</n:invisible>
>     <n:invisible n:pattern="content">
>        The title of this box, an <strong>arbitrary</strong> piece of
>        text and/or various markup.
>     </n:invisible>
> </n:invisible>

Sure, this could be used as writing a default fragment that defines its own
renders and data methods (with a template that calls those methods).

I've implemented such a thing in weever which can be found here:
http://developer.berlios.de/projects/weever/
There is only one main index page that act as a container for all the other
pages. My render_content method does something like:

def render_content(self, ctx, data):
    ctx.tag.fillSlots('content', self.content)

Where content is provided during instantiation of the page class like this:

def child_topic(self, ctx, data=None):
    return topic.Topic(data, ctnt=topic.TopicContent)

> Still, render_define_macro and render_expand_macro do not come
> predefined with nevow (at least so far).  It probably wouldn't be too
> difficult to code them, of course, but _designing_ them just right is
> both harder and more important -- I'm anything but sure that the
> architecture implied in this example-use sketch is best (the ZPT example
> leaves me far from sure it's really all that well designed, either;-).

There are at least 2 proposals for macro stuff in Nevow, and at least one
has already been implemented by Matt Goodall. But, its main purpose is not
to provide a way to include some page inside another one (which is clearly
already possible even with parametrization) but to provide a better way of
skinning a page. Of course it could be used for both :)

> This, I believe, is part of nevow not being fully mature yet; at release
> 0.3, of course, full maturity should not yet be expected, either.  ZPT
> is older and wiser.  Nevertheless, the fundamental architecture of nevow
> appears to be sound and very promising (for the templating part, at
> least; I'll reserve my opinion about the other parts!), and if the worst
> that could be said of it is that it may still lack some convenience
> predefined general-purpose renderers such as define_macro and
> expand_macro, well, that sure won't be very hard to remedy (getting such
> convenience add-ons designed right is the interesting challenge; the
> coding, with nevow's power at hand, is the easy part).

It also lacks some built-in components to make creating web pages just a
snap :), maybe also some documentation. But we are working on it. Also,
convenience renderers, if provided with a good usecase, could be included in
a nevow-extra package, maybe, (togheter with those built-in components).

-- 
Valentino Volonghi aka Dialtone
Now running FreeBSD 5.3-beta7
Blog: http://vvolonghi.blogspot.com