[Tutor] Python CMS advice wanted

[Scott SA]

On 11/27/07, Richard Querin (rfquerin at gmail.com) wrote:

>After reading it all I'm wondering if maybe a templating system like
>Cheetah might be the way to go for us. I'll have to do a lot more
>reading and exploring.

Sure. Be wary of any system that allows the template to freely call python i.e. one system I've seen:
    <python: eval('unrestricted python code')/>

... 'nuf said.

>I'd love to learn something like Django but
>like it has been said, that's really a framework you'd use to build a
>CMS. And this site is really a labour of love and not a business
>venture so the time we invest into it at the moment is kind of in
>short supply.

There are a couple of 'screencasts' on 'showmedo.com', one of them is here:
    <http://showmedo.com/videos/video?name=1100000&fromSeriesID=110>

... it's the typical "Build a wiki in 20 minutes" dog 'n pony show, but you do get a feel for some of the key features.

There is a pretty direct line between the request and rendering a response. Everything arrives in a dictionary and is returned in a dictionary, usually with a template spec'd but can be direct too (this isn't totally unique to django, I'm just illustrating the concept).  URLs are parsed using regular expressions, a portable skill so it's not a framework-specific element and IMO doesn't count in the 'learning curve'.

A big difference between templating systems is how 'active content' is described. Some templating structures use embedded python within custom tags. This is not the case with django and for some that is a deal-breaker, others it is a deal-maker. It's pretty feature-rich, but _does_ have its own (well documented) syntax using curly-braces ie. {{ dict.item }} or {% ifequal %}.

The db interface is straightforward and much of it is managed for the developer, including the table creation; a single command-line call. There are a few gotcha's when you want to do some complex queries, but for most things it is straightforward and capable. There is the ability to use raw SQL, so the developer isn't 'trapped'.

Each table is defined as a python class with field-names as class-attributes and the class-name typically as the app & table-name i.e. 'thisap_apptable'. 

The developer can then define methods within each of the classes to do most table-related things i.e. custom type-chekcing, agregation of fields and so on. Quite pythonic indeed. (you could check out SQLObject for similar functionality in an independent library)tutor at python.org.

Again, much of the required skills are very portable and not framework specific. This was a selling point _for_me_, it feels natural to work with. It's automatic admin forms were another bonus, allowing the developer to focus on more important things. Did I mention the automatic forms???

It has a built-in server as well, typically for development and dead-simple to start/config. From the main project directory the call is:
    python manage.py runserver

... an optional port number can be added.

"manage.py" is a set of utility and maintenance scripts for creating the databases, seeing what SQL is generated and so on.

Still, as much as _I_ like this framework, I fully recognize there are good reasons why others exist and respect their capabilities. I don't want you or anyone else to use this because I said so, but because after review it is what meets your needs. 

All the best,

Scott

PS. In fact, I fully intend on exploring Pylons (and now Webpy) in the new year - nothing is perfect for all circumstances.


>While we have less than 50 entries at the moment, adding each one is
>still quite a hack. I've written a small wxpython app to take away
>some of the pain of it, but it's still prone to corruption and still
>too much work.
>
>I think I'll have to watch some demo's to get a feel for how some of
>these systems work before going down any specific path, because a lot
>of it is still Greek to me.
>
>Again sincere thanks for all the great info, and I'll try to check
>back in on this thread once we get going on a solution.