Python vs PHP

[Alex Martelli]

Valentino Volonghi aka Dialtone <dialtone.##NOSPAM#$#$$#@gmail.com>
wrote:

> Max M <maxm at mxm.dk> wrote:
> > Zope Page Templates has a far better approach to this imho. Where you
> > define reusable markup in a macro.
> >
> > The box could then be defined with title and content slots like::
> >
> >      <div metal:define-macro="box">
> >          <h5><metal:block define-slot="title">The title</metal:block></h5>
> >          <metal:block define-slot="content"/>This is example 
> > content</metal:block>
> >      </div>

Hmmm, isn't this HTML malformed?  the second metal:block seems to be
self-terminated and then terminated again by a </metal:block>.  I'm
going to assume a typo (apologies if it's a ZPT feature instead).

> > This approach makes it relatively easy to reuse markup as well as logic.
> > It is possible use arbitrarily complex markups as "parameters" to the
> > slots in the template. Wich makes it very nice for larger systems.
> 
> Which with Nevow is perfectly natural since you can do:
> 
> <div nevow:render="content">
>     <nevow:slot name="content" />
> </div>
> 
> and then in the code:
> 
> def render_content(self, ctx, data):
>     ctx.tag.fillSlots('content', My_Fragment())
>     return ctx.tag

OK, but the problem is, who supplies My_Fragment, and how is said
fragment going to be parameterized.

> Just like I've done in weever (on berlios) where there is a main file that
> defines the base class for all the pages and requires a content fragment as
> argument with which it will fill the empty slot to render the whole page.
> 
> Then I subclass the main page class to give the behaviour I need, and then I
> pass the content 'page' to have it rendered in the output.

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.
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>

which expands the previously-stashed-away contents, with slot-filling.

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;-).

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).


Alex