At the risk of going down in history (and Google Searches) as the man who supports ZClasses, I think that someone deserves to come to their defense. 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. 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. In fact I have pushed ZClasses pretty far. If you are building an application, and you are a single developer, and you are comfortable with a tree based data model, then ZClasses is probably still your fastest development tool. I was recently told that ZClasses now work with Zope 2.8.* Maybe it was 2.9.* 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. I also think that there is a bright future for ZClasses, in the niches that I am interested in. 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. But I see a brighter future for ZClasses as well. The demand for my services is booming. I have way more business than I can handle. Someone recently did a search for a plone resume on Google, and I got 6 of the top placements. We have heard of search engine optimization, but this is just crazy good. Of course managing a staff of recruiters is the hardest part. So soon I will need to run multiple servers with data being shared among them. I will need a distributed schema, where people enter their resumes on one job board, and have them distributed to several other job boards. Zope 3 has a single server schema, but I have no idea if I will be able to expand it to a distributed Schema. With Zope 2, and ZClasses, it is very clear to me how I can build a distributed schema that moves classes around between servers. Most of the work is already done for me, another huge chunk, the schema part, I have done. So I think Zclasses serve my needs wonderfully. And I think that I can upgrade them with MVCC to make a single developer even more productive. And I think that I can build powerful distributed applications on top of them. That will be so much easier than trying to build and move python code on the file system and restarting dozens of servers. And it only takes a few of us using ZClasses, and making money off them to keep ZClasses quite alive. So I hope that this defense of ZClasses encourages you not to abandon them. Use whichever tool is best for your application, and trust that others will make the same wise decisions. Flame Shield is now up. I look forward to your replies. Regards Chris
--On 27. September 2006 17:05:37 -0700 Christopher Lozinski <lozinski@freerecruiting.com> wrote:
At the risk of going down in history (and Google Searches) as the man who supports ZClasses, I think that someone deserves to come to their defense.
Not really. We've had these discussion in the past and the arguments were exchanged multiple times. ZClasses deserve a maintainer or a budget to fund a maintainer - otherwise they will remain what they are: a 3rd-class citizen of Zope. If ZClasses should have a future in Zope 2, it's basically up to the ZClasses users to do something. Except Jim I don't see any person in the community who has an interest in maintaining the code but as Jim wrote: he has better things to do...so ZClasses will remain in the state as they are. They don't get better from writing long postings. -aj
Christopher Lozinski wrote:
At the risk of going down in history (and Google Searches) as the man who supports ZClasses, I think that someone deserves to come to their defense.
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. 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.
I think this is a good point. I agree that in Zope 2 and Zope 3 it's rather a lot of overhead to create a file-system based application, though Archetypes + Plone probably helps a lot. What I'm hoping is that eventually in a Zope 3 context we can create something that is as easy to develop with as ZClasses are, though filesystem based. (I myself am mostly interested in solving this on the code level, but people are welcome to write a UI for it) Some of us are going to invest a bit of time in trying to get this project off the ground, so we'll see what next year brings. That's not to say we're going to come up with something very similar to ZClasses, it's just that we're trying to make something that's close to being as easy to develop for, in the simple case, as Zope 2 is with its through the web development model. Note that this doesn't help people using ZClasses currently in maintaining their application at all, so this point is perhaps a bit useless. I just wanted to make sure that we are aware of the usecases surrounding ZClasses and hope to be able to fulfill at least some of them, in quite a different way, in the future. Note that ZClasses also have another feature that right now we're not going to tackle - changing them on a live server without restarts. You describe these usecases eloquently. This is an issue that *also* needs more work in a Zope 3 context, I just declare it out of scope for my project. :) Regards, Martijn
My 0.02 EUR: I like the idea and aim of ZClasses. However: I think the implementation makes them more difficult to create than disk-based classes, which defeats the purpose. I also think that without exact knowledge of the limitations of ZClasses they have a high risk of programming yourself into a corner. For that reason, I think that ZClasses is a dead end which the core Zope development team should not spend time on. There are many much more useful things to do. If people who want ZClasses are willing to spend time and money on ZClasses, this is of course not a problem.
On 9/28/06, Lennart Regebro <regebro@gmail.com> wrote:
My 0.02 EUR:
I like the idea and aim of ZClasses. However:
I think the implementation makes them more difficult to create than disk-based classes, which defeats the purpose. I also think that without exact knowledge of the limitations of ZClasses they have a high risk of programming yourself into a corner.
Create, no. *Maintain*, absolutely. Anthony, who has a vast number of ZClasses dating back rather a long time now that need a rewrite, sigh.
if zclasses(and some of the niceties that depended on them like ZPatterns) could reliably roundtrip to the filesystem, would we be having this conversation? I don't know...it seems like if you tackled the less sexy problem of making zclasses play with normal developer tool chain, the divide between zclass fans and core developers is bridged. Seaside, the smalltalk web framework is a successful example of this(but before it could be, they had to build a scm in smalltalk). I think the reality is that since the current best practice toolchain came after the inception of ZClasses, you can't expect any active developers to want to maintain something divorced from their working environment. bring zclasses back to the tool chain, and you might grow an audience to help you. -w
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 :)
On Thu, 2006-28-09 at 14:13 +0200, Philipp von Weitershausen wrote:
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.
In the words of "The Pragmatic Programmer" ... ZClasses can be used to build fine prototypes but cannot be used to create `tracer bullets`_. Python developers by nature tend to be pragmatic programmers, so of course we would rather use a tracer bullet over a prototype. _`tracer bullets`: http://www.artima.com/intv/tracerP.html - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net
Philipp von weitershausen wrote:
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.
I appreciate all your comments. It helps me better understand what I am dong. In fact I do dynamically build my ZClasses on the fly on the production server. When I build a new job board, a whole bunch of stuff gets automagically done. I have code writing code. Then the users create specific instances of ZClasses. I love the idea that Zope 3 includes schema information. I love the idea of building Zope 3 schemas through the web. But Legacy code and data has a powerful gravitational pull. I have a working application, it is very little work to make the upgrades I need to make. It is a huge amount of work to migrate it to Zope 3. If I built a new application, it would be in Zope 3. For the existing stuff I am happy enough with Zope 2. It is so much better than PHP! In terms of motivations, I am happy enough with Zope 2.7* I do not really understand the new upgrades, or what the changes are, or what the benefits are. With all due respect, I would prefer stability in my platform rather than evolution. At some point I will come up with a limitation of Zope 2.7*, I will need to upgrade, ZClasses will not be working, and I will then do something. In the meantime my attention is much more focussed on how to manage my employees better using my application. Thanks for all the advice. I expect you will hear back from me when ZClasses are next discussed on this mailing list. Regards Chrsi
Philipp von Weitershausen wrote:
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.
I wonder where Chris' orginal post is. I don't seem to have it.
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.
I think Chris is defending the functionality and trying to motivate someone to provide maintenance.
When are ZClasses the best solution?
"best" is probably not the best word for Chris to have used. :)
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.
Chris, have you tried ArchGenXML? I find it rather impressive in this regard. If I needed something quick and dirty, I would pick it ober ZClasses.
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.
Right. But if it is a throw-away prototype, that doen't matter. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
Jim Fulton asked
Chris, have you tried ArchGenXML?
I did do a project in Archetypes, in Plone. If I recall correctly, Archetypes requires CMF. And that is way too much code to add to my application. My workflow requirements are trivial. I think that Archetypes is quite brilliant at defining a schema. But it also includes the definition of the user interface in the data schema. I much prefer to use Formulator to define the forms, and Archetypes to define the data schema. Since I was not quite happy with Archetypes, I saw no point to move up to ArchGenXML. Actually what I have done in my internal code is to swipe the ideas from Archetypes, and automagically create the ZCatalogs, and ZClasses and Formulator forms. That way the forms can evolve away from the underlying classes. With these tools I can put up a new customized job board in very little time. And I do not have to carry around the whole infrastructure from CMF. So I would prefer to be working in Zope 3. But I am stuck with my legacy code, and pretty happy with it. I do some things which absolutely require the dynamicism of ZClasses. And when I get a reason to upgrade my zope server to a version that does not support ZClasses, then I will be motivated to do something about it. Chris
participants (9)
-
Andreas Jung -
Anthony Baxter -
Christopher Lozinski -
Jim Fulton -
Lennart Regebro -
Martijn Faassen -
Philipp von Weitershausen -
Rocky Burt -
whit