Forum OpenACS Q&A: Response to Article on ACS x Zope
The only issue I really questioned with Zope currently was it's complexity in it's source code. No clear programmers documentation. A certain level of difficulty mastering it's code base.
On the surface it seemed as if ACS might deliver similar features but a simpler code base to master. On further review and reading consequent messages, I now longer believe that is necessarily the case.
OpenACS has invested significant time rewriting parts of ACSes code in order to use an alternative db. However regardless of OpenACS or ACS your still pretty well wired to a db not of your choice. aD is working on ACS 4.0. This is a major rewrite in order to as Philip puts it "to correct the sins of the past" (paraphrased). This rewrite will not necessarily abstract out any of the db parts. If it doesn't then the work is still required to 'port' ACS 4.0 to PostgreSQL. It will still be very db restricted regardless.
This somewhat demonstrates that ACS is different from Zope but not necessarily simpler.
ACS is a tremendous tool. If it delivers something you need, it can be a tremendous benefit. However, most websites contain much which is not touched upon by ACS. At that point you leave the benefit of ACS. Yes, you will still be in AOLserver, wait or is that Apache, no wait, it's Oracle. Oh well.
A lot of what Philip spoke of early has changed. AOLserver is no longer the platform. Tcl is not necessarily the language. There is no single language which defines ACS any longer. A little SQL, PL/SQL, Tcl, Java, adp, ... Then comes the new features with templates, etc. The knowledge and the skill set is broadening. Maybe the complexity too. Who knows? Who knows what's next?
Zope is not necessarily less complex. Digital Creations is working very hard to as Paul Everitt puts it "reduce the coefficient of complexity". Zope is probably somewhat more complex behind the scenes because it attempts to make the job easier for the 'user' of the Zope web development tool, not necessarily the 'developer'. Zope is great for managing content and users.
When I posted previously, I was concerned that adding Perl to what was previously perceived to be a single language tool was going to increase the complexity of the Zope machinery. From messages to the list and conversations with developers I know longer believe this. Factoring out the api necessary to be able make Zope elegantly handle multiple languages is requiring Digital Creations to improve the code. While doing so they are improving the developer api's and documenting them. :)
In the end, regardless of one's view of adding Perl to Zope, the machinery of Zope will be cleaner and better documented. This will no doubt improve the ability of DC to extend and add new features without exponentially increasing complexity.
A nice feature of Zope is it's transparent use of storage. One can create objects which model their data very easily. Zope will store them transparently in the ZODB. The objects can be modified, changed, extended, etc. and it doesn't affect the storage. This a major benefit to people who either want to quickly prototype a site, don't have the skills to use a RDBMS, or just don't want to use a RDBMS. As Ben Adida said, converting objects to RDBMS sucks (major paraphrase).
I happen to tremendously like ZODB. Coming soon is ZODB's ability to create multiple files, allowing one to partition their data as they see fit. Oh but RDBMSes already can do that you say. Yes, they can. But they don't dynamically alter the attributes/columns in their tables well. I can take a class or even just an object and add or subtract properties. ZODB won't care, it'll just go about it's business. ZODB is just as dynamic as Python. RDBMSes are not as dynamic as Tcl. ZODB is also storage agnostic. ZODB can use filestorage, Berkeley db, coming soon RelationalStorage (thanks Chris), and others as initiative and desire combine. ZODB has an api in which one can create a 'storage'.
If you prefer RDBMSes and SQL to ZODB, Zope can most elegantly accommodate you. Zope doesn't care if your using Oracle, PostgreSQL, InterBase, Sybase, Solid, ... You pick. You have legacy data and dbs, fine. Bring one, bring all.
Zope also leverages greatly inheritance and acquisition. These can provide tremendous opportunity to leverage data and code existing in various places in Zope. At any point in your development cycle you can see the need to do X and then remember code/data that you can inherit/acquire to fulfill your needs. This can often be done via an url without any coding. It's awesome.
In the end you can create a quality website with either tool. Delivering a high quality experience to the web sites visitor. The difference is in the philosophy of the developer and the tool. Each will deliver a different developer experience. If everywhere you look, you see objects. Choose Zope. If the world is a database, especially RDBMS, ACS may be your cup of tea.
I see objects everywhere. I've decided not try to fit my round world into a flat square world. Having said that, I don't think anyone will go wrong with either tool. Pick the tool which models your development philosophy. Enjoy your decision. It's a great day when you have fine choices. :)
