cherrypy/cheetah vs twisted/nevow

[has]

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

> I'm not sure if I understand your point, and it may be the case that
> I'm really missing something. I think that, by its very definition,
> templating systems (including variables, conditionals, loops, and
> other control structures) *do* mix some aspects from the model into
> the view. 

You're confusing presentation logic with business logic. In MVC, only
*business* logic should go in the Model layer; presentation logic
belongs elsewhere. The Model does *not* dictate how the User Interface
layer(s) should receive input or present data. Think of the Model as a
complete program within another program, containing all the smarts
needed to do its job but providing no way for end-users to interact
with that data. All it supplies is an API into which user-interface
code can connect.

Aside from just being good architecture by minimising the amount of
coupling between code, such separation is genuinely useful. For
example, one should be able to plug any number of UIs into a single
Model to handle input and present data in different ways. Many Mac
applications provide at least two user interfaces out of the box: a
graphical user interface and an Apple event interface. Some implement
more, e.g. BBEdit also provides a CLI interface, FileMaker a web
interface. Web applications may provide a browser-based interface PLUS
an XML-RPC/SOAP interface. And so on.

A good mental test is to ask yourself: "If I remove the UI, will the
Model still function if I control it programmatically directly by its
API? If I replace the Model with an API stub that silently accepts
input and returns dummy data, will my UI still function? Can replace
one UI with another? Can I add multiple UIs, and will they all work at
the same time?"


> One may argue at which extent it's possible to keep both
> apart -- at some point, there must be an interface -- so it may be a
> matter of personal choice.

MVC is quite clear about where the interface goes: between business
logic and presentation logic.


> My current standing (after a long break from applications development,
> which allowed me to re-enter with a fresh perspective, but also a
> little 'rusty') is that the templating interface should be made
> simpler,

Oh, I agree completely. I wrote two other templating systems before
HTMLTemplate, and they were huge, complex beasts because I failed to
factor the problem adequately before charging ahead with the solution.
With HTMLTemplate I finally got it right. Whereas most templating
systems provide direct support for both presentation logic and markup,
HTMLTemplate implements support for the markup side only and leaves
the host language to take care of all logic. This gives a system that
is both extremely simple (turning markup into a simple object model is
trivial) and incredibly powerful (as powerful as the host language, in
fact, since that's what the presentation logic is written in).


> that the model should take care of the intermediation.

Absolutely not. Presentation logic belongs in the UI code, not the
Model.

With systems like Cheetah and TAL, the presentation logic is embedded
within the template markup itself. I don't like this approach myself
because it makes the template system responsible for supporting that
logic, adding a huge amount of complexity to it (something I learned
the hard way myself). See also Greenspun's Tenth Rule.

With PyMeld, Nevow.Renderer and HTMLTemplate, the presentation logic
goes in a separate Python script, where it clogs up neither business
logic nor HTML markup and makes the templating engine a cinch to
implement as the only thing it has to do is convert markup into a form
the script can manipulate - a trivial task.


> For example, I *feel* that repetitive elements (like
> lists and reports) shouldn't be modelled as programming loops inside a
> template. I really don't have a solution for this yet. 

This is presentation logic, so belongs in the UI layer(s).


> Albeit
> confusing, XSLT is a step in the right direction, but it sometimes
> feels like they're trying to fit a square peg into a round hole. 

XSLT is a basic declarative language beneath a really horrible syntax.
Like macro-style templating systems it spends an inordinate amount of
effort implementing a ridiculously complex and expensive solution to
what should be a trivial problem, then patting itself on the back for
its incredible brilliance and devotion to hard work for
successfully... reinventing the wheel (yet again). I find this sort of
thing terribly depressing, because it conditions people into thinking
complex solutions to complex problems are actually something to aspire
to, rather than avoid as much as possible. To quote Alan Perlis:
"Fools ignore complexity. Pragmatists suffer it. Some can avoid it.
Geniuses remove it." But anyway, I digress...


> Nevow implement a very intriguing idea: it allows to derive the *structure*
> from the template. 

Nevow implements six or seven extremely interesting ideas. I think its
biggest problem is it does this as one huge package rather than six or
seven independent modules, which makes it a bit of a bear to get on
top of and also cuts down on reusability which is a shame.


> I'm still looking, though.

I'd suggest looking at HTMLTemplate. It's simpler than Nevow.Renderer
and faster than PyMeld, mature, has no significant dependencies and is
small enough to pull apart and grok (and hack) quite easily:

http://freespace.virgin.net/hamish.sanderson/htmltemplate.html

It also maps well to the Apple definition of MVC:

- The View layer is constructed by the template compiler, which
converts HTML markup into a simple, specialised object model.

- The Controller layer is provided in the form of a callback function,
renderTemplate (the compiler attaches this to the compiled template
for your convenience) and some code to tell the compiled template to
render some data, and do something useful with the result. (Graham
Dumpleton has been working on a simple framework to handle all the
dogsbody work here for you
<http://www.dscpl.com.au/projects/vampire>.)

- The Model layer is entirely your own business; all it needs to do is
provide an API that your Controller can talk to in order to obtain the
data it needs to insert into the template.

(Admittedly, the trivial examples I've provided don't show separate
Model and Controller layers, but that's because they're too simple to
need a proper Model. I've done more complex stuff that does though,
and it works out just fine.)

HTH

has