Web programming ...

Fri May 7 05:02:52 EDT 2004

> If you're interested in CherryPy, you might as well have a look at CheesyPy 
> (http://sourceforge.net/projects/CheesyPy). Somewhat similar to CherryPy, but 
> different (and IMHO cleaner, but who am I to say? I developed it ;)) 
> implementation of the OO-framework on top of the base Web-Server.
> 
> CheesyPy is in no way finished yet (not even documented well enough, but 
> browse the source luke!), but the lower-level code which is demonstrated in a 
> simple sample application at the root of the package works out of the box 
> already.
> 
> The main difference between CherryPy and CheesyPy is the fact that CheesyPy 
> doesn't use a precompiler

I'd like add a few comments about this:

    - "Cleanliness":

I won't comment on the cleanliness of the "implementation" of the
tools themselves because I don't think it is very relevant. What
really matters is the cleanliness of the code that users write with
the tools (for their web applications).
Some tools will naturally encourage cleaner code than others, just
like python naturally encourages cleaner code than other languages
(who said "Perl" :-)).
In that area, I think that CherryPy has managed to keep python's
qualities.
Even though it adds another layer on top of python, developping a web
app with it still very much like writing regular python code and it
still encourages clean code: users almost never have to write extra
lines of code that don't have anything to do with the problem they're
trying to solve but that are needed because of the tool itself.

Also, people usually misunderstand the following two points about
CherryPy:

    - "Text generation":

I see 3 common ways of dynamically generating HTML (or any other type
of text). Let's say we have a variable called "name" that contains
"world". The 3 common ways are:
        (1) Embedding HTML in python: return "<html><body>Hello,
%s</body></html" % name
        (2) Embedding python in HTML (templating language):
<html><body>Hello, $name$</body></html> (or some other notation
depending on the templating language). I would also put things like
XSLT in that category.
        (3) The "programmatic" approach: return HTML(BODY("Hello, %s"
% world)) (or some other notation)

        CherryPy doesn't force you to use one approach or the other
because for each page (or even each bit of text) you can use whatever
approach you prefer. If you want to use a templating language,
CherryPy comes with a default one but you can also use another one if
you want (some people use Cheetah).
        I usually prefer approach (1) if the page has lots of dynamic
data and little static date, and approach (2) if the page has lots of
static data and little dynamic data.

    - The "compiler" effect:

A lot of people are initially put off by the fact that developing a
site in CherryPy requires a compilation step (it feels like going back
to the "C" age, doesn't it :-).
Well, in practice, this is never a problem ... The compilation step is
really fast (even for big sites) and I just have a 2-line script that
compiles the site and starts it ...
This compiler approach does have some benefits (otherwise it wouldn't
be there :-): Of course, speed is one of them, but also, several
popular CherryPy features (like aspects) couldn't be easily
implemented without this approach.

Remi.