cherrypy/cheetah vs twisted/nevow

[Charlotte]

I am developing a web application and am looking for the best framework
to do this in. I know this is an old question, and I have read the list
archives and a couple of comparison pages on the web. I played around
with some, and I have reduced my choices to two very different
frameworks: cherrypy+cheetah and twisted+nevow.

I am writing the prototype in cherrypy with cheetah, and I like it
very much. I am very impressed with the speed of development, and
cherrypy seems to fit the way I think. Before this I used webware, but
cherrypy is simpler and easier and does the things I want very well.
Cherrypy is being completely redesigned at the moment. The 'old'
version is no longer developed, the new version just had the first
alpha release. While the new version looks promising, I am uncertain
that it will be ready for production use very shortly. I can of course
just use the old version, which is stable.

Because of my doubt, I went looking for alternatives, and stumbled
upon nevow. I now absolutely think this is the way a web application
should be developed. I like the way ui and code is seperated, I love
formless, and livepage looks very promising. However, it is still
beta, and reportedly rather difficult to use.

The application should have a first version finished in about six
months. Security is very important. The users of the application are
fully trusted, so the most important in this regard is authentication
(and encryption, of course), I think. I could, if needed, just code this
myself. It is a relatively small application, at most a few thousand
users, who will not be using the application, much less sending
requests, at the same time. At the moment I do not expect to use much
of twisted's great possibilities.

Any ideas on what you would do, would be most appreciated.

Charlotte.

 

[Carlos Ribeiro]

I am developing a web application and am looking for the best framework
to do this in. I know this is an old question, and I have read the list
archives and a couple of comparison pages on the web. I played around
with some, and I have reduced my choices to two very different
frameworks: cherrypy+cheetah and twisted+nevow.

I am writing the prototype in cherrypy with cheetah, and I like it
very much. I am very impressed with the speed of development, and
cherrypy seems to fit the way I think. Before this I used webware, but
cherrypy is simpler and easier and does the things I want very well.
Cherrypy is being completely redesigned at the moment. The 'old'
version is no longer developed, the new version just had the first
alpha release. While the new version looks promising, I am uncertain
that it will be ready for production use very shortly. I can of course
just use the old version, which is stable.

Hi! That was the same reason that got me hooked on CherryPy: it's
simplicity, and the fact that it seemed so 'obvious' to use. As for
the redesign, I'm already using the CP2 alpha project for a few
projects of mine. None of them is 'life critical', and I'm not using
all features, but it seems very stable to me right now. The main
difference is that CP2 is now 'pure python', with no intermediate
compilation step, which makes it even more natural to use than before.

Because of my doubt, I went looking for alternatives, and stumbled
upon nevow. I now absolutely think this is the way a web application
should be developed. I like the way ui and code is seperated, I love
formless, and livepage looks very promising. However, it is still
beta, and reportedly rather difficult to use.

I'm yet to study nevow, but I'm getting more and more interested. I
have my own approach to separation; I use to think about a third
entity, "structure", as being independent from code & ui. The
structure is the common part; it's the "glue" between ui and code; and
it's the first part to be designed. I'm still experimenting with this
concept. For what I have read so far, nevow seems to follow a similar
approach, although I haven't seen any reference to "structure" as a
third element in the design anywhere.

The application should have a first version finished in about six
months. Security is very important. The users of the application are
fully trusted, so the most important in this regard is authentication
(and encryption, of course), I think. I could, if needed, just code this
myself. It is a relatively small application, at most a few thousand
users, who will not be using the application, much less sending
requests, at the same time. At the moment I do not expect to use much
of twisted's great possibilities.

For what I know, twisted is a huge beast, and forces you to a totally
different programming paradigm. There is a wsgi gateway for twisted in
the works, and that may make things simpler for pure web development,
as it will hide some of the inherent complexity of twisted async
design. For my own needs, I still prefer to stay with CherryPy.

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: (e-mail address removed)
mail: (e-mail address removed)

 

[Valentino Volonghi aka Dialtone]

I'm yet to study nevow, but I'm getting more and more interested. I
have my own approach to separation; I use to think about a third
entity, "structure", as being independent from code & ui. The
structure is the common part; it's the "glue" between ui and code; and
it's the first part to be designed. I'm still experimenting with this
concept. For what I have read so far, nevow seems to follow a similar
approach, although I haven't seen any reference to "structure" as a
third element in the design anywhere.

What you call structure in Nevow is a flattener IMHO. Basically:

From a XML/HTML file Nevow builds a Stan Tree which is a simpler DOM
implementation (You can provide your own implementation of this parser/DOM
builder to Nevow, since the framework only cares about the resulting Stan Tree).
Then, when a user connects to your site, the stan tree is flattened, which means
(in nevow-speaking) that nevow iterates through the stan tree directly returning
simple strings and adapting dynamic components (directives, slots, patterns and
so on) to something that knows how to provide an html/xhtml version of the
object.

So the adapter and stan should act like your structure.

For what I know, twisted is a huge beast, and forces you to a totally
different programming paradigm. There is a wsgi gateway for twisted in
the works, and that may make things simpler for pure web development,
as it will hide some of the inherent complexity of twisted async
design. For my own needs, I still prefer to stay with CherryPy.

I actually think that Nevow was the first Web Toolkit to provide wsgi support
built-in. And it could be used also without Twisted but as a CGI.

 

[bruno modulix]

Carlos Ribeiro a écrit :
(snip)

I'm yet to study nevow, but I'm getting more and more interested. I
have my own approach to separation; I use to think about a third
entity, "structure", as being independent from code & ui. The
structure is the common part; it's the "glue" between ui and code; and
it's the first part to be designed.

Err... I may have missed something obvious, but doesn't this smells like
a good old MVC ?-)

 

[Carlos Ribeiro]

Carlos Ribeiro a écrit :
(snip)

Err... I may have missed something obvious, but doesn't this smells like
a good old MVC ?-)

In a way, you're right. The problem is that none of the templating
models that I know of completely separates the 'M' from the 'V'.
Simple templates (PSP, for example) tend to bundle view & parts of the
model together. There is no easy way to take them apart. The
'structure', as I call it, is not exactly a 'model' (imho the model
includes other information that belongs in the DB design, but I may be
wrong here), but it allows for a better separation.

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: (e-mail address removed)
mail: (e-mail address removed)

 

[has]

In a way, you're right. The problem is that none of the templating
models that I know of completely separates the 'M' from the 'V'.

Plenty of templating systems allow Model-View separation. Not all
*enforce* it, but this is a matter of philosophy [1], not an indicator
that a template system is good or bad.

Some templating systems (e.g. Nevow.Renderer, PyMeld and HMTLTemplate)
additionally separate presentation logic from markup via an approach
that's strongly reminiscent of Apple-style MVC, where the View layer
consists purely of GUI widget/template node instances and the
Controller layer contains code for (1) manipulating these objects and
(2) connecting to the Model layer.

HTH

has

--

[1] i.e. just an excuse for BDSM freaks and godless liberal Lispers to
have a good rammy now and again. Any competent developer will
automatically build a well-layered system, and no amount of nannying
is going to save an incompetent developer from themselves.

 

[Carlos Ribeiro]

In a way, you're right. The problem is that none of the templating
models that I know of completely separates the 'M' from the 'V'.

Plenty of templating systems allow Model-View separation. Not all
*enforce* it, but this is a matter of philosophy [1], not an indicator
that a template system is good or bad.

Some templating systems (e.g. Nevow.Renderer, PyMeld and HMTLTemplate)
additionally separate presentation logic from markup via an approach
that's strongly reminiscent of Apple-style MVC, where the View layer
consists purely of GUI widget/template node instances and the
Controller layer contains code for (1) manipulating these objects and
(2) connecting to the Model layer.

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

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, not more powerful, and that the model should take care of the
intermediation. 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. 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. Nevow
implement a very intriguing idea: it allows to derive the *structure*
from the template. I'm still looking, though.


--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: (e-mail address removed)
mail: (e-mail address removed)

 

[has]

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

 

[Carlos Ribeiro]

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.

Well, there are lots of stuff that deserve commenting here. But I feel
that we aren't very far from each other (though my terminology
definitely needs improvement .

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.
That's my point when I talk about the reporting example.

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?). I have a lot of experience with
Delphi, that is also based on the same concept. In both cases (Apple
and Delphi), the resource is clearly separated from the code; they're
in separate files, and use different languages. 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.

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.

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: (e-mail address removed)
mail: (e-mail address removed)

 

[Charlotte]

Hi! That was the same reason that got me hooked on CherryPy: it's
simplicity, and the fact that it seemed so 'obvious' to use.

Yes, I continue to love it. I wonder why it is not much more used.

As for
the redesign, I'm already using the CP2 alpha project for a few
projects of mine. None of them is 'life critical', and I'm not using
all features, but it seems very stable to me right now. The main
difference is that CP2 is now 'pure python', with no intermediate
compilation step, which makes it even more natural to use than before.

Yes, I like that very much. It makes it also much easier to unittest.
Would you be willing to share your experiences with CP2?

I'm yet to study nevow, but I'm getting more and more interested. I
have my own approach to separation; I use to think about a third
entity, "structure", as being independent from code & ui. The
structure is the common part; it's the "glue" between ui and code; and
it's the first part to be designed. I'm still experimenting with this
concept. For what I have read so far, nevow seems to follow a similar
approach, although I haven't seen any reference to "structure" as a
third element in the design anywhere.

This is the way I like to organize my code to, and I have now found
out that HTMLTemplate also works like this. Which is great, because it
works with CherryPy.

For what I know, twisted is a huge beast, and forces you to a totally
different programming paradigm. There is a wsgi gateway for twisted in
the works, and that may make things simpler for pure web development,
as it will hide some of the inherent complexity of twisted async
design. For my own needs, I still prefer to stay with CherryPy.

I decided to stay with CherryPy for now. HTMLTemplate does a lot of
what I liked in Nevow. I liked formless, but that is not that
important, and I can implement xmlhttprequest things myself. What I
really like about CherryPy is that I understand what is going on. In
Webware, I was just following examples, and it worked, but I found it
rather complicated, with al the Kits I never used. And I know Webware
is actually supposed to be simple...

Thanks for your input, and I would like to know how you like
CherryPy2, as your work progresses.

Charlotte.

 

[Charlotte]

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

Thanks for your explanation. I took a look at your website, and
HTMLTemplate seems to be very nice indeed. I wonder why I had not
discovered this before.

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

I completely agree.

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.

And I agree again.

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

Well, you know how to sell your product

Thanks.
Charlotte.

 

[has]

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

 

[Tim Roberts]

Yes, I continue to love it. I wonder why it is not much more used.

Do you expose the CherryPy server directly to the public, or do you run a
proxy through Apache?

I also find CherryPy very natural and easy to understand, but I'm concerned
about deployment issues. Every site I do has to share the serverspace with
other web apps.

 

[Carlos Ribeiro]

Do you expose the CherryPy server directly to the public, or do you run a
proxy through Apache?

All my current work on CherryPy is for Intranet deployment. I'm using
it to deploy webapps, and I found it quite easy to work with. Very
pythonic IMHO

I also find CherryPy very natural and easy to understand, but I'm concerned
about deployment issues. Every site I do has to share the serverspace with
other web apps.

I was also somewhat concerned about it. I have heard that some sites
are using CP for public web servers (I found CherryPy reading a blog
post where the author commented that the blog engine was based on it);
but I do not have more information to back it.

There is a company specialized in hosting Python applications, and
they do support CherryPy. Take a look at: www.python-hosting.com. I'm
not affiliated with them, but hey, they already host CherryPy
development, so I guess they deserve mention

--
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: (e-mail address removed)
mail: (e-mail address removed)