Web tool kit : pro - cons ?

**Irmen de Jong** · Jul 18 '05, 01:03 AM

Re: Web tool kit : pro - cons ?

vincent_delft wrote:
[color=blue]
> Is there a site who list the main charateristics of each of those Web tool
> kit ?[/color]

Check out http://www.python.org/cgi-bin/moinmoin/WebProgramming

--Irmen de Jong

**vincent_delft** · Jul 18 '05, 01:03 AM

Re: Web tool kit : pro - cons ?

Irmen de Jong wrote:
[color=blue]
> vincent_delft wrote:
>[color=green]
>> Is there a site who list the main charateristics of each of those Web
>> tool kit ?[/color]
>
> Check out http://www.python.org/cgi-bin/moinmoin/WebProgramming
>
> --Irmen de Jong[/color]

Waouuuww...

So many different tools ....

Can I get some "guidelines " ?
My needs are :
- Build pages via templates (easy to split content and layout)
- My pages will be defined with "boxes". I would like to have a tool that
can manage easely such "object".
- I will use PostgreSQL as backend.
- possibility to build very simple web site (<10 users) but big web sites
too ( > 1000 users). So I don't need a Apache/mod_Python, ... for small web
sites. CGIHTTPserver is enough. But CGIHTTPServer will not be able to
manage very high load.

**Gerhard Häring** · Jul 18 '05, 01:03 AM

Re: Web tool kit : pro - cons ?

vincent_delft wrote:[color=blue]
> My needs are :
> - Build pages via templates (easy to split content and layout)[/color]

ZPT seems to be a good option there.
[color=blue]
> - My pages will be defined with "boxes". I would like to have a tool that
> can manage easely such "object".[/color]

You mean a WYSIWYG web development IDE for Python? I don't think there's
such a thing.
[color=blue]
> - I will use PostgreSQL as backend.[/color]

I'd suggest you use pyPgSQL or psycopg for this. I'm a little biased
towards pyPgSQL, being one of it's developers ;-)

-- Gerhard

**yaipa h.** · Jul 18 '05, 01:03 AM

Re: Web tool kit : pro - cons ?

Vincent,

You don't list Webware oddly enough. I have been using it with the
Cheetah templating engine. Works fine, with good support.

Python 9 White Paper on Webware
--------------------------------

Do My Programming Homework | Order Your Paper For $10 - EssayTigers

http://www.python9.org/p9-cdrom/index.htm

Looking for where to do my programming homework? EssayTigers is here for you. Professional writers. High quality papers. No plagiarism.

Cheetah dev page
----------------

Cheetah3, the Python-Powered Template Engine — Cheetah3 - The Python-Powered Template Engine

http://www.cheetahtemplate.org/

Cheers,

--Alan

vincent_delft <vincent_delft@ yahoo.com> wrote in message news:<3f23003f$ 0$266$ba620e4c@ reader0.news.sk ynet.be>...[color=blue]
> I'm looking for a Web Tool kit to build web pages with the following
> criteria (in priority order) :
> - easy to use, develop (reuseability of code, ...)
> - flexible (ideally should run with Python CGIHTTPServer and/or with Apache
> (with or wihout mod_python)
> - possibility to have load balancing and/or caching (for very high loaded
> web pages)
>
> I've founded lot of tools ...
>
> I've read the doc of most of them, I've tested some of them.
> But, is there anyone "experience d user" who can give the pro-cons for each
> of those solutions ? (or propose an another)
>
> Is there a site who list the main charateristics of each of those Web tool
> kit ?
>
> Thanks
>
>
> Zope (www.zope.org),
> SkunkWeb (http://skunkweb.sourceforge.net/),
> Quixote (http://www.mems-exchange.org/software/quixote/),
> Twisted (http://www.twistedmatrix.com/)
> Albatross (http://www.object-craft.com.au/projects/albatross/)
> Cherrypy (...)
> pwo (...)
> ...[/color]

**Dennis Lee Bieber** · Jul 18 '05, 01:03 AM

Re: Web tool kit : pro - cons ?

vincent_delft fed this fish to the penguins on Saturday 26 July 2003
04:01 pm:
[color=blue]
> - Build pages via templates (easy to split content and layout)
> - My pages will be defined with "boxes". I would like to have a tool
> that can manage easely such "object".
> - I will use PostgreSQL as backend.
> - possibility to build very simple web site (<10 users) but big web
> sites too ( > 1000 users). So I don't need a Apache/mod_Python, ...
> for small web sites. CGIHTTPserver is enough. But CGIHTTPServer will
> not be able to manage very high load.
>[/color]
Have you considered Zope?

(And I am NOT an expert in it at all... Merely a dabbler when I can
find time)

--[color=blue]
> =============== =============== =============== =============== == <
> wlfraed@ix.netc om.com | Wulfraed Dennis Lee Bieber KD6MOG <
> wulfraed@dm.net | Bestiaria Support Staff <
> =============== =============== =============== =============== == <
> Bestiaria Home Page: http://www.beastie.dm.net/ <
> Home Page: http://www.dm.net/~wulfraed/ <[/color]

**Ian Bicking** · Jul 18 '05, 01:03 AM

Re: Web tool kit : pro - cons ?

On Sun, 2003-07-27 at 05:58, vincent_delft wrote:[color=blue][color=green][color=darkred]
> >> - My pages will be defined with "boxes". I would like to have a tool
> >> that can manage easely such "object".[/color]
> >
> > You mean a WYSIWYG web development IDE for Python? I don't think there's
> > such a thing.
> >[/color]
> No. Each part of the web page will be "boxes". I would like to be very
> flexible and display "dynamicall y" some selected boxes.
> For example the same page (url) will not display the same boxes if you are
> administrator, maintener or simple viewer.
> An another example will be to have possibility to re-use existing boxes. If
> I have a boxes displaying the last 5 news from Slashdot, I don't want to
> re-write it each time I need a new bacground color (for example). My Idea
> is to use those "boxes" like we use classes : if you need some modification
> you subclass it on the rest remains the same.[/color]

You might want to look at Cheetah, where templates are mapped to Python
classes. This allows subclassing of templates, defining methods (e.g.,
a header method), and of course nesting templates.

Ian

**Remi Delon** · Jul 18 '05, 01:04 AM

Re: Web tool kit : pro - cons ?

> I've read the doc of most of them, I've tested some of them.[color=blue]
> But, is there anyone "experience d user" who can give the pro-cons for each
> of those solutions ? (or propose an another)[/color]

The problem is that most people are "experience d users" with only a few of
the frameworks.
In order to find out all the little caveats of a perticular framework, one
has to use it for quite a big project (I'd say at least 6 months).
I don't think any of us have developed such big projects with more than,
say, 2 or 3 python frameworks. (in my case, I've only used Zope and CherryPy
for "real" applications. I've only "played" with the other frameworks).
This is why it is hard to have one person make a comparison of all the
frameworks ...

Having said that, I think that CherryPy definitely meets your
requirements... (sorry, I couldn't help saying it :-)))

Remi. remi@cherrypy.o rg
----------------------
Specialized python hosting: http://www.python-hosting.com
CherryPy application server: http://www.cherrypy.org
Free CherryPy hosting: http://www.freecherrypy.org
----------------------

**Jane Doe** · Jul 18 '05, 01:06 AM

Re: Web tool kit : pro - cons ?

On Mon, 28 Jul 2003 10:59:05 +0100, "Remi Delon" <remi@cherrypy. org>
wrote:[color=blue]
>Having said that, I think that CherryPy definitely meets your
>requirements.. . (sorry, I couldn't help saying it :-)))[/color]

I second that. CherryPy is the Python framework that was the easiest
to grasp as a newbie.

Other frameworks that look similar to CherryPy (ie. URLs are actually
calls to classes and methods) are WebWare + Cheetah, Skunkweb. If
someone knows of others, I'm all ears :-)

JD.

**Jeffrey P Shell** · Jul 18 '05, 01:07 AM

Re: Web tool kit : pro - cons ?

David Jeske <jeske@chat.net > wrote in message news:<mailman.1 059332921.14965 .python-list@python.org >...[color=blue]
> If you are not wedded to Zope for your applications, you may want to
> look at Clearsilver. (http://www.clearsilver.net) It is a very mature
> system which was developed at eGroups.com, and today is in use on
> high-performance sites such as Yahoo! Groups and
> wunderground.co m. Clearsilver includes a full CGI kit which handles
> form variables, cookies, etc. It also includes a PythonObject<->RDBMS
> mapping system (MySQL only today, no pgsql yet), and a transparent
> translation string extraction system. It is not a "server environment"
> like Zope, and in fact you can use it inside of your server of choice
> (Apache, Boa, IIS, Zope, etc).
>
> I find ZPT's model for replacement hard to work with, because it tries
> to fit into the xml document namespace. From the ZPT documentation
> here:
>
> http://www.zope.org/Documentation/Bo...urrent/ZPT.stx
>
> This example:
>
> <title tal:content="he re/title">Page Title</title>
>
> Illustrates how ZPT is making it's "tag" (i.e. tal:content) fit in as
> an attribute defined by a new XML namespace. The problem is, this
> constrains where you can use template commands to construct the
> document. Clearsilver uses a model more like PHP where the tags exist
> as items outside of the XML document parsing. This has the drawback
> that your template document is not a valid XML document, but it has
> the advantage that you can put the tags anywhere.
>
> For example, in clearsilver, you can construct URLS using sequences of
> template commands, even looping. Here is a small example (whitespace
> added for readability):
>
> <a href="/url?
> <?cs each:p=CGI.Para ms ?>
> <?cs var:p.name ?>=<?cs var:p.value ?>&
> <?cs /each ?>"[color=green]
> >a_link</a>[/color][/color]

I love Zope's page templates. I do have to admit that I worked at
Zope Corporation since before Zope was Principia, but am now out in
the wild stressful world on my own again. But I grew to *hate* the
above style of templating, which Zope's older model (DTML) follows.
I've been using DTML since early 1997 and when web applications were
still fairly simple, I think it was a nice system (DTML was also
simpler then and focused more on being a templating language than on
being a programming language, which is what made DTML particularly
painful on Zope in later years before ZPT).

I work with some very talented designers. It used to be that they
would give us (the developers) their designs and we'd rip them to
shreds and they could never touch them again. Because now they were
in little bits and pieces and stuffed full of tags-within-tags, with
silly things like 'standard_html_ header' and 'standard_html_ footer'
(never really fitting a technical definition of header once complex
designs enter the equation) making it very painful to apply what they
would thing were rudimentary design changes.

Not so with ZPT. It's not a holy grail, but it's pretty close. Most
of the time, the designers can tweak the site - even in production -
without upsetting the natural order of things. Given that they're
full time graphic designers (sortof a 'sibling' company. they also do
a lot of large volume print material, etc) and not programmers, this
is pretty impressive. They are smart enough to watch out for the
dynamic parts. But we've had very few issues since moving to it.

What I personally like about ZPT is the fact that it feels natural
within the HTML/XML environment. It may have taken some getting used
to initially, but I find it very natural. And it's extra nice because
I can work in smart text editors like XEmacs or BBEdit, or work in
GoLive (very nice when used with its WebDAV browser) and can view the
whole page - including the 'standard header/footer' (usually supplied
by a standard full page macro, which in itself is very easy to modify
and edit because it's a single full page and not broken up into chunks
like header/footer/sidebar - VERY nice. My life is so much better for
this fact alone!). Sometimes adding a dynamic element to a tag from
visual mode means just popping up the quick-tag editor and adding in a
TAL statement. Close the tag editor, and the page is still intact.

You can even do complex things like the following::

<tr tal:attributes= "class python:test(rep eat['item'].even(), 'even',
'odd')">
....
</tr>

and have visual editors, or even helpful hilighting editors (BBEdit,
XEmacs, etc) not be affected by it. Compared to::

<tr class="evenodd">

or this, if you only want the class attribute written on even rows
(and how we come up with the variable 'even' is being left to the
imagination here):

<tr class="even" >

most editors just die right here - especially visual ones. In TAL,
you could do:

<tr tal:attributes= "class python:test(rep eat['item'].even(), 'even',
nothing)">

and most editors would be fine. (Note: 'nothing' is that ZPT
equivalent of 'None'. The core components of ZPT (TAL, TALES, METAL)
were written as specs first, with the idea/hope that other programming
languages could implement them as well, hence 'nothing'. 'None' could
have been used in its place just as easily in this situation). Is it
more verbose? More typing? At times, yes. But there's a nice
explicit nature about it, and many old Zoper's have learned the hard
way that explicit is almost always better than implicit (DTML had so
many implicit actions going on that in the end - even after years of
use - there were always new surprises waiting in the wings. And
Radiohead says it best - 'no alarms and no surprises').

Anyways - this is just my personal experience. But I find that
(generally) with ZPT, I'm writing better HTML and have a more
maintainable web site. It's different, but I think it's a good thing.
I'm happy to get away from Server Side Include and Processing
Instruction style syntaxes.

To get back to your example::[color=blue]
> <a href="/url?
> <?cs each:p=CGI.Para ms ?>
> <?cs var:p.name ?>=<?cs var:p.value ?>&
> <?cs /each ?>"[color=green]
> >a_link</a>[/color][/color]

ZPT (at least in Zope) has a helpful module called ZTUtils that
contains a lot of nice helper functions for building query strings
(which I'm increasingly convinced should never be constructed by hand
unless absolutely necessary, due to issues with URL and/or HTML
quoting), hidden values, etc. Assuming that CGI.Params is a
dictionary/mapping, once could do:

<a tal:define="que ry python:modules['ZTUtils'].make_query(CGI .Params)"
tal:attributes= "href string:/url?${query}"[color=blue]
>a_link</a>[/color]

``make_query`` (which can also use keyword arguments) is extra nice
because it automatically URL quotes all of the values for the query
string. This is EXTRA EXTRA nice when passing full LDAP distinguished
names in a query string, for example.
[color=blue][color=green]
> > No. Each part of the web page will be "boxes". I would like to be very
> > flexible and display "dynamicall y" some selected boxes.
> > For example the same page (url) will not display the same boxes if you are
> > administrator, maintener or simple viewer.[/color]
>
> This should be pretty easy in most template systems worth their
> weight.
>[color=green]
> > An another example will be to have possibility to re-use existing boxes. If
> > I have a boxes displaying the last 5 news from Slashdot, I don't want to
> > re-write it each time I need a new bacground color (for example). My Idea
> > is to use those "boxes" like we use classes : if you need some modification
> > you subclass it on the rest remains the same.[/color]
>
> Clearsilver has a macro definition facility for doing just this. You
> can supply arguments to macros, and even call macros recursively. Here
> is a simple example:
>
> <?cs def:makelink(ur l,title,text) ?>
> <a href="<?cs var:url ?>"
> title="<?cs var:title ?>"[color=green]
> ><?cs var:text ?></a>[/color]
> <?cs /def ?>
>
> <?cs call:makelink(" http://www.python.org" ,"Python.org website","Pytho n.org") ?>
>
> The paramaters can be any expressions, including constructed strings,
> or data from your dynamic CGI. For example:
>
> <?cs call:makelink(" http://" + CGI.host + "/" + CGI.script,"tit le","link text") ?>
>
> As always, there are lots of systems out there, and YMMV.[/color]

Macros do make life happy. :) Or at least, happier. ZPT macros
(METAL) do things a little differently, but I think it works out for
the best. To the best of my knowledge, ZPT compilation/rendering
occurs in two steps - first, macros are expanded (METAL statements are
executed) into the template like they were there in the template all
along, and then all of the TAL statements (including ones that were in
the macros) get executed. One thing this allows, when used in a
dynamic environment like Zope, is the ability to have the macros be
expanded at edit time (optionally, of course). When using a full-page
macro, you can add a new ZPT page, fill it in like this::

<html metal:use-macro="here/standard_templa te.pt/macros/page">
<body>
<div id="main" metal:fill-slot="body">
<h3>The body of my new page template</h3>
</div>
</body>
</html>

Turn on 'expand macros', and the whole macro 'page' defined in the
page template 'standard_templ ate.pt' gets expanded. Macros define
'slots' which clients of the macros can choose to fill in. Nicely, if
you don't fill a slot specified by the macro, its defaults are filled
in and you can see where the slots are by looking for the 'metal:slot'
attributes. The above mentioned macro might contain a slot called
'local_js' and put it on a <script> tag:

<script type="text/javascript" metal:slot="loc al_js"></script>

You can use it if desired, by changing 'metal:slot' to
'metal:fill-slot' and add Javascript to the head of the page - all
without requiring changing the header or having to have the page
broken up into statements like:


<script type="text/javascript" ></script>


....
....
....

Which I've had to do and maintain so many times. I'm not sure when it
happened - but at some point, this all got to be unmanageable. It's
easy for situations like an intranet or basic web application where
you're in control, but when you're on the east coast dealing with a
west coast designer who dramatically changes layout every day - it
does grow untenable.

But I've long been of the personal opinion that HTML and code don't
mix. I felt that way ever since I started using CGI and wrote my own
little dynamic web system (pummel/pyml/avantpy) in '96 until I got
turned on to Bobo (ancestor and still-the-heart of Zope). ZPT lets me
see my templates as HTML, but still gives me the programmatic control
I need. It's better than the old days when I'd look at my templates
and see two conflicting languages that looked alike - an SGML-ish tag
based templating language inside the SGML tag based HTML language.
For some reason - using basic XML constructs (namespaced attributes)
works so much better (for me) than using one set of tags within
another set of tags.

I think that's all aided by how relatively clean and simple they've
managed to keep the core ZPT languages (TAL, METAL).

But, as always, mileage will definitely vary.

--
Jeffrey P Shell

http://toulouse.amber.org/

"Tied you up, placed in tube"

eucci, aodl, rive, sunhil — finest art and audio est. 1994

http://euc.cx/

Eucci - finest minimalist art and audio since jan 2000; Rive - finest audio recordings since 1994, 2003; aodl - finest return to noise since 2003; elw - finest audio collective group since 1994, 1997, 1999; my tv wife stars and starlets - finest guitars since 1997; Eucci Group Ltd - collection of finest art and audio designers

**Jeffrey P Shell** · Jul 18 '05, 01:07 AM

Re: Web tool kit : pro - cons ?

"Remi Delon" <remi@cherrypy. org> wrote in message news:<3f24f3f7@ shknews01>...[color=blue]
> The problem is that most people are "experience d users" with only a few of
> the frameworks.
> In order to find out all the little caveats of a perticular framework, one
> has to use it for quite a big project (I'd say at least 6 months).
> I don't think any of us have developed such big projects with more than,
> say, 2 or 3 python frameworks. (in my case, I've only used Zope and CherryPy
> for "real" applications. I've only "played" with the other frameworks).
> This is why it is hard to have one person make a comparison of all the
> frameworks ...[/color]

That's very true. I've been using Zope, Principia, and Bobo almost
back to their inception, and can't even grok other systems now. No
offense to CherryPy or any of the other ones. But once you get
proficient in a tool, it's hard to spend time with another when time
is.. Well. What is time and who has it anyways? :)

I've played with a couple of other Python web frameworks, I've even
written my own (way back in the day when WebObjects was the only major
app server on the market and *everything* else was home grown, and
Java was still a cute way to add animation to web pages ;). But aside
from the big jump to learning Zope 3 - I know I don't see any time in
my future for doing a serious (ie - more than 'hello world' or
'guestbook') evaluation of anything else. :\.

In response to the original question - things that I would use when
evaluating kits today is community size, maturity, etc. There are a
lot of "cool little idea" web kits that never reach completion, or
anything close to it (again - having written one, I know). Some
projects have been around for a while and have yet to reach a '1.0'
milestone. Some of those may just be reaching for perfection. Others
are left to languish while the core developers have to work for a
living, or find other solutions. Others may be in a state of 'yeah,
the current version is good enough', but a real 1.0 release never
quite seems to get made. For the past few years, I've made the SCM
decision for myself to never run on beta software, and seldom use
pre-1.0 software, no matter how good it may be, because we've got
dependability requirements from customers that we have to ensure are
met. And software that looks immature generally gets ranked low on
the list of evaluations. (of course, having a low quality 1.0 release
is not a good idea either ;)

Quixote and CherryPy both deserve attention for their templating
systems. I like what I've seen of each more than the many variants of
"Python Server Pages" out there that try to embed Python in HTML
(Python's block structure just makes this already messy style
messier).

Database Abstraction is another key issue. Zope gets points here not
only for the built in ZODB database, but for SQL Methods / Database
Adapters. There is nothing in Zope that is tied to Postgres, MySQL,
Oracle, Sybase, SQLite, etc. Yet it's always been able to use any of
them since before it was Zope. There's just a nice simple abstraction
layer that one seldom has to think about. Other tools try the O-R
mapping route for abstraction with varying degrees of success.
SkunkWeb has PyDO, WebWare has one (I can't remember its name right
now). Zope's model is nice because it's not intrinsic to Zope that
you use SQL - it's just a nice model to plug into if you need it, when
you need it. I don't know how other toolkits stack up here. Some may
just say "go find a Python adapter that works for you and do what you
want with it", which seems to be as good of a way to go as any.

Enterprise scalability could be another factor. SkunkWeb has
aggressive caching and tight integration with Apache as one of its
features for delivering dynamic chunks of content under high load.
Zope has its built in transaction system, which makes database work
nice. Database adapters and other objects can integrate themselves
into this system to ensure that either everything succeeds and gets
written, or everything fails and rolls back, and you're not stuck with
some data in one database but none in another (it's only as infallible
as the systems that support it. Thank gods for InnoDB in MySQL!).
Transactions are automatic (but can be handled manually, if desired) -
a web request begins a transaction, and a successful writing of the
response commits it. Any exceptions raised abort it. This becomes
one of those little subtle platform niceties that you forget about but
are eternally grateful for. Usually ;). Other toolkits may vary - it
depends on what itch they were initially trying to scratch when they
started. The transaction stuff in Zope goes back to Bobo and the
early BoboPOS (which became the ZODB) because of the work I assume
Digital Creations was doing with databases. Having gone through the
pain of half written text files generated by mediocre self-written CGI
scripts, this became an early favorite feature :).

In any case, this is just my evaluation list as it would stand today,
given my experiences over the last couple of years. I don't know how
rosy Zope would come up today if I were evaluating different
frameworks under this criteria - I always think it would be nice to
have time to really step back and evaluate some different options, if
only to get a fresh perspective (kindof like taking some time to
evaluate Ruby might give one a fresh perspective on programming
Python). But - there's just no time in the schedule to justify such
an undertaking, for better or for worse...

**Ian Bicking** · Jul 18 '05, 01:08 AM

Re: Web tool kit : pro - cons ?

On Wed, 2003-07-30 at 01:28, Jeffrey P Shell wrote:[color=blue]
> Database Abstraction is another key issue. Zope gets points here not
> only for the built in ZODB database, but for SQL Methods / Database
> Adapters. There is nothing in Zope that is tied to Postgres, MySQL,
> Oracle, Sybase, SQLite, etc. Yet it's always been able to use any of
> them since before it was Zope. There's just a nice simple abstraction
> layer that one seldom has to think about.[/color]

Praising SQL Methods? Maybe I've been missing something, but SQL
Methods seem really primitive to me, certainly worse than the DB API
(though I suppose they preceded the DB API). The transaction stuff is
convenient -- if sometimes mysterious (like so many Zope things). But
it's not solving a terribly difficult problem.
[color=blue]
> Other tools try the O-R
> mapping route for abstraction with varying degrees of success.
> SkunkWeb has PyDO, Webware has one (I can't remember its name right
> now). Zope's model is nice because it's not intrinsic to Zope that
> you use SQL - it's just a nice model to plug into if you need it, when
> you need it. I don't know how other toolkits stack up here. Some may
> just say "go find a Python adapter that works for you and do what you
> want with it", which seems to be as good of a way to go as any.[/color]

PyDO and MiddleKit (Webware's) are both independent of their frameworks
(it's kind of unfortunate that they appear to be tied, though), as are
the other ORMs (like my SQLObject). All three provide something
approximating business objects built around database rows.

My impression of Zope's SQL Methods is that they encourage distinctly
un-OO style of programming, and instead everything is done through a
heap of ad hoc queries and eclectic query results. At least, that's the
code I've encountered, and it's taken discipline to avoid doing the same
thing -- maybe there are better ways to use SQL Methods than what I've
been exposed to. (If so, it would be better if Good Zope Style was
documented, not just learned through wisdom born of failure -- but I
haven't found that sort of documentation for Zope yet).

Ian

**Jon Ribbens** · Jul 18 '05, 01:08 AM

Re: Web tool kit : pro - cons ?

In article <240b1020.03072 92149.2cb95a13@ posting.google. com>, Jeffrey P Shell wrote:[color=blue]
> I work with some very talented designers. It used to be that they
> would give us (the developers) their designs and we'd rip them to
> shreds and they could never touch them again. Because now they were
> in little bits and pieces and stuffed full of tags-within-tags, with
> silly things like 'standard_html_ header' and 'standard_html_ footer'
> (never really fitting a technical definition of header once complex
> designs enter the equation) making it very painful to apply what they
> would thing were rudimentary design changes.[/color]

jonpy works around this problem while also avoiding the limitations of
XML. The templates contain no code at all except 
"magic comments" and $$name$$ replacements. Both of these survive the
files being mangled by HTML editors and keeping as much as possible
out of the HTML file means that if you get given brand new
from-scratch design it is still a quick job to 're-templatify' the new
HTML.

Web tool kit : pro - cons ?

Web tool kit : pro - cons ?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment