I’m very curious about how this can be done. How did it go?

Not really a problem… I’m planning on making the admin console my user-facing app. Of course, now I have the task of tweaking the UI and adding more robust security permissions so the admin console can be used by regular users… We’ll see how this goes…

i.e. when you want to make the front-end for it, you’re going to run straight into the “how long would it have taken me to make it this pretty in Rails?” problem, no?

As for “baked-in” login systems: after installing one of the various available login generators (via something like ‘gem install –source http://dist.leetsoft.com login_generator’), you can add a login system to any project by running ’script/generate login Auth’. And the same for tabbed navbars, search, sparklines (http://nubyonrails.topfunky.com/articles/2005/08/01/sparklines-now-gem-i-fied), PayPal payment system, etc.

That said, if Python is the language of your poetry, then Django looks to be a damn fine framework.

I want all of my site’s data in Oracle, not just some of it, because then I have a true separation of code and data when the lights turn off. With my data safely stored in Oracle, I can drop and recreate my Zope site when I release a new version of my app. With some of my data pickeld in the ZODB, I would have to write and run migration scripts to upgrade the meta-data. I do have to do the same in SQL when the schema changes, but I trust my SQL schema upgrade skills more than my Zope object upgrade skills. The alternative is to dump the ZODB data to file, release a new version, build out my site, and reimport my data. This dump/build/import cycle is what I do now with each Plone release into production. If I can avoid it, I’d love to.

Comparing Zope object schemas feels a little more opaque to me than comparing SQL table schemas. Also, with some of the schema in the ZODB, and some in Oracle, I now have to write two migration/upgrade scripts… doing it once is bad enough. Plus, I feel there is more collective wisdom in the universe surrounding the issue of relational database schema migrations than archetypes’ schema migrations. Altering SQL schema changes is more learnable, teachable, and googleable.

I spent lots of quality time groking APE to make it store all this data in Oracle, but unless you write custom mappers/gateways for your custom objects, your data will be stored as pickles. I spent lots of time trying to figure out how to “unpickle” data into readable tables. It’s possible, but there’s so much work involved… Things like ActiveRecord, SQLObject, and Django’s ORM make this a no-brainer for me. The fact that Django stores all its data (including meta-data and security roles and permission settings) in the relational database, too, is wonderful — there’s less there that needs “fixing”.

With Plone, I keep dreaming up and working on lots of crafty programmatic ways to get my data out of the ZODB and into my relational database. After a certain amount of effort, especially after long debugging sessions with APE, I start asking “why go through all the trouble?”

Without Archetypes or APE set the way the want it, I had to use raw ZSQL for my data access.. And since I wasn’t using Archetypes, I also had to had to create all my own ZPT forms and validation scripts… This is what took months to learn, code, and test. Basically, I was getting none of the benefits of Plone, except the nice user interface, which is what attracted me to it in the first place. Django provides a nice UI, plus an easier data storage option.

Another point, is that displaying tabular data (like the mini spreadsheet in my screenshot is a no brainer in Django)… Doing the same in Plone/Archetypes or Plone/APE was not easy.

So in a nutshell, if you want to live in a relational db world, it’s an up-hill battle in Plone. If you don’t need to live with with deep support for relational databases, Plone is fine. Don’t get me wrong, Plone the project is great and I enjoy and admire the developers working on it… And I had a great time coding and sledding with the Plone developers at the Snow Sprint in Austria. Plone is a well established project with a strong user community and some high-profile clients. I’d like to see Plone succeed. Perhaps, I’ll sponsor a Plone sprint of my own to fix my Plone/RDBMS issues. :-)

Okay, rant over. :-)

Permissions, yeah… well that seems to be a perpetual “should have|shouldn’t have” for frameworks in every language (including python).