This is a screenshot from a fully functioning Django timesheets “app”. It took me about a day (mostly spent reading documentation) and about 100 lines of code in my Django model definition. 100 lines!
I weep when I think how many months and how much code it took me to do the same in Plone. (Complete with SQL storage, data validations, processing flow, and UI tweaks). Most of that time was spent getting Plone to store and retrieve my data in an Oracle database. Of course, my Django prototype didn’t “just” take a day… I had to write the Oracle backend for Django first.
The prototype isn’t done yet… but it’s pretty good for now. In particular, I need to tweak the stylesheets so all the parts of the page match the width of the “Time Entries” section. Also, I need to figure out a way to display the “read only” text description of the project/subproject code.
And since I’m not a graphic artist, how long would it have taken me to make it this pretty in Rails? Also notice that Django gives me a nice login and permissions scheme fully baked in with no extra coding on my part.
I think you are unjust with Plone. The problem with plone I suppose was the sql storage but try using django without its native store (for example using xml).
In the other hand i think that ‘months’ is too time, using archetypes and sql-storage, 2 or 3 days would be sufficent.
Link | August 15th, 2005 at 6:24 am
Seems to me Rails is way more generic overall and doesn’t claim an out-of-the-box admin interface, but rather “scaffolding” to use while you put the “real code” in place. While I’m trying to think you’re just pointing out the differences I can’t help but think it sounds like the digs and gloating common in Railsworld that I disdain… but I know you’re above that ;-) right?
Permissions, yeah… well that seems to be a perpetual “should have|shouldn’t have” for frameworks in every language (including python).
Link | August 15th, 2005 at 1:33 pm
pablo: Even if you use Archetypes, its sql storage still stores meta-data in the ZODB. (e.g. creation-date, modified-date, last-modified-by)… I need to be able to query those meta-data items from SQL just like the rest of my app’s data. There are some posted hooks (http://plone.sourceforge.net/archetypes/sqlstorage-howto.html) for getting all of your object’s data stored in the relational database, but you have to jump through a lot of hoops. I’ve also heard that Archetypes sql storage is inefficient with its use of sql and could use a fair bit of refactoring to make it useable in large volume sites.
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. :-)
Link | August 15th, 2005 at 3:48 pm
Jason: Try adding the class “superwide” to the body of your admin page to widen it up.
Link | August 15th, 2005 at 6:12 pm
Prettiness has very little to do with what web framework you use. Rails doesn’t come with anything that’ll magically make your app look “pretty”.
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.
Link | August 15th, 2005 at 6:56 pm
But isn’t that just the admin console?
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?
Link | September 28th, 2005 at 7:55 pm
“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?”
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…
Link | September 30th, 2005 at 5:19 am
If Oracle support gets added (and supported) into Django…that would be the deal clincher for me. All I have at work is Oracle.
Link | November 14th, 2005 at 11:33 pm
“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’m very curious about how this can be done. How did it go?
Link | February 24th, 2006 at 6:39 pm