The Hand of FuManChu - Latest comments on Eat less, exercise more

In response to: Eat less, exercise more

fumanchu [Member] — Sat, 08 Oct 2005 19:06:54 +0000

"Could you outline for someone familiar with Quixote what the difference is [in architectural style between CherryPy and Quixote]."

Sure. Here are some of them that I see:

1. Quixote requires a separate Publisher object, to which you pass your handler Root. CherryPy asks you to attach handlers to the cherrypy.root object.
2. Quixote is single-threaded by default. CherryPy is multi-threaded by default (and uses WSGI by default, to boot).
3. Quixote expects you to subclass a core class as your Root (is it required? you at least need q_traverse, I think). CherryPy expects the opposite (although it's permitted--see Subway's controller.Controller for example).
4. Quixote passes a request object to page handlers; if you want CGI params, you call request.get_field(name). CherryPy passes CGI params as **kwargs to page handlers; if you want other request data, you use cherrypy.request.xxxx.
5. Quixote has a "get" fetish IMO--get_user, get_environ, get_field... CherryPy tends to use "var = object.data" where Quixote users write "var = object.get_data()".
6. Quixote includes PTL. CherryPy is templating-agnostic.
7. Quixote mixes encoding, gzipping, the Expires header, javscript-inside-forms (!) and many other optional features into the core. CherryPy shoves those things into filters in its standard library.
8. CherryPy allows streaming output to any HTTP server. Quixote only provides it to medusa and twisted servers by default.
9. CherryPy has a comprehensive test suite. If Quixote has one, they've decided not to ship it with the distro.
10. Quixote's package architecture seems to be based on module/subpackage size. That is, if a feature has enough lines of code, it will get its own module, or subfolder. CherryPy has a separate /lib folder for app-developer imports (see http://www.cherrypy.org/wiki/PackageStrategy).

I'm sure there are others, and there are probably some errors in my understanding of Quixote. But those are some differences I see at the moment.

In response to: Eat less, exercise more

Hamish Lawson [Visitor] — Fri, 07 Oct 2005 13:11:05 +0000

"There's a decisive difference in architectural style between CherryPy and Quixote."

Could you outline for someone familiar with Quixote what the difference is.

In response to: Eat less, exercise more

Ben Bangert [Visitor] — Fri, 07 Oct 2005 01:39:33 +0000

By the way, this is what that code fragment should've looked like:
"live", :action => "status" %>

In response to: Eat less, exercise more

Ben Bangert [Visitor] — Fri, 07 Oct 2005 01:38:48 +0000

Having concise, easily understood parts make up the whole is something that appeals greatly to me. I've been working on my own little "mega" framework or whatever the word is for them, and the thing that stuck me is that you do make some gains by having some of the other parts included.

I was originally looking to see if I could use CherryPy with Myghty as the template language, but some of the abilities I gained when using Myghty for the controller aspect as well couldn't be attained (AFAIK) without a more tightly knit connection. Take this somewhat common thing thats done in Rails:

"live", :action => "status" %>

We're sticking the full HTML output of what is essentially another request, and putting it into the current page. I can do this if I use Myghty for both Controller and View since Myghty treats Controller actions/methods as components that can be included.

No clue how this would be possible using Cheetah, or Kid, or something where the template language doesn't know about the Controller that called it. So far in my Rails experience, Active Record is very decoupled from the rest of Rails. I've actually used Active Record by itself, its quite easy (Though I prefer SQLObject). However, the Controller/View code in Rails is tied much closer.

Definite advantages and drawbacks to both approaches.

In response to: Eat less, exercise more

Dave Warnock [Visitor] — Fri, 07 Oct 2005 00:09:26 +0000

I agree that CherryPy also needs to stay thin. The things I was talking about were to make sure that TurboGears does not do internally things that the CherryPy team would want to be part of CherryPy. For example at the moment there is

http://www.cherrypy.org/ticket/145 "Running multiple apps in one process"

which is something coming from Paste and TurboGears but seems like it should be part of CherryPy for it do it's own purpose properly. We don't want to make it harder to stay up-to-date with CherryPy by putting too much in TurboGear, but equally we don't want to add to CherryPy stuff that is TurboGear or Subway specific.

Thats a balance for us all to live with in all these projects, it's what keeps it fun ;-)

Dave