Python vs PHP

[Valentino Volonghi aka Dialtone]

The question then is, what are you trying to achieve with nevow's
templating? (Or maybe, what do you think is achieved?) I don't think

Cleaner templates, and sometimes to avoid disk templates at all (when they
are not needed). Nevow template is also wonderful in giving the programmer
the ability to modify and transform the DOM at will (almost).

anyone is achieving the separation of rendering logic from control or
business logic with templating -- rendering logic is too sophisticated
(in real applications) to always rely on a template. In ZPT, some logic
remains in the template; the amount of logic is flexible, and frequently
changes back and forth as the application is developed.

Why can't you put rendering logic in a python file and the template only in
the template? just allow me to modify the DOM Tree as I need to while I'm
rendering, then the final output will be what you expected. This is what
Nevow does.

Nevow has a very strong limit to how much logic can go in the page --
and that limit is very low. It's not a limit of zero, since it is more
sophisticated than something like XMLC or the DOM. But it's not
terribly high.

Nevow _CAN_ embed code in the template. and you can do that in this way:

<n:invisible n:render="python x=2**4" />

with this code in the python file:

def render_python(self, arg):
def _(self, ctx, data):
exec arg
return ctx.tag[x]
return _

I would also say that Nevow templating has all the very same features you
can find in ZPT. You just have to code them yourself, if you really really
need to.

But Nevow is cleaner than ZPT, because there is no actual reason to embed
python code in the template. If you really really need to transform the DOM
in some way you can do that from the python side.

Actually, you can do everything from the python side if you want.

is usually the case), I'm not a bottleneck. I'm not sure this is
possible in Nevow.

It is as I wrote above. Nevow templating system is _extremely_ flexible and
can be made to do almost everything you need to.

the template. To a degree that's already true. OTOH, I don't know if
it's helpful to code alternating row colors for a table in Python, when
it will be necessarily far away from the table that needs the coloring.

It is not a necessity. You can code that directly in the template:

<table nevow:data="some_data" nevow:render="sequence">
<tr nevowattern="item" class="odd">...</tr>
<tr nevowattern="item" class="even">...</tr>
</table>

Will work, as expected and will build an alternating color table, I can't
see how this is hard to understand for a designer or any not experienced
programmer.

Anyway, I'm very suspicious of any system which limits the programmer
for their own good.

Which, I would say, It clearly not Nevow.

Sry If I misunderstood something, I'm not that keen with english so...

 

[Istvan Albert]

Nevow _CAN_ embed code in the template. and you can do that in this way:

<snip>

what you showed here is basically a workaround, a way to
"trick" python that runs the templating engine into
directly executing a statement ... not a wise choice ...

Moreover why is it that the webpage is so
eager to explicitly contradict this possibility?

http://www.divmod.org/Home/Projects/Nevow/

"Nevow includes the ability to load templates off disk...
.... The attribute technique was inspired by the attributes
used by ZPT. However, no actual code may be embedded in
the HTML template"

Istvan.

 

[Valentino Volonghi aka Dialtone]

what you showed here is basically a workaround, a way to
"trick" python that runs the templating engine into
directly executing a statement ... not a wise choice ...

It's not a workaroud. It's there and you can use that. I can't see a
different way to execute code from a template without calling exec or eval.
Of course I may be wrong about this, if you can tell me how to.

ZPT does exactly the same, and Nevow provides everything for you to do it.
BUT Nevow doesn't ship with that renderer by default.

Moreover why is it that the webpage is so
eager to explicitly contradict this possibility?

http://www.divmod.org/Home/Projects/Nevow/

"Nevow includes the ability to load templates off disk...
... The attribute technique was inspired by the attributes
used by ZPT. However, no actual code may be embedded in
the HTML template"

Because you cannot do (e.g.):

<%for i in range(10): %>
<tr>blahblahblah</tr>
</%for>

But as I showed you can embed code in the tag attribute, you simply have to
write the renderer yourself, since the Nevow way is not to have code
outside of the python source file.

There is even a guy who wrote a new templating system for Nevow that can
read templates made like this IIRC:

<div> {$slot} </div>

In order to do this, you 'simply' have to provide a loader object that can
translate from your template to a Stan Tree that Nevow can use to render the
page, so, looking at this, there can even be a possibility to write a
templating engine for Nevow where you can embed code in the template.

 

[Istvan Albert]

Not sure what example you mean:

http://www.divmod.org/Home/Projects/Nevow/

data/render methods

But the point is, the logic
is in the code, Python code well out of this HTML file; the role of the
template is to provide the HTML basis, and tag where the current data
comes from, which method renders it

The render_colorful method creates a new attribute "color" that
was not specified in the template. They may have moved all python
out from HTML but surely did not move out all HTML from the
python code.

I would argue that this is not templating in the way
people use this term. Here the "color" attribute just
appears from thin air.

I stick to my opinion that every framework must allow one to bend
the rules because in real situations one cannot always choose
*the right thing*. What nevow seems to be doing is bend
them by allowing HTML to be moved into python,
or to say it more nicely, by allowing python to modify
the template document object model (DOM).

Istvan.

 

[Sridhar R]

www.nevow.com

 

[Sridhar R]

www.nevow.com

 

[Istvan Albert]

It's not a workaroud. It's there and you can use that. I can't see a
different way to execute code from a template without calling exec or eval.
ZPT does exactly the same, and Nevow provides everything for you to do it.

Directly executing parts of a template as code is a unacceptable
security hole that cannot possibly be allowed in any development
model where there are people that are not supposed to
have complete access to the entire system.

ANd I don't think that is how ZPT works. Although I only used it with Zope and
I'm not sure which one implements the proper security measures.

I would imagine that proper way to go about it would be
to create a python-like, bare-bones language and use that to
interpret the code.

But as I showed you can embed code in the tag attribute, you simply have to
write the renderer yourself, since the Nevow way is not to have code
outside of the python source file.

I think now I understand what you mean. Whatever is in the template
will treated as a string and is dealt with the method that
is associated with the tag.

best,

Istvan.

 

[Alex Martelli]

http://www.divmod.org/Home/Projects/Nevow/

data/render methods


The render_colorful method creates a new attribute "color" that
was not specified in the template. They may have moved all python
out from HTML but surely did not move out all HTML from the
python code.

Surely there is no prohibition against the Python code generating all
the HTML it wants; it doesn't even have to use any template whatsoever
if it doesn't want to, generating HTML from code is the main thrust of
stan, somewhat similarly to Quixote. It's not true that Nevow _is_
templating: Nevow _has_ templating, as one of many tools -- it just
happens to be the one tool I think should be used, given the scenarios I
explained.

I would argue that this is not templating in the way
people use this term. Here the "color" attribute just
appears from thin air.

I don't see anything contradicting the usage of "templating" in leaving
code in ultimate control of what gets output -- adding attributes is no
different from adding or removing tags. Once my nevow-using code has
gone for the templating choice, it's in fact not in "ultimate control",
in a sense, since renderers are chosen by the template; the code
controls which renderers it supplies and what exactly they do, the
template controls which renderers, out of those supplied, get used (and
with what arguments, if any -- with what DOM subtree being passed to
them, since that's exactly the template's contents -- etc).

I stick to my opinion that every framework must allow one to bend
the rules because in real situations one cannot always choose
*the right thing*. What nevow seems to be doing is bend
them by allowing HTML to be moved into python,
or to say it more nicely, by allowing python to modify
the template document object model (DOM).

Oh, it also allows Python to create HTML out of thin air, if the
programmer so wishes -- there's no constraint in Nevow to actually force
your code to use any of the templating subsystem. It's mechanism, not
policy. I think it _is_ feasible to use that mechanism to always do the
right thing, even in perfectly real situations: never emit any piece of
HTML that didn't come from templates, using renderers only to select,
reiterate, etc, the appropriately marked-up pieces. But there's no
constraint against writing a renderer that just ignores everything and
returns '<strong>pekaboo!</strong>' (direclty or via stan); just like
there is nothing in Python that stops the renderer from having a nice
'while 1: pass' right at the start, and block everything. It's simply
better to not combine the mechanisms that Python and Nevow order in ways
which make them implement such ill-advised policies, that's all.


Alex

 

[Tim Roberts]

Can someone who has use PHP before and know quite well about the
language, tell me what are the stuffs that Python offers and PHP
doesn't. A few examples will be nice. I know about the date format
problem which PHP is having but I need more examples. Thank you for
any help.

I'd like to mention one MAJOR difference that I've found in my
explorations.

As a language, PHP is quite adequate. The class structure is usable,
although not as thorough and sophisticated as Python. The run-time library
is VERY extensive (although all the names are in the root namespace), and
the online documentation is quite good.

The biggest difference, in my view, is the global archive of sample code.
There are many, many sites with sample PHP pages, snippets, and modules.
However, they are almost universally bad. Monolithic code, no modularity,
no structure, no separation of presentation and processing. No one seems
to use classes.

One could probably write a master's thesis on the reasons for this.
Perhaps it is because PHP is simple enough that it attracts inexperienced
programmers. Perhaps the early versions of the language required hacky
programming, and the early samples not moved on. I don't know exactly.

I do know that much of the sample Python code in the world represents
relatively good programming practices. Most of the PHP code I've seen most
definitely does not.

 

[Roy Smith]

The biggest difference, in my view, is the global archive of sample code.
There are many, many sites with sample PHP pages, snippets, and modules.
However, they are almost universally bad. Monolithic code, no modularity,
no structure, no separation of presentation and processing. No one seems
to use classes.

I've seen plenty of code which meets your description in all sorts of
languages; C++, Java, Perl, you name it (even Python). The classic
aphorism is "You can write Fortran in any language", but that's probably
an unfair jab at Fortran, since it's certainly as possible to write good
code in Fortran as it is to write bad code in other languages.

 

[Max M]

Surely there is no prohibition against the Python code generating all
the HTML it wants; it doesn't even have to use any template whatsoever
if it doesn't want to, generating HTML from code is the main thrust of
stan, somewhat similarly to Quixote. It's not true that Nevow _is_
templating: Nevow _has_ templating, as one of many tools -- it just
happens to be the one tool I think should be used, given the scenarios I
explained.

The main problem with most templating systems is not only that they mix
markup and code, but also that markup reuse is allmost impossible.

An illustrative example is a "box". Often seen in the and right hand
side of websites. Eg. on sites like slashdot. Basically it has a title
and some content. It usually appears many places on a site, and so is a
prime candidate for reuse.


It can be defined very simply in html like::

<div class="box">
<h5>A title</h5>
Some content.
</div>


If you want to reuse this in most teplate systems, you need to do it in
the programming language. Eg. in Python like::


def box(title, content):
return """<div class="box">
<h5>%s</h5>
%s
</div>""" % (title, content)


But now there is allready a problem. It is out of the hands of the
layouter. A programmer is needed to go in and change the markup.
Naturally this is a simple example, so a layouter would probably be able
to do it. But as the templates gets increasingly more complex, it's
going to be increasingly difficult for the layouter to do any changes.

Another thing is that you cannot call this as markup. You need to use
programming conventions::

<% box('My little Box', 'Some content in the Box with <b>bold</b>
markup')%>

This approach of reuse, while technically correct, is next to useless.
Even if there is only mildly complex markup as content in the box.

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>


Wich you can resuse like:


<div class="box" metal:use-macro="box">
<h5 metal:fill-slot="title">A Title</h5>
<metal:block fill-slot="content">Some content in the Box with
<b>bold</b> markup</metal:block>
</div>


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.


--

hilsen/regards Max M, Denmark

http://www.mxm.dk/
IT's Mad Science

 

[Valentino Volonghi aka Dialtone]

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>

[snip]

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

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.

 

[has]

The main problem with most templating systems is not only that they mix
markup and code, but also that markup reuse is allmost impossible.

[Just to add my 2c...]

These criticisms may well be true of macro-style templating systems,
but neither should be an issue for object model-based systems
(Nevow.Renderer, PyMeld, HTMLTemplate) that are properly designed.
Markup is used to construct the template object model; the code to
manipulate that model is supplied separately. And being constructed of
objects means almost by definition that the template will be reusable
in whole or in part.

An illustrative example is a "box". [...]
If you want to reuse this in most teplate systems, you need to do it in
the programming language. Eg. in Python like::


def box(title, content):
return """<div class="box">
<h5>%s</h5>
%s
</div>""" % (title, content)

Simple solution: any templating system that makes you write such
nonsense automatically warrants a trip to the bit-bucket. Honestly,
I wouldn't waste time pondering it. It's not like these problems
haven't already been solved.

Zope Page Templates has a far better approach to this imho. Where you
define reusable markup in a macro.

Better than nothing perhaps, but having to design, implement and use a
whole new macro system just to solve one particular reuse problem is a
rather expensive solution. (e.g. See GreenSpun's Tenth Rule, and take
a lesson from Lisp which solved these problems fifty years ago.) In an
object-based templating system, reusing one chunk of template in
another would take something like:

template2['box'] = template1['box']

If you also want to retain the content from template2's original 'box'
object as the ZPT macro example does, you can write yourself a
five-line generic 'merge(template1, template2, nodename)' function
that does this automatically and stick it in a reusable support
library somewhere. And all in a templating system that can be
implemented in about 350LOC with a full API shorter than this post. If
there's a benchmark for extensibility and reuse in templating systems,
that's gotta be pretty close.

Cheers

 

[Alex Martelli]

Hmmm, isn't this HTML malformed? the second metal:block seems to be

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 nattern="title">The title of this box</n:invisible>
<n:invisible nattern="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

 

[Valentino Volonghi aka Dialtone]

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 nattern="title">The title of this box</n:invisible>
<n:invisible nattern="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).

 

[Cliff Wells]

The main problem with most templating systems is not only that they mix
markup and code, but also that markup reuse is allmost impossible.

I'm not certain which templating systems you are referring to. Markup
reuse is certainly a major point for the use of these system. If the
system isn't capable of this then it isn't much of a templating
system.

An illustrative example is a "box". Often seen in the and right hand
side of websites. Eg. on sites like slashdot. Basically it has a title
and some content. It usually appears many places on a site, and so is a
prime candidate for reuse.


It can be defined very simply in html like::

<div class="box">
<h5>A title</h5>
Some content.
</div>


If you want to reuse this in most teplate systems, you need to do it in
the programming language. Eg. in Python like::


def box(title, content):
return """<div class="box">
<h5>%s</h5>
%s
</div>""" % (title, content)

Why?

Since I mentioned Smarty before, I'll give an example in that templating
system. Your example:

<div class="box">
<h5>A title</h5>
Some content.
</div>

would become the following Smarty template:

{* box.tpl *}
<div class="{$class}">
<h5>{$title}</h5>
{$content}
</div>

and the following PHP:

<?php
$smarty = new Smarty;
$smarty->assign('class', 'box');
$smarty->assign('title', 'A title');
$smarty->assign('content', 'Some content');
$smarty->display('box.tpl');
?>

Reusing this template on different pages is a simple matter of including
it in other templates:

{* page one *}
<html>
{include file="box.tpl"}
</html>

Additionally, the template itself can define variables to be passed to
the included template, if so needed:

{* page two *}
<html>
{include file="template.tpl" class="box" title="A title" content="Some
content"}
</html>

This is quite possibly *the most basic* use of Smarty (and templates in
general, IMO), so your claim that templating systems don't support this
seems quite bizarre to me.

But now there is allready a problem. It is out of the hands of the
layouter. A programmer is needed to go in and change the markup.
Naturally this is a simple example, so a layouter would probably be able
to do it. But as the templates gets increasingly more complex, it's
going to be increasingly difficult for the layouter to do any changes.

Another thing is that you cannot call this as markup. You need to use
programming conventions::

<% box('My little Box', 'Some content in the Box with <b>bold</b>
markup')%>

This approach of reuse, while technically correct, is next to useless.
Even if there is only mildly complex markup as content in the box.

For whatever "templating" system you are referring to, I'd certainly
agree this is useless. The very term "template" implies the opposite of
what you are demonstrating:

See entry 2a:
http://dictionary.reference.com/search?q=template

Regards,
Cliff

 

[Jon Perez]

Hi all,


Can someone who has use PHP before and know quite well about the
language, tell me what are the stuffs that Python offers and PHP
doesn't. A few examples will be nice. I know about the date format
problem which PHP is having but I need more examples. Thank you for
any help.

Shufen

Python is just a plain better language. I use both
PHP and Python heavily and finishing the same task in
Python takes half the time in most cases, if not less.

Unfortunately, mod_python deployment is a minute fraction
of that of mod_php, and that is why Python is way less
popular as a server-side scriptiong solution.

Doing some research on why this is so reveals some 2-3
year old posts that mention that it takes more effort to
configure mod_python for stability and security on shared
web hosts. Why? Because Python lets you do more advanced
stuff compared to PHP (specifically having to do with
importing modules) that may inadvertently or deliberately
crash the server if misused. Thus, for mod_python hosting
to be reliable, you have to give each user their own instance
of the Apache server (proxied through a central instance of
Apache).

This might, in fact, no longer be needed with the latest
mod_python, but I leave that to the mod_python experts in
this newsgroup to expound upon if so.

As a (former) PHP fan myself, I found Spyce (spyce.sf.net)
to be the closest in philosophy and ease of use to PHP and
I highly recommend it to those who want to experiment with
making the switch from PHP server-side to Python server-side.

 

[Ksenia Marasanova]

Python is just a plain better language. I use both

PHP and Python heavily and finishing the same task in
Python takes half the time in most cases, if not less.

Unfortunately, mod_python deployment is a minute fraction
of that of mod_php, and that is why Python is way less
popular as a server-side scriptiong solution.

Doing some research on why this is so reveals some 2-3
year old posts that mention that it takes more effort to
configure mod_python for stability and security on shared
web hosts.

Just my 2c:
I am using mod_scgi http://www.mems-exchange.org/software/scgi/ (with
Quixote), and this is a *very* stable solution. The application runs in
a SCGI process, which is independent of Apache. If you modify the
application code, SCGI process needs to be restarted. But Apache never
needs to be restarted, and the configuration is very-very simple:
<Location />
SCGIServer 127.0.0.1 4001
SCGIHandler On
</Location>
In this example, Apache passes all requests to SCGI application running
on port 4001.

The longest running scgi process on the server I have right now, is 6
months old... (it had to be restarted 6 months ago due to code
modification

Ksenia.

 

[Max M]

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

It was a typo. Untested code from memory.

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

Exactly. Complex markup inside complex templates is the problem.

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!),

I don't have anything bad to say about nevow, as I don't know it ;-) But
I have tried many page layout systems where complex layout in complex
layout is the problem.

--

hilsen/regards Max M, Denmark

http://www.mxm.dk/
IT's Mad Science

 

[Matt Goodall]

On Tue, 2004-10-26 at 14:27 +0200, Max M wrote:

[...]

I don't have anything bad to say about nevow, as I don't know it ;-) But
I have tried many page layout systems where complex layout in complex
layout is the problem.

I'm not sure it's been said explicitly (I should really read the whole
thread ;-)) but Nevow *embraces* the fact that the HTML sometimes needs
to be generated from code. See the nevow.stan and nevow.tags modules for
proof.

I've had a couple of occasions where my disk templates have got to the
point of being unmaintainable. Mostly, it's been trying to layout
reasonably complex, dynamically sized tabular data with col and row
spans (ick!). I moved the HTML generation into a Python module using
stan tags and the code is now readable and shorter. Personally, this is
something I try to avoid but Nevow does support it when necessary.

Note that it's very easy to create tag libraries with Nevow. That keeps
the bulk of the HTML generation in a sane place and leaves render
methods as just glue between the page and the code.

Cheers, Matt