cherrypy/cheetah vs twisted/nevow

[has]

Carlos Ribeiro <carribeiro at gmail.com> wrote in message news:<mailman.6085.1099850448.5135.python-list at python.org>...

> I agree that presentation logic (the term that I was missing) is
> different from business logic. But I still think that the more you can
> take the presentation logic *out* of the HTML template, the better.

Absolutely no disagreements there. :)


> I may be wrong, because I never programmed Macs, but I think that in
> the original Apple MVC implementation, you had "resources" (that
> stored the form definitions), and there was code to fill the form with
> data ("presentation logic", right?). 

Correct. Apple refer to the former as View and the latter as
Controller, a careless choice of terms that's bound to cause plenty of
confusion amongst folk who follow the original Smalltalk definition
(e.g. webapp developers). The View - windows, menus, etc. - is
constructed from live GUI widget objects using a visual editor. These
objects are then serialised and stored in the application's resource
fork/bundle to be reconstituted each time the application is run. The
Controller is written in the implementation langage just like any
other code, and is responsible for (1) handling input received by the
View and manipulating the Model in response, and (2) updating the
View's appearance as necessary whenever the Model sends notification
that its state has changed. BTW, you'll also find this pattern in the
Renaissance framework <http://www.gnustep.it/Renaissance/>, except it
stores Views as XML instead of binary data.

Being Mac-based myself, this system became a major influence in the
philosophy and design of HTMLTemplate. I wouldn't be surprised if it
also influenced the designers of similar templating systems (Donovan
Preston, for example, is a Mac user).


> This example shows one
> of the problems with (many) templating systems; one has to write both
> the 'resource' (the HTML Template) and the 'presentation logic' in the
> same file.

I think this approach has its niche, particularly in shrinkwrap
applications aimed at non-programmers where a small, simple, very
low-abstraction macro language with a fixed, limited featureset is
needed to allow a degree of template customisation. Something like
Fogcreek Software's CityDesk application might be a good example.

For professional web application development, however, I think it's a
very poor approach; an expensive exercise in make-work. I came to
programming from design, btw, and the major motivation for writing
HTMLTemplate was to create the sort of templating system that I as
designer could work with: one that didn't stink up my lovely markup
with great gouts of ugly, unfriendly code.

Graphic designers shouldn't be forced to take responsibility for
programming, and programmers should be free to write code unhindered
by alien markup and visual concerns. Templating systems are meant to
make application development easier, and any templating system that
causes designers and programmers to stomp all over each other's toes
seriously fails in that respect. (I think PHP and its kind have a
great deal to answer for in setting the craft of application design
back by years, if not decades. Blech.)


> Now, I'm reallly struggling to catch up with a lot of stuff, and I
> don't know about HTMLTemplate, so I have to take your word for it; you
> say it's good, and it separates the presentation logic from the
> template, and that's what I am looking for. I'll check it now. Thanks
> for the all the info.

Good luck, and feel free to fire away if you've any other thoughts or
queries.

has