Death to ZClasses!!! ==================== By Max M. 28-05-2002 10:42 I have used Zope for a few years by now and have developed both in zClasses and Python products. While zClasses seems nice when you start out, you will soon be bitten by their subtleties. So you save a little time by not doing a Python product at the beginning, but soon you loose that time, and more as you struggle with the zClasses. I have written this document to help other people see why zClasses are "A Bad Thing". I think that way to much effort is wasted in documentation and development using zClasses. If all that energy had been focused on Python products, Zope would be much easier to use and program for everybody. so DEATH TO ZCLASSES! ;-) It is hard to change the base classes with ZClasses --------------------------------------------------- Sometimes you make a mistake, or you forget to include a base class when writing a product. So you want the ability to add them later. The order in which you subclass classes matters. Sometimes you do it wrong, and you want to change it. zClasses makes this difficult. Example:: class myFolder(SimpleItem, ObjectManager): "This won't work as SimpleItem has a method called ObjectValues that allways returns an empty tuple" class myFolder(ObjectManager, SimpleItem): "This is The Right Way as the it will call ObjetManager.ObjectValues() so yuu get the expected result" Ok you made the mistake. Now try and fix it ! Subtle changes when changing meta type -------------------------------------- If you change the meta type of a zClass you have to also change the add List name, in the zClass' factory to be able to add instances through the Zmi. That is at least when you have a Python Based ObjectManager class that uses the ZMI. It also breaks the ability to cut/copy/paste/rename those zClass objects It also makes the little + dissapear in the tree view so you cannot expand the Objectmanager based zClasses. Makes it harder to learn what Zope actually do ---------------------------------------------- When you write Python product everything is much more transparent, and there are fewer subtle effect that surprise you and make you wast hours debugging. You are more prone to do it the right way when writing Products and put login into Python and not the dtml. Simply because it is easier to do. It's also hard to document how to make zClass based products as you have to use a lot of screenshots or animations instead of text. Code for one class spread over several locations stops you from thinking clear ------------------------------------------------------------------------------ It as if you wrote Python code with all of your methods in different files. And as it is common knowledge the number of errors rises exponentially with the amount of code you cannot see. It can make class seem much bigger and more complicated than it really is if you cannot see all the code. Having products with parts of the code in External methods, other as dtml-files, python scripts etc. in the Zmi is a real drag! It seems so simple to begin with, but as the product starts to grow, it is so tiring. Programming through a web browser sucks! It slows down development considderably. Using ftp in the editor doesn't help much. A hassle to upgrade on remote servers ------------------------------------- With products you just upload via ftp, and perhaps run a script to find all instances and add new attributes. With zClasses keeping a development and production server in sync is hard to difficult. There is a whole lot of software writte to work around the flaws of using and uprading zClasses. That should be a hint that somethings wrong. Other reasons that other people has reported -------------------------------------------- There is a subtle bug in the ZClass registry code that can cause instances to refer to an older class definition. Makes it hard to use straight up Python code, have to use external methods, Working from Python gives you MUCH more power Copy & paste programming does not work with ZClasses. So it's harder to start new projects. Debugging Python code is easier than debugging ZClasses. You can use CVS for the code ZClasses behave "strange" with regard to nested acquisition. ZClasses are relatively slow, especially if you use other ZClasses as base classes of ZClasses If you have anything to add and/or correct. Please mail it to me at maxm@mxm.dk regards Max M
You make good points. I would recommend putting this somewhere more permanent, such as a page on Zope.org. -Casey On Tuesday 28 May 2002 04:51 am, Max M wrote:
Death to ZClasses!!! ====================
By Max M. 28-05-2002 10:42 [snip anti-zclass arguments]
Hi ZClass Bashers, ;-) I know I'm coming late to this roast... and I basically agree with all of Max's points, at *some* level. However.. I think that while ZClasses may have missed the mark on some points, and will never be a great answer for "serious" developers working on complex stuff (requiring fancy class hierarchies), for certain purposes they have a lot to recommend them. Generally, when I start working on a filesystem based Zope Product, there's a lot of housekeeping to do before I can really get started with the "meat" of the project. The way I "normally" do it, is to take some other product I've written, rename a bunch of stuff, throw a bunch of stuff out, and hope I've got it all right. ;-) The good news is, that if I don't have it all right... I can just change it, and everything is still OK. But it takes a lot of time, and a lot of fiddling around. If what I need is basically a very simple class, with some "standard" property types, and some simple methods, a ZClass is a very quick and painless way to get there in 5 minutes. I think of ZClasses as a sort of RAD tool to break into something quickly and try out some ideas. Maybe the project will never need anything more. If it does, I refactor and go the filesystem based Product route, but probably *after* I've learned a lot about the problem(s) and have some clear idea of how to avoid any pitfalls I've discovered. If you mix this kind of thinking with ZPatterns, then it's even cleaner, since the application is really tied together in instance space (Racks and Specialists) and the low level classes don't generally handle any inter-object collaboration (i.e., you don't need fancy subclasses of other zope objects since the only classes you're actually *writing* are SimpleItemish things). At this point with various tricks and templates, I can cook up a fairly fancy ZPatterns/ZClass based application with five or six different classes all collaborating and doing fairly fancy stuff (e.g., backed by a relational database, or ZCatalog) in a day or so (no UI, just connections and problem domain stuff). If I were doing the same thing with all filesystem based products/classes, it would probably take me three times as long (rough guess). Anyway.. I just thought ZClasses didn't deserve quite the degree of disrespect that I've been hearing, since *I* have at least been grateful for their existence, even if I have cursed them occasionally when I tried to push them further than they could reasonably go. Just because you can't build a skyscraper with a pocketknife, it doesn't mean that they're not handy to have when you need one. ;-) enjoy, -steve On Wednesday, May 29, 2002, at 01:45 AM, Chris Withers wrote:
Casey Duncan wrote:
You make good points. I would recommend putting this somewhere more permanent, such as a page on Zope.org.
How about the front page of zope.org? *weg*
Chris
_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )
Steve Spicklemire wrote:
Generally, when I start working on a filesystem based Zope Product, there's a lot of housekeeping to do before I can really get started with the "meat" of the project. The way I "normally" do it, is to take some other product I've written, rename a bunch of stuff, throw a bunch of stuff out, and hope I've got it all right. ;-)
I understand that, but using zClasses is the wrong solution imho. I wrote the easyproduct exactly to get around this problem. http://www.zope.org/Members/maxm/HowTo/easyProduct So getting started on a new product is even faster than a zClass. You just take one of two products. One based on SimpleItem the other on ObjectManager and do a search and replace for one word, and you are good to go. And they do work right from the start ;-) regards Max M
Alright. I didn't know about this one.. I'll take a look! On quick inspection, it looks like I'd need to subclass your classes to use them with ZPatterns, but maybe that's not too bad. I'll give it a whirl. thanks, -steve On Thursday, June 6, 2002, at 04:50 AM, Max M wrote:
Steve Spicklemire wrote:
Generally, when I start working on a filesystem based Zope Product, there's a lot of housekeeping to do before I can really get started with the "meat" of the project. The way I "normally" do it, is to take some other product I've written, rename a bunch of stuff, throw a bunch of stuff out, and hope I've got it all right. ;-)
I understand that, but using zClasses is the wrong solution imho. I wrote the easyproduct exactly to get around this problem.
http://www.zope.org/Members/maxm/HowTo/easyProduct
So getting started on a new product is even faster than a zClass. You just take one of two products. One based on SimpleItem the other on ObjectManager and do a search and replace for one word, and you are good to go.
And they do work right from the start ;-)
regards Max M
participants (4)
-
Casey Duncan -
Chris Withers -
Max M -
Steve Spicklemire