[Tutor] Python CMS advice wanted

Scott SA pydev at rscorp.ab.ca
Tue Nov 27 21:30:36 CET 2007

First-off, I have to appologize to the list for an accidental re-send of my original post. I didn't want to spam the list with an 'oops' message, but it seems appropriate now. If the other version gets caught by a moderator, it can be deleted - thanks!

On 11/27/07, jim stockford (jim at well.com) wrote:

Jim, great reply with valid points - only the reader can choose how to weight them for their needs.

>> Woah, I whole-heartedly disagree with this. Sorry!
>perfectly okay and somewhat hoped for. note the points
>* "cms systems have a big learning curve": largely true
>and often unsuspected how big.

Agreed, something like Zope sounds promising but it can easily become a rats-nest due to the 'magic' factor in the background.

As previously noted that I don't believe he is looking for a CMS but that seemed to be a good frame of reference for starting his quest. Now that "Frameworks" are on the table, his options are broader, simpler and certainly less bloated.

>* "might have more fun (and be more productive...":
>depends on his talents and ambitions, some people
>like coding despite the problems and responsibilities.

Possibly, but unlikely. Before you can use a pencil sharpener, you need to know what a pencil is (with mechanical pencils these days, this is not as silly as it sounds).

My point is, this being a 'Tutor' list and the expressed level of knowledge, it would be more informative for someone to learn how/why a framework has certain features by working with them, than trying to discover they need a feature.

The other nice thing about a framework like Django, for exampe, is it can be started quite easily and with it's automatic forms a novice can get a pretty decent site working in a short period of time. All the while allowing that person to write custom 'business logic' in python without a lot of contortions.

It's a high-level approach allowing for the user to drill down as they need.

Essentially, this _is_ the difference in our approaches: which end do you start with?

>>>    maintenance, especially by some one else, would
>>> be an area to worry about: each cms system has its
>>> own community of experts, a few of which are always
>>> available to help. your custom code would present
>>> new people a learning curve.
>> This is why I disagree: maintenance.
>> Oh yeah, how about: security!
>very good point, security.

I'd be a liar if I said I hadn't been bitten with this before... as would a lot of high-profile installations.

This is a double-edged sword. The gains you get from using a framework is the knowlege of others the sharp-bit is complexity which brings more opportunity to err.

>> Along with expediency, quality and a bunch of other things like maybe 
>> the OP would like a life too (i.e. not be a slave to supporting his 
>> own code).
>for sure one of the considerations, depends on his talent, ambition,
>and build-or-buy proclivity.

"proclivity", "a natural inclination", great word & thanks for introducing me to it... now back to the thread.

In my personal experience, the more a batch of code revolves arround _my_ view of the task, the more I become the sole point of support. It is a constant effort to make things clear, organzied and self-documenting. 

Having the separation of framework from customization is a reduction in volume of code to be maintained by the developer.

The sharp-pointy-bit to this is you are reliant on others sometimes for getting things fixed and exposed to the possibilty of breakage with upgrades. 

>> Frankly, the OP (Richard) does not really need the 'full-meal' of a 
>> CMS. He's looking for a templating system (cheetah, myghty, kid) and a 
>> mechanism to organize code into a web application of sorts.
>what are the learning curves of cheetah, myghty, kid?
>also,  http://screencasters.heathenx.org  seems at the lean end of the
>richness spectrum (per looking for a templating system), so of all
>possible python projects, his is within reasonable limits as a candidate
>for building from available modules (i.e. from scratch).

Hey, some things are better from scratch... like bread ;-)

My experience with Quixote was valuable from this perpsective. I got tired, though, of re-inventing things that already existed elsewhere. For example, we wanted to add breadcrumbs, not an arduous task, but we had to re-write it. That took resources, time to consider how it needed to work, code it then debug it.

>> Yes, some of the frameworks/CMS have small communities (quixote) but 
>> others (django, tubogears) are quite active. Still, each _do_ have a 
>> community and if th OP chooses one that has a critical mass (all of 
>> the above), he will find ample help to get over the humps & bumps.
>evaluating the community around a framework/cms product
>is an important part of evaluation.

... and everybody's measuring sticks are different. 

>> Do you think a person with emerging skills is going to create clean, 
>> elegant code that optimizes Python's strengths? No aspersions toward's 
>> Richard's skills, just going by his own remark: "I have a rudimentary 
>> knowledge of Python"
>certainly not: experienced coders generally code much better
>than in their pre-experienced state. Note the key issues are
>* does he want to take on coding
>* does his project reasonably permit his doing so (time to market)
>* is there some special customization he has in mind

Valid as a learning exercise, sure, or to maintain propriety, another reason. All good points but not necessarily a good _starting_ point. 

It helps knowing what you don't want as much as it helps knowing what you want. The evaluation of existing tools available can assist in both and only after that can one trully make an informed decision as to wether to build or buy, as you put it.

>> I don't mean to be critical of you; taking the time to express your 
>> constructive opinion is a valuable act. However, in this case I don't 
>> believe it serves in the best interest in the OP's requirements.
>your comments are very informative. this is a build-or-buy issue, and
>i hope what we're writing provides some helpful insights to those who
>are considering python projects, including richard.

Absolutely. If the least we've obtaind is the ability to ask better questions, then it is a net gain.

>> There are some truths to what I believe you were trying to say. Some 
>> CMS/Frameworks like Zope are to be avoided, IMHO, unless they satisfy 
>> some specific requirements (the Zope sites I have are a bear to extend 
>> for reasons outside the scope of this thread). They are bloated or 
>> just non-starters, but thankfully they are not the only options.
>it would be nice to have some comparative information
>on these products: does anyone know of a web site or
>other source that compares CMS/frameworks?

Ahh, now this is _where_ roll-your-own comes into play. Rough comparrisions i.e. "does it have xyz feature" are helpful in narrowing the range but a person really does have to take the leap and play with the tools. 

A really good starting point, IMO, is to scan the tutorials and documentation. Maybe watch a few videos and see which 'feels' the best. Then choose one that seems to fit the needs and dive into it with the tutorial or a small project.  Rinse and repeat as necessary.

Before I chose my current framework, I looked for comparative information. Since this is a moving target, it can only be a rough guide. I had to research more into the features available and see how they fit.

Some of the things I considered were how it interfaced with a DB. I'm an object-oriented guy so the ORM (object-relational model) was a consideration. The cost of that is performance as a site becomes more complex. If your db requirements are minimal then this may not be an issue or it may make the db interface so transparent you don't have to think about it anymore.

Another consideration was portability of code from one project to another - something I do frequently. How is that handled. If you don't move code, it doesn't matter as much.

Templating syntax and the separation of code from presentation was yet another consideration. Is it intelligently done and easy to work with? 

There are more things to think about, but I have run out of time for now.



More information about the Tutor mailing list