Python vs PHP

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

s4046441@student.uq.edu.au (Shufen) writes:
[color=blue]
> 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.[/color]

imho php is more to compare with template engines (like cheetah...)
than python himself.

--
Wilk - http://flibuste.net

On Thu, 2004-10-21 at 23:03 -0700, Shufen wrote:[color=blue]
> 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.[/color]

PHP and Python are both very dynamic languages. I've used both pretty
heavily (although Python far more) and I'll make these observations:

On paper, PHP is pretty good. In real life, the interpreter is badly
broken in many ways. Much of this is supposedly fixed in PHP5 with the
new Zend engine, but that remains to be seen. The object model in PHP4
barely works. It doesn't support chained references (i.e. a->b->c
doesn't work) or doing things like utilizing the return value of an
expression or function call unless it's been assigned to a temporary
variable (i.e. a function foo() returning an array can't be used thusly
foo()[0]. Whether or not this is a bad thing is arguable, I'm merely
demonstrating the language's lack of a feature, or rather, lack of
generality).

PHP has some excellent libraries for web development. In many ways this
makes up for the shortcomings in the language itself, since you can
quite often keep actual programming to a minumum. I've seen nothing in
the Python world that compares to Smarty templates (and yes, I've
reviewed the many Python templating engines available. To date I've
seen none that approach Smarty in actual
usability/readability/simplicity).

Outside of web development PHP makes little sense. One of the silliest
abominations I've ever encountered is PL/PHP, a procedural language for
PostgreSQL. The only thing arguably worse is PL/Perl. (Note: Luckily we
have PL/Python available <wink>).

Python, on the other hand, is a remarkable general purpose language (of
course you shouldn't be surprised to hear that here). If PHP is the
best language for the web (due to its tight integration with the server
and its specialized libaries), then Python is the best language for
everything else, and a close second for best language for the web (and
I'm sure you'll hear arguments that it's the best in that category as
well).

If you are strictly doing web development and are familiar with PHP,
then I feel you have nothing to lose (aside from gaining some broader
experience) with sticking with PHP. If you plan to do anything else,
don't even consider it. Use Python or some other general-purpose
language.

Regards,
Cliff

--
Cliff Wells <clifford.wells@comcast.net>

Cliff Wells wrote:
[color=blue]
> PHP has some excellent libraries for web development. In many ways this
> makes up for the shortcomings in the language itself, since you can
> quite often keep actual programming to a minumum. I've seen nothing in
> the Python world that compares to Smarty templates (and yes, I've
> reviewed the many Python templating engines available. To date I've
> seen none that approach Smarty in actual
> usability/readability/simplicity).[/color]

Have you tried PageTemplates from Zope?

They are very clever, and the macros makes it much better at reusing
code than anything I have seen elsewhere.

--

hilsen/regards Max M, Denmark

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

Max M wrote:

[color=blue]
> Have you tried PageTemplates from Zope?
>
> They are very clever, and the macros makes it much better at reusing
> code than anything I have seen elsewhere.[/color]

I second that. But the truth is that I really like
templating systems that are valid HTML, thus
can be manipulated in an html editor

Istvan.

Istvan Albert wrote:[color=blue]
> Max M wrote:
>
>[color=green]
>> Have you tried PageTemplates from Zope?
>>
>> They are very clever, and the macros makes it much better at reusing
>> code than anything I have seen elsewhere.[/color]
>
> I second that. But the truth is that I really like
> templating systems that are valid HTML, thus
> can be manipulated in an html editor[/color]

Wich is exactly what PageTemplates are...

Most other systems use "illegal" html syntax for things like loops and
logic.

--

hilsen/regards Max M, Denmark

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

On Fri, 2004-10-22 at 14:46 +0200, Max M wrote:[color=blue]
> Cliff Wells wrote:
>[color=green]
> > PHP has some excellent libraries for web development. In many ways this
> > makes up for the shortcomings in the language itself, since you can
> > quite often keep actual programming to a minumum. I've seen nothing in
> > the Python world that compares to Smarty templates (and yes, I've
> > reviewed the many Python templating engines available. To date I've
> > seen none that approach Smarty in actual
> > usability/readability/simplicity).[/color]
>
>
> Have you tried PageTemplates from Zope?
>
> They are very clever, and the macros makes it much better at reusing
> code than anything I have seen elsewhere.[/color]

Can they be used outside of Zope? One of my criteria was usability
<wink>

--
Cliff Wells <clifford.wells@comcast.net>

Cliff Wells wrote:[color=blue][color=green]
>>Have you tried PageTemplates from Zope?
>>
>>They are very clever, and the macros makes it much better at reusing
>>code than anything I have seen elsewhere.[/color]
>
>
> Can they be used outside of Zope? One of my criteria was usability
> <wink>[/color]

Yep, I use them regularly. zpt.sf.net has a somewhat out of date
distribution (it still works fine though), and simpletal is another
implementation. There's even a Perl implementation (PETAL). At some
point the Zope people are going to make a fully up-to-date release of
that package (without the rest of Zope), but they are mostly stuck on
the packaging issues (the dependencies have already been worked out; it
doesn't depend on the rest of Zope).

--
Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org

Shufen wrote:[color=blue]
> 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.[/color]

Well, in general I'd say Python is better than PHP at pretty much
everything but:
* Regularly available on commercial hosts
* Unified basis for web development (there's still a lot of MVC-like
frameworks built on PHP, but they share more in common than in Python)
* Always uses a multiprocess model that both protects against bugs (or
at least, your server stays up no matter how buggy your PHP app or
libraries), and not too inefficient (like CGI).
* Easy to install and administer PHP applications; there can be a lot of
nuisances when installing Python web applications, like sys.path etc.

When it comes to all the more general things, Python beats PHP on pretty
much everything. Python has a clear and general object model -- PHP is
just starting to add some more generic things to its object model, like
operator overloading, and computed attributes. It still falls way short
of even the earliest versions of Python. I'll only briefly mention the
amateurish object implementation that requires assigning intermediate
objects to variables; I don't even understand what hackery caused that
misfeature.

Python doesn't have references (except that everything is implicitly a
reference), which is 100% a feature -- references are a horrible idea.
PHP seems to be moving away from references in version 5 as well.
Everything in Python is call-by-reference.

Python has namespaces and good modularity.

Python doesn't muck up quoting. PHP's magic quotes are bizarre and
dangerous, IMHO. They were a way of making up for PHP's sloppiness in
other areas. It never folds things into the namespace like PHP --
again, PHP programmers are moving away from this.

Well, that's just a short list. Just about everything you can think of,
Python is arguably better than PHP. Except for the web programming
environments -- which have their benefits in Python, but it forces you
to make a lot of choices and compromises that would be better forgotten.
But we're finally making some progress in Python to fix that
situation. (Incidentally, I work full time doing Python web
programming, and I've done a fair amount of PHP programming in the past
as well.)

At the same time, there's still a lot of really good PHP applications,
which is a testament to the language. Any language where people can do
good work is a good language; and while PHP's advantages over Python
seem small, I think the evidence shows that they are quite significant.

--
Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org

Istvan Albert <ialbert@mailblocks.com> wrote:
...[color=blue]
> I second that. But the truth is that I really like
> templating systems that are valid HTML, thus
> can be manipulated in an html editor[/color]

Me too. nevow forever...!!!

Alex

>> Have you tried PageTemplates from Zope?[color=blue][color=green]
>>
>> They are very clever, and the macros makes it much better at reusing
>> code than anything I have seen elsewhere.[/color]
>
> Can they be used outside of Zope? One of my criteria was usability[/color]

SimpleTAL
http://www.owlfish.com/software/simpleTAL/ - pure python module

--
damjan

Dnia Fri, 22 Oct 2004 03:56:44 -0700, Cliff Wells napisa³(a):
[color=blue]
> I've seen nothing in the Python world that compares to Smarty templates[/color]

I am using Smarty and I know them very well, but compiled Cheetah Templates
(http://www.cheetahtemplates.org) with its inheritance approach
is much powerfull and easier to use than Smarty. Cheetah can cache any
indyvidual placeholder or portions of template. Smarty caches only the
entire template output as a unit. Cheetah can be extended using inheritance
approach. Smarty can use only the containment aproach. Cheetah uses Python
with its all benefits. Smarty uses PHP with its messing function names, no
import idea, no namespaces idea, worse unicode library, no docstring, no
good free IDE/RAD editors etc.

--
JZ http://zabiello.om

Dnia Fri, 22 Oct 2004 03:56:44 -0700, Cliff Wells napisa³(a):
[color=blue]
> I've seen nothing in the Python world that compares to Smarty templates[/color]

I am using Smarty and I know them very well, but compiled Cheetah Templates
(http://www.cheetahtemplates.org) with its inheritance approach
is much powerfull and easier to use than Smarty. Cheetah can cache any
indyvidual placeholder or portions of template. Smarty caches only the
entire template output as a unit. Cheetah can be extended using inheritance
approach. Smarty can use only the containment aproach. Cheetah uses Python
with its all benefits. Smarty uses PHP with its messing function names, no
import idea, no namespaces idea, worse unicode library, no docstring, no
good free IDE/RAD editors etc.

--
JZ http://zabiello.com

Alex Martelli wrote:
[color=blue]
> Me too. nevow forever...!!![/color]

Hm, it says on their page:

"However, no actual code may be embedded in the HTML template"

alas these are the sort of design decisions that
won't adapt well for real life scenarios.

Should we use code in templates? No. Should we make
every possible effort to prepare the data exactly as
we need. Absolutely.

Yet as soon as the whole thing is working we realize
that we forgot something and that fixing it the
"right way" will cause a significant setback. That's
reality, trying to avoid these by mandating a
certain behavior will only make the framework less
usable.

And that is where ZPT shines. You want full separation
go ahead. You want to bend the rules a bit go ahead.
You want to do it the wrong way and put your entire
program into the first "define" tag, well, guess
what you can do that too.

Where ZPT sucks is in its messy way to deal with
expressions. There are whole bunch of ways to create
them:

* path expressions - locate a value by its path.
* exists expressions - test whether a path is valid.
* nocall expressions - locate an object by its path.
* not expressions - negate an expression
* string expressions - format a string
* python expressions - execute a Python expression

and when one starts combining these all kinds of
peculiarities will have to be dealt with.

Istvan.

ps. as I look that the data/render example, I noticed
the color attribute is actually created in the
code ... IMO this is exactly what we are trying to avoid
with templating. There is no indication in the
template that a new attribute is going to be added
to the tag ...

compare this to the same thing in ZPT:

<span tal:content="name" tal:attributes="style color">Tag Name</span>

Istvan Albert <ialbert@mailblocks.com> wrote:
[color=blue]
> Alex Martelli wrote:
>[color=green]
> > Me too. nevow forever...!!![/color]
>
> Hm, it says on their page:
>
> "However, no actual code may be embedded in the HTML template"
>
> alas these are the sort of design decisions that
> won't adapt well for real life scenarios.[/color]

Works fine for me.
[color=blue]
> Should we use code in templates? No. Should we make
> every possible effort to prepare the data exactly as
> we need. Absolutely.[/color]

The template is not going to be exactly the HTML code we need to output,
of course; that's what the nevow namespace is all about --
letting the template get the data it needs and pick the rendering
approach it prefers among those the application makes available.

[color=blue]
> Yet as soon as the whole thing is working we realize
> that we forgot something and that fixing it the
> "right way" will cause a significant setback. That's
> reality, trying to avoid these by mandating a
> certain behavior will only make the framework less
> usable.[/color]

What setback? If you've omitted to provide (e.g.) a rendering method
you realize you need, you add it to the Python code and access it with
the appropriate nevow:data="whatever" attribute in the template. No
problem.

[color=blue]
> And that is where ZPT shines. You want full separation
> go ahead. You want to bend the rules a bit go ahead.[/color]

Special cases are not special enough to break the rules.

That's what makes Python great. It's what will make nevow great when it
gets a bit more stable (it IS still at 0.3, after all -- and I've seen
bugs in 0.3 that are already fixed in CVS [duplicating the patch I was
going to submit, natch;-)]).
[color=blue]
> You want to do it the wrong way and put your entire
> program into the first "define" tag, well, guess
> what you can do that too.[/color]

If you think that's a plus, go ahead, but then to be consistent you
should be coding in Perl...

[color=blue]
> ps. as I look that the data/render example, I noticed
> the color attribute is actually created in the
> code ... IMO this is exactly what we are trying to avoid
> with templating. There is no indication in the
> template that a new attribute is going to be added
> to the tag ...[/color]

Not sure what example you mean (I'm not up to date on nevow's current
docs). If the template gives control over to a rendering method, it's
of course fine for the rendering method to perform whatever rendering
alterations it's documented to perform. I disagree that removing
rendering functionality from code is "exactly what we're trying to
avoid": _some_ rendering requires logic (conditionals, loops) and
getting such logic OUT of the HTML is what _I_ see templating as being
mostly about.

There are many finer-grained ways, such as nevow:slot and
nevow:attribute, for the template to suggest exactly what aspects of the
rendering should be controlled by the code.

[color=blue]
> compare this to the same thing in ZPT:
>
> <span tal:content="name" tal:attributes="style color">Tag Name</span>[/color]

With the appropriate renderer (and NS declaration), the nevow equivalent
might be:

<span n:render="name">
<n:attr name="style"> <n:slot name="color"/> </n:attr>
</span>

It could well be simpler, in many ways, depending on how the renderer
method render_name in the code behind this page is specified (where else
but as a style attribute should the color go, for example? so wanting
to spell it out this way may be redundant). 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, and what spots need to be
identified (as slots, attrs, or patterns).

Alex

Alex Martelli wrote:[color=blue][color=green]
>>Yet as soon as the whole thing is working we realize
>>that we forgot something and that fixing it the
>>"right way" will cause a significant setback. That's
>>reality, trying to avoid these by mandating a
>>certain behavior will only make the framework less
>>usable.[/color]
>
>
> What setback? If you've omitted to provide (e.g.) a rendering method
> you realize you need, you add it to the Python code and access it with
> the appropriate nevow:data="whatever" attribute in the template. No
> problem.[/color]

Well, this quickly becomes a matter of aesthetics, intractible to argue
about... but anyway...

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

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.

Something that ZPT tries to attempt -- and not entirely successfully --
is a separation of concerns, so that some people can work primarily in
ZPT. I frequently work with people who work entirely in ZPT, sometimes
stretching it further than it should go; but in those cases they are
able to move forward with ZPT, and later we can cooperatively refactor
the code. If I'm the only one comfortable going into the Python (which
is usually the case), I'm not a bottleneck. I'm not sure this is
possible in Nevow.

Now, there might be a valid compromise where a more declarative template
language is acceptable in my sort of situation. Indeed, there is a
problem where control and rendering logic become mixed, which is part of
why other people aren't comfortable going into the Python code (though
there's other reasons, like they aren't familiar with the domain objects
or other pieces of the system). In some ways, I'd like to see a
templating system where I can call the template from my control code
with a minimal, fixed interface, and that there is a small bit of Python
code that does the heavier lifting of making that data acceptable for
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.

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

--
Ian Bicking / ianb@colorstudy.com / http://blog.ianbicking.org

On Fri, 2004-10-22 at 21:32 +0200, JZ wrote:[color=blue]
> Dnia Fri, 22 Oct 2004 03:56:44 -0700, Cliff Wells napisa³(a):
>[color=green]
> > I've seen nothing in the Python world that compares to Smarty templates[/color]
>
> I am using Smarty and I know them very well, but compiled Cheetah Templates
> (http://www.cheetahtemplates.org) with its inheritance approach[/color]

http://www.cheetahtemplate.org/
[color=blue]
> is much powerfull and easier to use than Smarty. Cheetah can cache any
> indyvidual placeholder or portions of template. Smarty caches only the
> entire template output as a unit. Cheetah can be extended using inheritance
> approach. Smarty can use only the containment aproach. Cheetah uses Python
> with its all benefits. Smarty uses PHP with its messing function names, no
> import idea, no namespaces idea, worse unicode library, no docstring, no
> good free IDE/RAD editors etc.[/color]

First of all, more powerful wasn't the main criteria and easier to use
is arguable depending on your point of view. Smarty strikes a fine
balance between power and simplicity. This is where I feel most of the
Python templating engines fall down. They try to do too much. Smarty
appears to have found the sweet spot between simplicity and power, with
just the right type and amount of built-in utility to do its job. On
top of that, it provides a way to extend itself with custom functions,
so the full power of PHP (broken as that may be) is within reach if you
need it.
My personal feeling on templates is that if you find yourself needing
very powerful features, you're doing it wrong. That's what the parent
programming language is for. My favorite use for templates is storing
them in a database so that the end user can modify a website (via a web
interface) without knowing PHP/Python. Were I shove too much
programming into the template, this wouldn't be possible.

Regards,
Cliff

--
Cliff Wells <clifford.wells@comcast.net>

Ian Bicking <ianb@colorstudy.com> wrote:
...[color=blue]
> 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[/color]

In this corner, one or more excellent programmers with the typical
aesthetic and artistic sense of the average programmer: lousy-minus.

In the other corner, one or more excellent graphics designers who
specialize in producing wonderful web pages mixing HTML, style sheets,
graphics, maybe a drop of javascripts for effects and usability -- with
the typical program-design ability of the average artist: lousy-minus.

How do we get great web pages out of this team?

I don't want the HTML, CSS etc to come out of the programmers' work: it
would look bad and be unusable.

I don't want any program design to come out of the artists' work: it
would be crufty and unmaintainable.

What I want is: let the programmers program, and the artists write HTML,
CSS, and the like.

Moreover, in the typical business scenario, the visuals and exact
effects of the pages will be endlessly tweaked and tinkered with,
because that's what clients, marketeers and focus on. The program must
be able to remain stable and just reflect to the browser the current
state of the tweaking and tinkering (ideally without needing to stop and
restart the program, to help the poor artists' lives).

Nevow helps a _lot_ with this scenario. The programmers (with all due
consultation and customer involvement, to be sure) define all the logic
and implement it in Python; _NOT_ in .HTML files, but quite away from
them. What the HTML files need to contain is the mention of the data
sources and renderers that are to be used, out of the 'palette' supplied
by the Python code (nevow:data and nevow:render attributes, data_this
and render_that methods in Python) and markers to identify 'this is the
spot' for the renderer's benefit.

The programmers can develop all logic (with lousy looks) with their own
ugly and nastly HTML files. The artists "just" need to write beautiful,
corporate-standards-du-jour compliant HTML, CSS, etc, with the
appropriate choice of data sources and renderers and 'this is the spot'
markup. Each time a template file is modified, nevow will know to
reload and reparse it next time it's used, which is handy for tweaking
and tinkering purposes.

Nevow has a lot of stuff I haven't needed yet, such as most of stan (can
generate HTML w/o any templating), live-page functionality (use Python
instead of Javascript... but with a round trip every time... well, maybe
on a LAN...), freeform/formless -- maybe I won't ever need it, and it
does not necessarily fit within the above scenario all that well. But
the templating per se seems to me to be just what I need in the above.

[color=blue]
> 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.[/color]

Right, business vs presentation logic separation is done 'behind' the
template, in Python.
[color=blue]
> 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.
>
> 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.[/color]

Bingo: the fewer the better.

[color=blue]
> Something that ZPT tries to attempt -- and not entirely successfully --
> is a separation of concerns, so that some people can work primarily in
> ZPT. I frequently work with people who work entirely in ZPT, sometimes[/color]

And nevow lets some people (graphics artists specializing in webpages)
work primarily in HTML/CSS/maybe javascript (sigh) for effects &c.
That's exactly how I like it...
[color=blue]
> stretching it further than it should go; but in those cases they are
> able to move forward with ZPT, and later we can cooperatively refactor
> the code. If I'm the only one comfortable going into the Python (which
> is usually the case), I'm not a bottleneck. I'm not sure this is
> possible in Nevow.[/color]

I believe it's not -- by design. If program logic must be modified,
programmers (able to work in Python, not a terribly high bar btw) will
be the ones modifying it. I like the idea.

[color=blue]
> Now, there might be a valid compromise where a more declarative template
> language is acceptable in my sort of situation. Indeed, there is a
> problem where control and rendering logic become mixed, which is part of[/color]

Absolute agreement here: such mixing is a problem. Nevow avoids it.
[color=blue]
> why other people aren't comfortable going into the Python code (though
> there's other reasons, like they aren't familiar with the domain objects
> or other pieces of the system). In some ways, I'd like to see a
> templating system where I can call the template from my control code
> with a minimal, fixed interface, and that there is a small bit of Python
> code that does the heavier lifting of making that data acceptable for[/color]

As long as said small bit of Python code is in a Python module, I'm fine
with that. Normal inheritance easily lets you split that way the class
that works behind a nevow template: any data supplier or renderer which
is rich or complicated may be stashed away in a base class somewhere
else, and the actual class driving the page need only "little bits" of
overriding/wrapping or adding new simple methods. If you only work with
graphic artists/page designers who are a little bit comfortable with
Python, they can work on retouching the easier, front-side parts, while
all the heavy and please-don't-touch parts are elsewhere and clearly
marked as such. Other such refactorings may quite well be possible; the
"pure" programmers-on-one-side, artists-on-the-other arrangement is
surely not the only one that Nevow enables... just the one that I think
I need, and that I've seen no other templating system enable so well.
[color=blue]
> 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.[/color]

No, in my worldview that's CSS's job. Python code only need to emit the
table rows with alternate (CSS) class attributes. The existing sequence
renderer supplied by nevow's infrastructure enables that, btw: write
more than one nevow:pattern="item" tags and render_sequence will render
them in round-robin style.

[color=blue]
> Anyway, I'm very suspicious of any system which limits the programmer
> for their own good.[/color]

Ah, you see the guy coding the HTML/CSS/etc as "the programmer". I
don't. The world has even too many webpages made by programmers: it
shows. Let's have some more made by people who know how to do pleasing
and usable graphic designs: they don't need to be programmers (at least
in the "pure" arrangement), they do need to be good artists. Meanwhile
the programmers may have all the aesthetic sense they're famous for,
without thereby spoiling the output pages...

Alex

Cliff Wells <clifford.wells@comcast.net> wrote:
[color=blue]
> My personal feeling on templates is that if you find yourself needing
> very powerful features, you're doing it wrong. That's what the parent
> programming language is for. My favorite use for templates is storing
> them in a database so that the end user can modify a website (via a web
> interface) without knowing PHP/Python. Were I shove too much
> programming into the template, this wouldn't be possible.[/color]

With Nevow you're meant to shove no programming at all into the
template, and enabling the modification of the templates by
non-programmers is a key design goal. (Haven't yet seen any work on
storing them in a DB rather than on the filesystem, or enabling specific
via-web editing thereof rather than the use of normal HTML editing tools
and applications, but that kind of issue seems secondary to the way the
templating system itself is designed).

Nevow is probably not yet mature enough for much more widespread use
than it's getting. But, it _is_ maturing -- and it seems (regarding its
templating subsystem, forgetting for the moment about other stuff such
as live-page klud^H^H^H^H brilliancies;-) consonant with your goals.

Alex

Dnia Fri, 22 Oct 2004 14:22:53 -0700, Cliff Wells napisa³(a):
[color=blue]
> First of all, more powerful wasn't the main criteria and easier to use
> is arguable depending on your point of view.[/color]

Hmm, so what's the main criteria? :)
[color=blue]
> Smarty strikes a fine balance between power and simplicity.[/color]

It is your personal point of view. Many others consider Smarty for hard to
learn and much too complicated for template system which should be simple
and easy to learn. PHP is itself a template language, so someone could say
there is no need for another template language on top of it. :) Look at
Savant Template System http://phpsavant.com/yawiki/. There are interesting
user notes. Many people seems to be frustrated with Smarty syntax.

But my personal point of view is, that Smarty is the best PHP template
system and it is worth to learn it even if it is not as simple as someone
could expect. I have no problem with Smarty's syntax because I use it for
several years. And if I would have to use PHP I would choose Smarty.

But, the problem is PHP itself has so many bad features that I prefer
rather Python to PHP. And I like Cheetah's inheritence aproach because it
is scales very well for complicated web pages. I can develop internet
application much faster using Python (e.g. using application, very cool and
pythonic Cherry2) and Cheetah. And because extending templates using OO
techniques is tthe feature I like, I would rather choose Cheetach than ZPT,
SimleTAL, Nevow and similar solutions.
[color=blue]
> This is where I feel most of the Python templating engines fall down.
> They try to do too much.[/color]

It is not fair to compare one Smarty against several anonymous template
systems for Python. I compare Smarty with Cheetah. Not Cheetah against
PHPLib, and all other better or worse templates for PHP.
[color=blue]
> Smarty [...] provides a way to extend itself with custom functions,[/color]

Savant Templates provides custom plugins using only pure PHP without
another, strange language. :) Savant has markup compiler, so you can invent
any markup system you like.
[color=blue]
> My personal feeling on templates is that if you find yourself needing
> very powerful features, you're doing it wrong.[/color]

No. I need power and simplicity working together. And my choice is Cheetah.
It has power and it is enough simple to be easy learned.

Regards,
Jarek http://zabiello.com

Ian Bicking <ianb@colorstudy.com> wrote:[color=blue]
> 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[/color]

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).
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
> is usually the case), I'm not a bottleneck. I'm not sure this is
> possible in Nevow.[/color]

It is as I wrote above. Nevow templating system is _extremely_ flexible and
can be made to do almost everything you need to.
[color=blue]
> 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.[/color]

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

<table nevow:data="some_data" nevow:render="sequence">
<tr nevow:pattern="item" class="odd">...</tr>
<tr nevow:pattern="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.
[color=blue]
> Anyway, I'm very suspicious of any system which limits the programmer
> for their own good.[/color]

Which, I would say, It clearly not Nevow.

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

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

Valentino Volonghi aka Dialtone wrote:
[color=blue]
> Nevow _CAN_ embed code in the template. and you can do that in this way:[/color]

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

Istvan Albert <ialbert@mailblocks.com> wrote:[color=blue]
> 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 ...[/color]

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.
[color=blue]
> 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"[/color]

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.

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

Alex Martelli wrote:
[color=blue]
> Not sure what example you mean:[/color]

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

data/render methods
[color=blue]
> 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[/color]

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.

www.nevow.com

www.nevow.com

Valentino Volonghi aka Dialtone wrote:
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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.[/color]

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.

Istvan Albert <ialbert@mailblocks.com> wrote:
[color=blue]
> Alex Martelli wrote:
>[color=green]
> > Not sure what example you mean:[/color]
>
> http://www.divmod.org/Home/Projects/Nevow/
>
> data/render methods
>[color=green]
> > 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[/color]
>
> 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.[/color]

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.

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

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

[color=blue]
> 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).[/color]

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

s4046441@student.uq.edu.au (Shufen) wrote:[color=blue]
>
>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.[/color]

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.
--
- Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

Tim Roberts <timr@probo.com> wrote:[color=blue]
> 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.[/color]

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.

Alex Martelli wrote:
[color=blue]
> 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.[/color]

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

Max M <maxm@mxm.dk> wrote:[color=blue]
> 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.[/color]

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.

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

Max M <maxm@mxm.dk> wrote in message news:<417cb790$0$226$edfadb0f@dread12.news.tele.dk >...[color=blue]
>
> The main problem with most templating systems is not only that they mix
> markup and code, but also that markup reuse is allmost impossible.[/color]

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

[color=blue]
> 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)[/color]

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

[color=blue]
> Zope Page Templates has a far better approach to this imho. Where you
> define reusable markup in a macro.[/color]

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

Valentino Volonghi aka Dialtone <dialtone.##NOSPAM#$#$$#@gmail.com>
wrote:
[color=blue]
> Max M <maxm@mxm.dk> wrote:[color=green]
> > 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>[/color][/color]

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).
[color=blue][color=green]
> > 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.[/color]
>
> 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[/color]

OK, but the problem is, who supplies My_Fragment, and how is said
fragment going to be parameterized.
[color=blue]
> 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.[/color]

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

Alex Martelli <aleaxit@yahoo.com> wrote:[color=blue]
> OK, but the problem is, who supplies My_Fragment, and how is said
> fragment going to be parameterized.[/color]

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).
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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>[/color]

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)
[color=blue]
> 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;-).[/color]

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 :)
[color=blue]
> 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).[/color]

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

On Mon, 2004-10-25 at 10:24 +0200, Max M wrote:[color=blue]
> Alex Martelli wrote:
>[color=green]
> > 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.[/color]
>
>
> The main problem with most templating systems is not only that they mix
> markup and code, but also that markup reuse is allmost impossible.[/color]

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.
[color=blue]
> 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)[/color]

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.
[color=blue]
> 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.[/color]

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

--
Cliff Wells <clifford.wells@comcast.net>

Shufen wrote:[color=blue]
> 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[/color]

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.

> Python is just a plain better language. I use both[color=blue]
> 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.[/color]
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.

Alex Martelli wrote:
[color=blue][color=green][color=darkred]
>>> <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>[/color][/color]
>
>
> 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).[/color]

It was a typo. Untested code from memory.

[color=blue]
> OK, but the problem is, who supplies My_Fragment, and how is said
> fragment going to be parameterized.[/color]

Exactly. Complex markup inside complex templates is the problem.

[color=blue]
> 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!),[/color]

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

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

[...]
[color=blue]
> 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.[/color]

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

--
Matt Goodall, Pollenation Internet Ltd
w: http://www.pollenation.net
e: matt@pollenation.net
t: +44 (0)113 2252500

hi all -

might I add what I think is a valuable link to this discussion:

http://www.myghty.org/

it is my own application largely based around the model of Perl's
HTML::Mason. It addresses specifically the performance, architecture,
and template-flexibility issues of some of the other packages I have
seen mentioned here. I think its particular combination of strong
featureset, smooth performance and templating style makes it one of
the best things out there for building python-based dynamic websites
as well as content-generation systems.

Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

re: Python vs PHP

Similar Python bytes

/bytes/development

/bytes/it

/bytes/about