Entries For: 2006

I have been poking around with Django few days now. I have been doing Plone development two years, so pardon me if my comments on Django are inaccurate. Here is a bit mindflow pouring out of my head. Again pardon for not-so-well-ordered content.

On the blue corner...

Django is a web development framework. You can easily implement small site functionality on it. Django has a bit hype around it now when the father of Python, Guido van Rossum, named it as the preferred framework for Python web development.

Plone content management system/(running on Zope application server) is complete content management solutions which ships with tons of stuff like permissions. workflows, complete skinnable UI. Plone has been here for years, there are a lot of real companies doing web development and some developers estimated Plone installation base be several thousands.

Naturally both are open source.

Common for both of these web platforms is that they are based on Python programming language. Currently, Python is my favorite as a wrist saving language. Python has compact, easy-to-read, syntax: You type less - you are more productive.

Test-fix-restart

Plone takes aeons to boot (it loads nearly 10 MB Python code to memory). This makes Python code debugging painful, even on the latest monster machines. (Note: this doesn't concern CSS/HTML development). Plone used to have on-the-fly code replacing, but with the latest Plone/Zope versions it usually fails due to Zope 3 dependencies. Zope 3/Five doesn't support hot replacing code, does it?

Django boots in one second.

The best of both

Django doesn't have a hiearchial content tree which makes things like automatic navigation trees, permission inheritance, etc. difficult. On the other hand, a big part of Plone codebase internals deal with acquistision: you have extra things to worry about.

Django is good when you don't need through-the-web content editing, the content is mostly static and there aren't many people working on your site (permissions).

Also, Django is based on traditional relational SQL databases. Plone's object-oriented Zope database, though is better for hierarchial content like most of CMS deal with, is simply weird. This scares off management people.

Why Zope backend is better for CMS? For example, it has field level automatic permission support, hiearchy (SQL doesn't do trees very well) and built-in capabilities to deal with HTML (e.g in search). The high level of integration is also needed when building very high performance sites - tuning database access on product level à la Plone's Cache-Fu product is the only way to achieve high level dynamic performance for content.

Templates are a big part of web development, since in the end, it alls goes to down to ugly HTML hacking. Django uses its own template language. I wonder what lead to yet-another-template-language decision, since the world is already full of template language engines (Smarty, Velocity, XSLT bunch, Freemarker). Unlike Zope's TAL, Django is a generic string replacement language. TAL co-opereates with HTML tags so that it doesn't break the structure of template document. Though the latter might be more painful to write, I prefer it because in the end it gives you easier toread results.

Hype(r)space

Even though Plone is an old project, it lacks the marketing it deserves. Plone is tons of times more mature than Ruby on Rails & co. but when you mention Plone everyone is like "huh?". People even know Django better. I wonder where Plone would be today if it had buzz around it like RoR or Django.

Common woes

Let's hope that organic growth, one of my favorite topics, don't harm Django codebase as much as it has harmed Plone. Looks like Django already had some mixed styles in its coding conventions.

One common feature in nearly all community driven open source projects is that they grow organically - stuff gets added when people need it. People come from different backgrounds, have different principles and goals. You cannot command them into engineering discipline like in big corporation world. This leads to tangled codebase.

I have been working with few Python based open source projects (Plone, Zope, Django and Python itself, all community driven) and then with Java projects (Eclipse, IBM led).

• Community driven code borns through natural evolution
• Corporate driven code borns through design and discipline
  

In my opinion, the strong lead might lead to higher quality code base which is more fun to work with (i.e. gives less headache).

• If there are big payrolls involved someone is usually paid to create documentation and there might be even useful comments in the source code due to formal reviews. Less try-to-see-how-it-works, less dive-into-source, less headache.
• The style is consistent. You don't see code like MyClass. my_function(). getAnotherFunction(). isthisreasonable().  Java has standard coding conventions, when Python lacks them. The result is eye hurting soup to read. Since good auto complete is nearly impossible to implement in Python IDEs, double checking function naming is even more PITA.
• More polish. You won't find XXX, TODO, etc. in code in a critical moment when you thought the subsystem was already working
• After things are once done without too much thinking, phasing them out is difficult. "This method will be deprecated" warnings may stay in the code many years.
  

In community driven open source projects, at least code conventions could be forced in the scope of the project itself. Other kind of strict rules might not work. Decrease too much the degree of the freedom and soon you don't have committers at all.

I have myself patched some Plone products. It's very unmotivating when your freshly baked cake gets tossed away when the codebase maintainers point things you are not interested in and thus your patches are rejected.

Plone's stock search functionality has several shortcomings

• Search form doesn't utilize Plone's content model and is based on scripts containing a lot of hard coded location information, making customizing and creating variants difficult.
  
• Plone's Smart Folder functionality provides rich search criteria, but doesn't provide easy end user interface to do arbitary queries - searches are static, created by the site manager.
  
• The underlaying architechture, Zope's ZCatalog, doesn't support boolean queries or multiple sort keys.

• According to the research (sorry, Finnish only!) made at University of Jyväskylä, Plone's default search result listing can be confusing. Try it yourself: go to plone.org and type "Eclipse" to the search field. The first hit is a screenshot instead of the tutorial you are probably looking for.
  

• Searches don't utilize content type in the ranking, only word counts in the text matter.
  
• The results lack location information. If there are similiar titles under many folders, the result will be ever more confusing. A simple use case would be a folder per company department, each folder having "personell" page. One couldn't distinguish pages from each other in the result listing.
  

A new product, Custom Search,  addresses these problems

• Search forms are Archetypes based objects, meaning they appear in the navigation tree, they have permissions, etc.
• Adding new forms and search fields can be done through-the-web easily If you have need very custom code, the search items can be extended using the normal class inheritance and schema magic which is used for the all Plone content types.
  
• Numeric, boolean and ranged search indexes are supported. This is useful if your content types have attributes like a price.
  
• Custom Search uses AdvancedQuery product by Dieter Mauer as a backend. AdvancedQuery monkey patches ZCatalog to support boolean queries and multiple sort keys.

Here are some screenshot examples what Custom Search can currently do.

For some use cases, Custom Search is already very usable. It still lacks some functionality like batching support (all search are displayed on one page) and adding boolean conditions to the queries.

The Earth is calling