This started out as a small comment to Paul Everitt’s post “Python, web frameworks, acts of good faith, making the case”, but it quickly became a long rant deserving its own space.
Having spent quality time with both Plone (2+ years) and Django (6+ months), I have some experience and basis for comparison between the two frameworks. I don’t have experience with Zope 3, however. So with Zope 3, I’m eager to hear some of that evangelizing that Paul is calling out for. I’ll need it after my experience with Zope 2/Plone.
I wrote a large production app with Plone in use at my employer for the past 2 years (our internal time and expense system). I never did anything “TTW” and started writing Python-based Zope products right from the start. But now, I’m using Django for future work. Plone, the CMS product, is great. Plone, the development framework, was fun at first, but frustrating towards the end.
I was first drawn to Zope because of Plone. And I was drawn to Plone because of its sexy web UI (I first spotted Plone when I saw the Plone banner at the bottom of python-in-business.org’s index page back in Fall ‘03.) I’m a developer, not an artistic UI guy, so any framework that automatically generates the UI bits for me gets extra points in my book. (Django now has those extra points for me.)
However, I live in a corporate “enterprise” environment where Oracle and LDAP support are musts. Our HR and Finance data are in PeopleSoft on Oracle, and we use LDAP to authenticate lots of internal apps. With Plone, I spent a lot of time “fighting the framework” trying to reconcile Plone with Oracle and searching for the right Zope/Plone LDAP product that would work with my configuration. And it seams every Python library I found needed special glue code for special use inside Zope/Plone. The more custom code for Oracle integration I wrote, the less I could use of Zope/Plone’s built-in features, like security ACLs, workflow, “free” CRUD templates from Archetypes, etc. All the documentation I could find just assumed the use of the ZODB. I went the ZSQL route and my reward was that I could use none of the cool features that originally got me so excited about Plone.
The last straw for me was when I spent a month getting Plone to work with Oracle via APE/Archetypes. Using APE/Archetypes had the promise of letting me use Zope’s ACLs, workflow, free CRUD forms, etc. all on top of a relational database. I learned a lot, but I was left with the impression: a) I was the only one on the planet doing Plone on Oracle via APE and b) Using Plone on Oracle via APE took alot of work. That uphill battle becomes a “downhill” walk when I begin with a framework that fully embraces relational databases from the start (like Rails and Django and TurboGears and web.py).
And yes, the ZCML stuff in Zope 3 is a big turn-off for me. And yes, if that went away, I would find something else to complain about… Debugging my syntax errors in APE’s XML config files has forever turned me off to the idea of configuration in XML. Plain old Python for configuration (as Django does) is great. If there’s a problem, I can just “import pdb; pdb.set_trace()” and start examining what went wrong. But if “XML config” went away, that “something else” would be Zope/Plone’s dependency on the ZODB (both code-wise and culturally among the developers and available documentation). I’ve seen some examples of using SQLObject in place of ZODB, but alas, SQLObject doesn’t have Oracle support, yet. I do see how Zope 3’s Interfaces made the ZODB/SQLObject swap-out easier to accomplish, but there’s still lots of un-fun boiler-plate work involved. :-(
I kept getting the feeling that the Zope and Plone communities just didn’t live in my world, even though “their” world is pretty darn fun, especially when coding and tobogganing with the Plone devs at the Snow Sprint last year in Austria! The Rails team absolutely lives in my world. And the Django guys mostly do (Though Oracle and LDAP support were missing at the beginning, I contributed patches to Django for Oracle, and just blogged about adding LDAP support.)
To me, Django feels like just another Python library… and I can plug in additional libraries (like ElementTree for XML or the python ldap library) with no pain or bondage required. The things I’ve seen of Zope 3 do say “its more pythonic”, but I don’t buy it when the next step says “now go edit this XML file”… and “now let’s write a Python interface class”. Yuck. Just let me import my little Python library and be done with it. I’ll add security and permissions if/when I need to. And then, after all that, the way URLs map directly to objects in Zope (and for that matter, the default way in CherryPy and by extension, TurboGears) is a downer, too. I prefer making them orthogonal to the code. When I view Django’s URLConf file, I can see in just 10 lines a complete site map of all available URLs that my app could respond to. This makes it easier for me to secure. With Zope/Plone, I always had a sinking feeling that there were lots of “unprotected” URLs exposed by Zope that I may or may not have secured properly. Again, this is probably different in Zope 3. And after all of that, don’t even get me started on reporting/querying data stored in the ZODB from the outside world. If the ZODB exposed data via an ODBC/SQL interface kind of like the way Lotus Notes exposes its object databases via NotesSQL, I’d be pretty happy, and it would mute some of the complaints I have with the ZODB.
Anyway, my point is… :-)… Teach me how Zope 3 “lives in my world”… Namely how can Zope 3 easily live in a world dominated by relational databases. And explain to me why writing interface classes and XML config files are necessary first steps when they’re clearly not in other frameworks. My hunch is that the reply will be “You’re going to need them someday”… Fine, give them to, but keep them hidden from me until I really do need them. Also, Zope used to use python-based configuration files, but then moved to XML. There were probably lots of internal debates about that and good reasons to make the change. Let me know why “Python based config files” are a bad idea and why XML-based are better. I may agree with you and “see the light”, but right now, I can’t see any good reasons for doing so.
So yes, I agree that Zope needs some evangelizing evangelists. Hopefully my rant here provides an outline of some points to comment on, critique, and provide answers to.
Rantfully Yours, Jason
Hi Jason,
Your rant is right to the point: Zope is much more an application than a framework.
> Let me know why “Python based config files” are a
> bad idea and why XML-based are better. I may agree
> with you and “see the light”, but right now, I can’t
> see any good reasons for doing so.
There are two good reasons not to write configuration files in Python: interoperability and security.
Practical interoperability requires the application’s configuration to be accessible from another environment, possibly by non-programmers who don’t have the skills, time or patience to learn Python, less so the Zope’s API.
Security requires the configuration to be valid, to not break the application and certainly not to be a potential exploit.
So, there is an overhead incured by parsing XML to call the configuration API instead of invoking it directly. However, the use of XML provides a “place” to validate that configuration before it is applied.
And, eventually, XML configuration files opens the administration of the application to others than pythoneers, using whatever XML editor they are found of, possibly enhanced with DTD validators that can filter out errors as early as possible.
Voila.
Link | February 2nd, 2006 at 5:49 pm
The ZCML stuff; is it really that annoying that that’s the reason you don’t want to use Zope3? How much of the total development do you really spend there? You get the package setup once and then you’re off to do what really counts. I haven’t tried it myself but isn’t there a script in zope3 that takes an interfaces file as input and creates a whole skeleton for you. Yes, I can understand that the ZCML is “XML sit-ups” you don’t want to do but if so, write a little script that uses ElementTree that imports the config from a python module and you’re done!
I don’t know enough about Django but having to maintain a big fat regular expression for URLs rather than objects/methods presence sounds like as much pain as maintaining the ZCML, but the ZCML you only maintain once (…give or take).
Link | February 2nd, 2006 at 7:57 pm
I suspect if Zope 3 got did a little convention-over-configuration, it could get rid of big swaths of ZCML. And probably without substantial changes to the framework — “convention” is just another word for “defaults”. Though debugging both conventions and defaults is no fun either, so I dunno — debugging explicit code you feel is unnecessary isn’t good, but debugging implicit code isn’t any good either.
Link | February 2nd, 2006 at 8:03 pm
Peter, sorry, I meant for the focus of my rant to be my frustrations with Zope’s code and cultural binding to the ZODB. My world (and the world where Rails and Django lives) is day-in day-out use of relational databases. The uphill battle that I had to fight being an “Oracle guy in a ZODB” world just got to be too much for me. Perhaps I should write a more focused rant on all the reasons why object databases are cool in theory, but suck in practice.
I don’t have direct experience with ZCML, but I do with APE’s XML config, which is pretty darn similar to ZCML. When there was a problem with the setup, I’d get really cryptic errors pointing to some weird line of code in the XML parser, and it took lots of digging to find where the problem was in the configuration. Perhaps, that’s just a problem with APE and the configuration parsing code, and not the XML format per se, and I shouldn’t project those frustrations onto Zope 3 and ZCML. But still, it was a frustrating experience. I’m left with the impression that XML for configuration is an unnessary layer of obfuscation in a Python app.
Regardless, I can see how someone on the other side could have a similar problem with Django’s URLConf and all those regular expressions (those can be slippery suckers, too!). I do appreciate Rails’ approach of “convention over configuration”… By leaving so much stuff as “default” system behavior, the amount of stuff that you do have to configure in some file is tiny compared to the amount of stuff that has to live in a ZCML file.
But again, my real rant is Zope’s close ties to the ZODB. If I had to, I could probably learn to live with ZCML… but I can’t live with the ZODB any longer.
Link | February 2nd, 2006 at 10:24 pm
Hi Jason. Thanks for taking the time for the comments and the writeup, and the follow-on comment. I wish I had time to do proper justice and parse the various points. I think we can learn a lot from someone like you.
Ultimately, I think Zope has to be clear if external data is a second class citizen or not. If so, that’s fine, because a lot of other people like the productivity win of the ZODB’s Python persistence. However, getting people like you to buy in on the features, only to find later that you’re on your own to make it work with your datastorage, only creates a bad reputation.
FWIW, I don’t buy the ZCML rant. [wink] More specifically, I don’t buy it when people complain about the XML nature of it. Syntactically, it looks pretty similar to an Apache conf file. However, I do buy complaints beyond syntax: that it goes beyond simple setup and into metaprogramming, and that tracebacks aren’t nearly as good as Python tracebacks.
Ultimately, I think the major question is whether Zope was ever the stack for you. Originally you just wanted the value of the Plone product. Later, the framework underneath started fighting you. It’s good that Plone gave value as a product, but we on the Plone side have to deal with the consequences of the second part.
For Zope itself, was it right for you? Zope has evolved into a culture of pluggability. Higher level semantics for how things connect, services that apply across resources, and replacability. If someone is a lone programmer, not working in a team with other designers, only interested in using Python libraries (and not ready-to-go stuff), that’s definitely not the sweet spot for Zope.
Whether the converse is true in reality is open to debate. It’s true though in intent.
Sure wish we had a first-class ORM story for you that was actively used by the core team. Until then, keep an eye on things like Jeffrey Shell’s Griddle Noise, which talk about ways to use Zope 3 stuff without the server, the ZODB, or ZCML.
Thanks again, Jason.
Link | February 3rd, 2006 at 4:37 am
Jason,
I’m with you at 100% percent.
I haven’t used Django yet, so I can’t tell anything about it, but I’ve made the dubious decision of using Zope 2 to write a mostly traditional web application (very few content management, a LOT of relational database access). That was 2 years ago and it seemed a good idea at the time (not a lot of mature web application framework at the time, I gave a look at Twisted back then and fleed when seeing the strange file extensions).
Now I’m regretting each and every day, and my colleague who has to maintain this even more so.
One thing which is pretty scary is that we are currently trying to upgrade our server from Zope 2.7 to Zope 2.9, and we are seeing a lot of deprecation warning, not from our code, mind you, but from Zope’s own code or from third party products whose support is slim at best.
We are quite anguished about the sheer possibility of migrating, but alas we think that if we don’t jump on another boat we might sink with this one. Should I say that in our current setup our Zope server has to be restarted every night, to clear a memory leak that dwell somewhere in the authentication system or the exUserFolder product ?
It’s very unpleasant to feel the foundation of your project slowly crumbling, and having to support the cost of forced maintenance and migration just because the developers of the framework told themselves “what the heck, let’s restart from scratch in Zope 3″.
Now it’s clear that as soon as we get a proper budget we’ll migrate to another web framework, for example the little one we built and use on other projects, based on mod_python, the publisher handler and an homemade templating system looking a bit like Velocity. But someone will have to pay for this migration…
One thing is sure, I won’t even consider Zope 3 ; too much kool-aid for me, thanks, I’ll try not to do the same mistake twice in my lifetime.
Link | February 3rd, 2006 at 3:59 pm
98% of my content types fit naturally into a hierarchal object model. Zope3’s component architecture makes working with a hierarchal object a breeze.
It took me a short while to get over the learning curve, but now the basics seem super simple.
Without Zope3, refactoring usually means rewriting. With Zope3, refactoring isn’t even necessary, you just add another layer of functionality or adapt an existing one.
It’s not for every project (especially relational model-based) but unless you have a dead simple project with permanent unchanging requirements, it’s worth investing a few hours learning how to wire a component architecture together with zcml.
Link | February 3rd, 2006 at 4:32 pm
I’ve got an experience similar to the one described by Nicolas Lehuen. A big web application had to be developed with few human resources, and the choice was to use Zope 2.7. It allowed us to to create a prototype assembled on the ZODB by glueing exUserFolder, ZPT templates, ZSQL methods and some Python scripts. The prototype was migrated to the filesystem, and the functionality was slowly refactored/rewritten into several Python-based products that extended the CMF.
Zope allowed us to deliver a prototype very quickly, and to make the “ZODB-to-filesystem” transition step by step, always maintaining a running system. But we’re now in a worrying situation:
What’s the lesson we’ve learned after this experience?
Now we’re thinking about migrating the application on some other web framework. We would just need some basic content publishing (files and documents) and a ZSQL-like class for recycling a few hundreds of SQL queries without having to rewrite them. We’ll see…
Link | February 3rd, 2006 at 6:49 pm
So you picked Django even though it has no Oracle support?
Link | February 3rd, 2006 at 6:53 pm
Lots of comments to reply to… but quickly, Robert, I was intrigued most by the rest of Django, so I thought I’d pitch in and write the Oracle support, myself. (“If not me, who?” went through my mind at the time.) My Oracle support patch should be coming in the Django 0.92 release. And I’ve been using Django on Oracle since I wrote the patch last August. I’m eager that this gets committed properly to the project so it doesn’t remain “custom” code that only I or my co-workers can maintain on-site.
I could have thrown my support into getting SQLObject’s Oracle support up-to-snuff. I still might do that, but I’m quite curious why several people have attempted it, and given up most of the way through. There is some basic support in a dev branch in the SQLObject repository; I’ve been meaning to try that out sometime. But man, with the all the billions that Ellison is worth, I wish he would throw a few over the fence into Python-land to fund some support for his databases!
Link | February 3rd, 2006 at 7:26 pm
limodou wrote:
[Django学习]没闲着，都忙呢
Link | February 4th, 2006 at 10:28 am
Here’s another vote of no-confidence in Zope.
My company’s reporting server used by clients is built on top of Zope 2.6, and like you our data is in Oracle, including the authentication DB. The whole Zope framework adds next to no value, while at the same time being incredibly cumbersome to manage, due to stuff being strewn all over the place, and the lack of a filesystem to rsync to. It’s so bad my developers have an almost physical aversion to writing new reports because we lose a week trying to implement something that would be done in a day in PHP or any other reasonable system.
I am in the process of reimplementing everything in Cheetah with a custom framework under the hood to handle database connectivity, navigation, access control and the like. Writing a mini-app server from scratch took me less time than wrestling with a single Zope report page. I can use a real editor instead of Zope’s web interface, for starters…
Link | February 6th, 2006 at 1:15 am
Interesting. I read this right after Benji Smith’s Why I hate frameworks. Worth a read if you haven’t seen it.
I tend to use Zope for websites I’m building and managing myself, Plone for those I think will be edited by others, and Django for anything primarily database-backed.
Learning Plone takes much too long, but I suspect that writing a CMS in Django would be pretty time-consuming. Not that most projects would need all the flexibility that Plone provides, of course.
The main reason I still use Zope is that I think ZPT is a very nice way to do templates.
Link | February 6th, 2006 at 5:58 am
> The main reason I still use Zope is that I think ZPT is a very nice way to do templates.
Quentin, if you want a light Framework with a zpt-like templating system, try Turbogears. Kid is very similar to zpt.
Link | February 6th, 2006 at 10:23 am
import this. » Blog Archive » Django vs. Zope wrote:
[...] out his experiences with Django and Zope, and it sounds like Django comes out ahead. Quoth Jason: To me, Django feels like just another Python library… and I can plug in additional libraries (like E [...]
Link | February 6th, 2006 at 7:01 pm
Hello Jason,
when I read your post, I smiled a little.
Because I was in a similar situation in January/February
2005. Let me introduce: My name is Holger
Froebe, I work for the IT of a university hospital
here in Germany (does this count for enterprise
requirements? I hope so.) – sorry for my crude
english.
………and now for something completely different ……….
We had some web-applications written in plone and
wanted to extend this stuff throughout the company
which failed via some of the reasons
(Integration of Oracle/User management) which you adressed
in your rant. The main goal of this extension project
was to ensure integrity of data stemming from
different sources (mainly Legacy systems, like SAP,
Oracle, stuff from File/FTP server, MySQL, SQLServer -
the whole spectrum ;-)
Why did we fail ?
First let me get one point clear: I think Plone has
its strenghts and merits and if you stay close to
the main street of its framework layout and its
original intention (see below), you can get very
satisfactory results – see Oxfam, Ebay-Developer Plattform,
Motorola and a lot of other impressive projects.
But if you look at its history, you see a pattern:
Plone started as a replacement for the User Interface of
the Content Management Framework (CMF) of Zope2. But
over the years more and more architectural
stuff slipped into the original Skin Package – which
suddenly became a framework of its own.
It started as one package – now
you have 13 (or so) Zope packages which constitutes Plone.
And this software stack got bigger with ev’ry release: There
is python, then comes zope, then plone, then put archetypes and
on top of it ArchetypesContentTypes. To add it, all this
stuff has strong inner dependencies.
So with all those dependencies
Plone slowly drifted away from its original goal (getting a more usable
+ visually appealing UI for Zope-CMF) and now does a lot of stuff
which should be done better deep down
in the software stack – may it be a pure python library
or a standard Zope Component/Product.
And that – to my totally personal mind – was the reason we failed
with a complex enterprise scenario.
If you’re interested in this point of view,
I’ll recommend you Chris Withers insightful talk
“Plone rocks my world” – http://www.simplistix.co.uk/presentations
………and now for something completely different ……….
But – What was the solution ?
We tried different approaches, but stayed
closely in well-known Python territory and rounded up
the usual suspects: TurboGears, Django, Zope3, to name
the most prominent.
And the winner was … Zope3 (now its time
to put on my fireproof suit, right ;-)
We started to work with it in Spring 2005 –
and we never looked back.
Man, this is such an amazing piece of software !
For me it’s like a piece of art ;-)
Everyday I work with it I’m getting more
enthusiastic about it.
Zope3 is build on some values which in my mind
really counts if you want to build an enterprise system:
= Avoid the Not-invented-here-syndrom
Zop3 is not the monolithic big framework like many
other appservers today, but a collection of loosely
coupled pieces where every piece has a clear and defined
responsibility and quality. There are a some
thousand tests to ensure the last one. You can use nearly every
of this little pieces (Zopies call them “components”)
outside Zope. This separation of concerns to the extreme
leads in a fast way to locate, isolate and remove errors –
that really saved some of my days in the last few months.
At the same time the Zope3-Guys build via ruthless refactoring a framework
which brings Zope-World closer to Python standard world
(stuff like WSGI, relational Database connectivity etc. – see
below).
Heck, you can even use Zope-Code for a client
app which doesn’t know anything Persistency or ZODB.
Yes, it’s true: You can write pure desktop applications
using Zope-Code without caring about ZODB – Example:
The CCPublisher2 rewrite of the CreativeCommons-Project,
see http://svn.berlios.de/svnroot/repos/cctools/publisher/trunk
or http://wiki.python.org/moin/PyCon2006/Talks#48
Or you want to use a collaborative tool for groups with
instant + slick visual feeling – try Bebop which strongly
relies on Zope3-Technologies on server AND client side.
…….and now for something completely different …..
The Zope3-Team discussed very thoroughly: What are the
core competencies of Zope and what not ?
For example: Zope2 had its own webserver – ZServer.
But why write and maintain such a beast when there
is something better in Python-World ?
So the Zope3-Guys integrated Twisted and
got best of both worlds.
… and now for something completely different …
Relational Databases and Zope3
You described very well in your rant the problems with Oracle.
This was nearly 100% identical to our experience,
so my smile from the beginning of this post
comes a little bit from the pain I left behind me.
With Zope3 there are two approaches:
a) Use cxOracleDA-adapter (http://svn.zope.org/cxoracleda/)
Looking at this source code I was amazed how easy and
straightforward it is to integrate a well-known and proven
python-Standard DB-Adapter into Zope3-world.
The same pattern again: Take a proven quality piece
of software from standard python world, put on a small wrapper
and – whoa – use it right away in Zope3.
Well, and then you could put sql-expressions into your templates
via sql-expressions (uhm, not really recommended ;-) or use
your zsql-scripts from Zope2.
But then we thought there should be a better solution,
which breathes the spirit of Zope3 … which led us to
b) an OR-Mapper-Solution
We tried SQLObject first, since it had a “native” Zope3-Integration
via sqlos. But Oracle connectivity is not one of the main targets
of SQLObject, despite there is a Oracle-SQL-Object-0.6.1-branch
in the repository.
PyDo2 from the Skunkweb-Project looked really promising, but
we had to put the name of the table into the class-definition,
so this was not flexible enough. Despite Oracle-Connectivity
was OK.
So we ended up with the best (shameless marketing)
enterprise ORM in python-world: SQLAlchemy (http://www.sqlalchemy.org)
Yes, there’s no official download and the developers
say there’s only Version 0.9.1 – but it’s pretty close to final 1.0
and it really suits our needs.
The great difference between SQLAlchemy and the rest of the bunch
is that other ORM-Mappers try to fit relational databases by all means
into Object-World. But a relational DB is no misled ObjectStore and
the whole analogy breaks more and more down with
– larger databases
– transactional aspects
– complex datasets/queries over many tables.
SQLAlchemy has the same philosophy as Z3 in
– extreme separation of concerns and
– integration of standard DB Adapters
– high quality of code + easy readability
(anybody said “pythonic” ;-)
– good quality of documentation
SQLAlchemy treats a Class as a Class, a RDB as a RDB, and
(you guessed it, right?) a RDB Table as a
RDB Table and connects them via mappers, which can easily
enriched with some standard methods/queries provided by
the framework.
It makes heavy use of the new dynamics aspects enriching
Python with the last few releases in the 2.x-line.
With SQLAlchemy I could drop the lines of code of my sql-related
stuff somewhere around 20-30%. And I REALLY like the approach
of “Writing less code”. Doing all my RDB-Stuff in python
is an extra-Bonus (OK, to be honest – some complex queries
survived, but I think this is only a matter of time, since
they vanish ;-)
So you’re not alone in Zope3-Oracle-World. To
cite the glorious A. A. Milne “And then there were three”
(and maybe even more, if someone answers this post ;-)
… and now for something completely different …
LDAP-Integration
Zope3 is very concise about Authentication via
so-called PAU’s – Pluggable Authentication Utilities.
You could easily plug together Authentication sources
with different Authentication methods – its as easy
as plug your lego-stones together.
Like in RDB-World: First you define an Adapter to your
Datasource – lets call it LDAP-Adapter, right –
which defines and holds the connection to your
external LDAP-Source (http://svn.zope.org/ldapadapter/).
That way, you could even use more than one LDAP-Source
in your Application.
Then you have another clearly defined LDAP-PAS (http://svn.zope.org/ldappas/).
which does the authentication against this Adapter.
And the whole beast (you guessed it again, right?) is a small,
well-defined wrapper around python-ldap. Plus
it’s easy to read and fast to understand (my 2 cents).
It’s like dejavu all over again ;-)
Hint: I just played around with this LDAP-stuff and never
tested that in our production environment,
but I have great confidence from my previous experiences
with Zope3 that it should be working relatively seamless.
… and now for something completely different …
ZCML
Well, everybody beats on ZCML, since its such an easy
target – “Hey, it’s XML – that’s bad. We don’t want
to use XML (for whatever ideological reason), so
Zope3 must be something ill-constructed”
If you ask me about my feelings about ZCML, I would
not try to convince you it was made in heaven and tell you
that you are too blind to see the light ;-)
But – as often in life: truth lies somewhere in
between the extremes. My 2 cents:
I share your feelings about not direct
debugging ZCML, despite the fact that Zope3.2 brings
very concise error-tracebacks.
The Zope3-Guys are aware of the problems users have with
ZCML. They try REALLY hard to bring as much ZCML back
to python as possible – see
http://www.z3lab.org/sections/blogs/philipp-weitershausen/20051214_zcml-needs-to-do-less
for a thorough discussion from one of the core developers
of Zope3. Looking from Zope3.0 to Zope3.2 (the current release) some
stuff vanished from ZCML, so those guys do their homework
and will do it even more on the upcoming Zope3.3 release.
The best thing at the end (now Z3-Team will really beat me ;-):
You can write up and use
ALL (right, ALL) ZCML-directives right away as python-code, if you don’t
XML.
And yes, this is even documented (call me old-fashioned,
but I read docs first). You may say, that there are such
a huge amount of README’s and other .txt-stuff spread
over the whole Zope-Project, that its not easy to get into it.
But Zope3 provides you with a toolscript
called “static-apidoc” which gives you a clear, concise
overview of the whole documentation as a static website.
Now if you look at the README under zope/component or
at the static-apidoc unter “Component Architecture”
you find methods like provideAdapter, provideUtility,
which do – surprise, surprise – the equivalent of
ZCML-alternatives. Or look at zope/component/site.py
or zope/configuration
You want to see this in action ? Look at this
2-part-example of a simple Z3-object publishing system
without any piece of ZCML:
Part I: The Zope Component Architecture –
Interfaces, Adaptation, and Duck Typing
http://griddlenoise.blogspot.com/2005/12/zope-component-architecture-interfaces.html
Part II: The Zope Component Architecture –
One Way To Do It All
http://griddlenoise.blogspot.com/2005/12/zope-component-architecture-one-way-to.html
Browsing through the docs, you can find the other
replacements in a straightforward way (or you debug
the xmlconfig-stuff from zope/configuration, which
gives you the corresponding callables for ZCML)
If that’s too tough and time-consuming – no problem,
ask on the Zope3-Users mailinglist. Those guys are
REALLY helpful to get you into Z3-world.
… and now for something completely different ..
Kool-Aid and the magic world of interfaces and adapters
Speaking with developers about Zope3 you often hear
that interfaces and adapters are too much magic and
they have to drink so much Kool-Aid to understand them.
I won’t put this here into a lengthy pro-con-discussion
of these concepts, since I’m not really a core developer,
but more an application developer/maintainer.
But to tell you my story:
It took me a while to GET the main ideas/principles
behind this stuff – to be honest,
2 days of intensive, dedicated work and 5 litres of H2O.
After one week of working with Zope3 I was more productive than
before. Plus I had learned a lot of new stuff about programming
in a quality way. Yes, dealing with Zope3 has made
me a better programmer – even if I never should do anymore project
with it ;-(
Plus it helped me to get my things done better + faster.
Well, that’s Kool-Aid I really like !
I wont’t say this world of interfaces and adapters
is the easiest to understand. But again:
There are a good amount of play-around-with-it-tutorials/docs/books
around which take you into Zope3-World. Just give it a try !
Want some examples? Want some simple apps to play around with?
Well, it was never easier than with Zope3 – see yourself
Here’s some easy stuff which you can work through in less than 1 hour
(well, the last example takes you longer ;-)
a) “Zope3 in 30 minutes” – at
http://zissue.berlios.de/z3/Zope3In30Minutes.html
showing you step by step how to build your first
simple Z3-application to collect your bookmarks on a server
b) Did I mention the magnificent Jeff Shell ? His blog
griddlenoise.blogspot.com is a rich and really insightful source
for getting into Zope3 – plus it’s really fun to read.
In his archives you find this funky little thing
http://euc.cx/toulouse/archives/simpletodoapplication/
(alternative http://worldcookery.com/files/jeffshell-todo/ )
where Jeff tells you how to build a Rails-like ToDo-Application
in some simple steps. In every step he shows you what
to do and why he thinks this implementation is carefully
thought out in Zope3 and what is the reason they did it this
and no other way.
c) Want a fresh new zope3-site without understandig “all the magic”
inside? Choose life – choose the z3 project starter
http://www.zope.org/Members/adytumsolutions/z3projectstarter/z3projectstarter_released
Answer a few simple questions and you have a project skeleton
to play around with without deeply understanding all this “kool-aid” upfront.
d) Philipp von Weitershausens Website/Book about Zope3 –
http://worldcookery.com
You will find more of this tutorials on Phillips website under
http://worldcookery.com/appetizers.
And this is not the end. New stuff is landing every day
in Zope3-space – like this little gem about events/notifications
and how they help you handle complex application
architectures:
http://remarkablysimple.blogspot.com/
Or you look at http://www.z3lab.org where you can get a peek
of the Zope3-ECM-Initiative and so on so on …
So, my advice to you: Fire on feedster.com, type in Zope3 …
and you’ll find a lot more of this diamonds.
I made the experience that most of the complaints about
Kool-Aid come from developers who specialized in certain
frameworks/habits and now had difficulties to extend
their mindset since they had to leave known territory.
They struggled with Zope3, found some hurdles and then gave up,
since “there’s so much kool-aid”.
I was surprised to find out that absolute newbies to programming
get productive with Zope3 very fast and easily –
maybe since they are not fixed on certain stuff.
I mean, sometimes I don’t get it: People want to write programs
for real complex enterprise scenarios, but at the same
time tell me it’s too hard to spend a few hours to play with some toy examples
and read some docs and play with the marvellous python command prompt
trying to push their brain into a new direction.
Believe me: This whole interface-adapter-pattern definitely helps
you in bigger/complex projects evolving over time.
Remember Fred Brooks Mythical Man-Month, which made so many of us aware
that change of requirements is inherent in any software project –
even if the whole system is in production use.
Zope3 has not ALL, but a lot of REALLY GOOD answers
to this situation every developer faces from time to time ;-)
… and now for something completely different ..
Querying the ZODB from outside applications
I’m convinced that it should be easy and I know
that the guys in the Bebop-Project did some stuff
in this direction, But I’m no expert in that,
since relational databases
constitutes more of my work. If you want to
have a profound answer on this – push it
on the Zope3-Users-Mailinglist (sorry, that
wasn’t a sufficient answer, right?). Those
helpful souls there will really show you
the best and easiest way to do it.
….. and now for something completely different ….
Coming back to your Plone-dissatisfaction
I don’t want to tell you that Plone is bad. Or Plone
sucks. Or stuff like that. For me it’s the right tool
for the projects it was made of – usable portal solutions
for medium size. The same holds for Django which
is also OK, if I want to make a fast RDBMS-UI-App.
The good thing is: For different work tasks there
are different tools in my toolchest. It’s my
responsibility to choose the right one for
every new project, but it leaves me with a
warm safe feeling that the toolbelt is filled
with such good quality stuff.
And the good news is just around the corner:
Plone and Zope3-World are converging – approaching
each other with every day. Now what does that mean?
Since I worked with plone it was easy to find my
way in Zope3-World. Zope3 tried to learn from
the Zope2 AND the plone lessons and put a lot of
the best breed of Plone (which constituted at the
same time those hard-to-manage architectural overhead)
back to the core of the framework. Well, this
is not totally right, since there is no such thing
as a monolithic core of Zope3-framework – the greatest lesson
learned from the problems with complex Zope2-projects.
Which is the best news of all ;-)
Know Archetypes ? There is schema-driven content-types
with form generation (zope.formlib)
Know Skins and Layers ? Use them right away in Zope3
Know Portlets ? Generalized to Viewlets and managed via ViewletManagers.
RessourceRegistries? Now known as RessoureLibrary.
… and so on … and so on …
But at the same time the Plone guys push their stuff
more and more towards the proven Z3-technologies –
and by handing over Z3 the framework responsibilities
the Plone community again can concentrate on being
the big shot at their homeground –
to provide you with the “MacOS of CMSes”
(well at least that’s what Limi told me ;-)
I also appreciate the other web frameworks
in Python world – and I’m happy to see that
there will be a “WebFramework”-Track during
Europython this year where zopies, djangistas
and turbogearianos and all those funky-stuffistas
will get into fruitful
discussions about solutions. I’m really
looking forward to this meeting since
we can learn a lot from each other
if we leave our minds open for the NEW.
…. and now for something completely different ….
There is so much more to say about this marvellous
piece of software (like the integration
of other templating languages like meld or clarity
or the integration of standards like Java-like Portlet-Stuff or
WFMC – the Workflow-Coalition – and and and)
but let me come to an end, since it’s really late
and I need some sleep:
I work for 20 years with software and applications.
Zope3 is one of the most professionall, mature
and qualitative outstanding frameworks I saw.
It’s really fun to work with, if you have a sense for
lasting quality solutions, if you want to be
proud of the stuff you created.
Thanx for your patience + Good night,
Holger @ Germany
PS: If you’ve got any specific question about Zope3,
drop me a not at booradley@web.de. Or visit some
of the links in my rant. Or subscribe
to the Zope3-User-Newsgroups and ask your questions.
This world is really full of possibilities ;-)
Link | February 8th, 2006 at 5:32 pm
Ah, and I forgot – the collaborative development
of my favourite Linux distro (Ubuntu)
is managed by a Zope3-Application -
see http://launchpad.net …
or the shiny Z3-based Schooltool if you want
to manage ressources and calendars …
see http://www.schooltool.org
Zope3 is really smoking ;-)
Link | February 8th, 2006 at 6:13 pm
Holger, You’ve pretty much answered every question/complaint I could possibly think of. :-) Comments like yours will go a long, long, long way to bringing frustrated folks like me back into the fold.
And, yes, I’m starting to understand that there’s still some learnin’ involved with a touch of Kool-aid required, but now its for completely different (and quite possibly) good reasons.
Thank you so very much for writing!
P.S. Didn’t know that about Ubuntu, ’tis my favorite Linux, too.
Link | February 8th, 2006 at 8:04 pm
Viva La Chipperfish » Ask Google: Python Web Framework Statistics wrote:
[...] rite Your Own Web Framework” “Zope, flames and the Koolaid remark” And this great comment sent to me on why Zope 3 deserves a seat at the table. Peace, Love, and Pytho [...]
Link | February 9th, 2006 at 10:23 am
Excellent post Holger!
I’ve been looking at web frameworks for a while and now you’ve piqued my interest in Zope 3. I had already made up my mind to skip its 2.0 incarnation.
I’ll also post a blog entry soon about your post once I get some time. :-)
Max in Kenya
Link | February 11th, 2006 at 5:03 am
Holger, I have to say that your post offers one of the best takes on why one should use z3. I would only add that the learning curve is steep, at least for me.. don’t expect to be productive in a few days. But, it is WORTH it.
Link | May 28th, 2006 at 9:00 am