[Zope-dev] Re: In Defense of ZClasses

[Philipp von Weitershausen]

Christopher Lozinski wrote:
> I think that there is a different tool for every job.  Sometimes I think 
> Plone is the best solution, sometimes Zope 2 is the best solution. 
> Sometimes Zope 3is the best solution, and  sometimes ZClasses are the 
> best solution. 

Yes, you're right about different tools. But we can't make the 
conclusion that ZClasses are the only good tool for getting prototypes 
done fast. If there are better tools (and I think there are) and 
ZClasses are in fact so hard to maintain that only one or two people can 
actually do it, I see little point in defending them.

> When are ZClasses the best solution?   Frequently a ZClass is the 
> fastest way to build an application.  I can put up a simple list of 
> types in ZClasses and DTML so incredibly quickly.  Frankly developing a 
> file system based python application is just way too much overhead for 
> bringing up simple web applications quickly.

The problem is the lack of an exit strategy. If you only need a simpel 
web app, fine. If you're creating a prototype, ZClasses are hard to get 
out of without rewriting a whole lot of code.

> I was recently told that ZClasses now work with Zope 2.8.* Maybe it was 
> 2.9.*

Why don't you try?

> Frankly I am not smart enough to understand the recent evolution 
> of the Zope framework.  But I suspect that ZClasses can be made to work 
> for a while more on top of the newest releases of Zope, and that is good 
> enough for me.  Someone will be motivated enough to make it work, and I 
> will take advantage of the resulting open source code.

Doesn't sound like you're trying to be part of the solution here. I've 
seen you've expressed interest in maintaing ZClasses, bringing them up 
to speed and what not, but so far nothing has happened. Don't expect us 
to do the work now.

> I also think that there is a bright future for ZClasses, in the niches 
> that I am interested in.

I think your niche definitely deserves attention, but not from ZClasses. 
ZClasses are a mistaken approach because they put too much focus on the 
actual object (the ZClass instance). That's what makes the ZClass 
implementation so difficult.

I take it that you're using ZClasses to mainly

* manage and update data in objects (currently instances of ZClasses)

* define views and other behaviour for these objects

For these use cases it is not necessary to use a complex machinery like 
ZClasses. The objects we're talking about here could be very very dull, 
to the point where we don't need something like a dynamically 
constructed class. You'd just instantiate the same object over and over 
again, and apply different behaviour.

There have been prototypes for this kind of thing in Zope 3 where you'd 
define a schema through-the-web and could then create content objects 
based on that schema. And of course you could add views and such. 
Without ever writing a single line of Python. Such systems have value, 
but they need to be implemented and maintained. No one so far had enough 
resources (e.g. a paying project) nor the use cases to do this. Most of 
us rather do like coding Python.

So, a more realistic effort is the one Martijn has been talking about: 
scaling Zope down. Yes, this will involve coding on the file system 
(because we like Python), but the goal is to be quick and agile, while 
still being able to evolve.

> Many years ago, I used to use versions to 
> develop production and development code on a single server.  I was in 
> heaven.  It was so easy.  It was so productive. Then came zcatalogs and 
> all of that broke.  Pretty soon, I think someone, maybe even me, will be 
> motivated enough to make ZClasses work with MVCC.  Multivalued 
> Concurrency Control, so that we can get rid of our development servers, 
> and as a single developer just run a simple cheap development/production 
> server.  Life will be great.

Not all of us share your vision of a great life :).

> Zope 3 has a single server schema,

Not sure what that means.

> So I hope that this defense of ZClasses encourages you not to abandon 
> them.

We're not abandoning them because they're not solving problems. We 
realize they solve problems like yours. We're abandoning them because no 
one is maintaining them, and because we think they're the wrong answer 
to the right questions.

> Use whichever tool is best for your application, and trust that 
> others will make the same wise decisions.

I think the fact that nearly nobody uses ZClasses anymore shows that 
most "others" have made "the same wise decision" already :)