[Zope-dev] Re: Future of ZClasses
Dieter Maurer wrote: Also the thread that ZClass (re)distribution code will be removed need not worry you too much. Fortunately, Zope is open source and you can simply combine the new release with pieces of an older release to retain features essential to you. I see no problem in making the "ZClasses" a separate svn.zope.org project, for example. That way they're not hindering Zope 2 core releases but could still be maintained (e.g. by volunteers like apparently yourself, Dieter :)) and shipped as an optional egg, for example. I don't see ZClasses as anything particular evil or good, just having them languish in the Zope 2 core puts a burden on all those who don't understand them and don't have the bandwidth to support them. So it's not about being "overly eager" regarding removal, it's about risk management for future releases. Moving ZClasses to a separate project reduces the risk of the Zope 2 core. Like you said, even you can't promise to keep ZClasses working for every Zope release... We have a large ZClass based application. And I will keep it working. Great! ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Future of ZClasses
Dieter Maurer wrote: Philipp von Weitershausen wrote at 2006-9-28 14:23 +0200: ... Why not set marker interfaces directly on the objects? That whole "type" thing is unnecessary. Just use interfaces. Usually, a type is seen as a set of objects, its type instances. It is quite nice to be able to work on a object set meta level rather than on individual objects Sure, though I don't see how an interface can't represent this meta level. Perhaps I'm missing an important point here... ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: wsgi/paste pipelines in Zope 2 or 3?
Sidnei da Silva wrote: On Thu, Sep 28, 2006 at 01:11:05PM -0400, Brad Clements wrote: | I've been doing a lot of work with Paste in the past year, cutting down on my | deployments of Zope. | | Now I'm taking a new look at Zope 3 and Zope 2, and wondering if it's possible to | use paste pipeline/filter in either version of Zope. I've looked at | | http://cheeseshop.python.org/pypi/zope.paste | | and | | http://awkly.org/archive/zopepaste-wsgi-applications-in-zope-3-using-pastedeploy/ | | But what I need is not just a wsgi application hosted in Zope, but rather, a wsgi | filter that can intercept the call chain during traversal. | | Has anyone else encountered this need or have thoughts about it? Hi Brad, The fine folks from The Open Planning Project /me grins. most of it is the work of one "fine folk", ian bicking. are developing 'topp.wsgi', which is pretty much what you're looking for. it's actually 'topp.zwsgi'. anonymous svn available here: https://svn.openplans.org/svn/topp.zwsgi/ browseable interface here: https://svn.openplans.org/cgi-bin/viewcvs.cgi/topp.zwsgi/ You can find them in #openplans on irc.freenode.net this is true, yes... please be aware, though, that this stuff is nascent, and our support time is limited. we can help self-motivated folks who are digging through the code and asking intelligent questions, but we're not yet to a point where we can do a lot of hand-holding. we do plan on using it within our own offerings, however, and all of our code will be available (in the same svn repo linked above), so i suspect this story will be improved in the coming months. -r ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Future of ZClasses
- Original Message - From: "Dieter Maurer" <[EMAIL PROTECTED]> To: "Jonathan" <[EMAIL PROTECTED]> Cc: Sent: Thursday, September 28, 2006 4:21 PM Subject: Re: [Zope-dev] Future of ZClasses Jonathan wrote at 2006-9-28 15:11 -0400: ... For internal applications I would rather leave the ZClasses in place and try to fix whatever breaks when zope is upgraded, however the application that caused my initial question is for an external client (with no in-house zope expertise of their own) and they are not at all pleased with the idea of having to 'fix things' everytime they update their zope version. Who speaks about every time (of an upgrade). I remember 2 (small) ZClass related problems after Zope upgrades and 1 time (for Zope 2.8) where ZClasses were not ready for the Zope beta version. The Zope 2.8 port of ZClasses was probably a significant effort (Thank's Jim). It is not unlikely that they will die should another such effort be necessary. However, for the next releases, no such effort is on the horizon. We might see small (unanticipated) problems like the 2 mentioned above. In this particular instance, I am going to have to 'bite-the-bullet' and remove all traces of ZClasses, so that they can upgrade to future versions of zope without fear. It is your choice. I will not argue against it In this particular instance the client is a government department. They do not want to have an application that requires a specific skill set (ie. mine) in order to do an upgrade (they have an internal policy about keeping all o/s and application platforms current - which they do themselves). As much as I would like it, they do not want to hire me everytime they do an upgrade (could be a good business concept though!) Jonathan ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Future of ZClasses
Jonathan wrote at 2006-9-28 15:11 -0400: > ... >For internal applications I would rather leave the ZClasses in place and try >to fix whatever breaks when zope is upgraded, however the application that >caused my initial question is for an external client (with no in-house zope >expertise of their own) and they are not at all pleased with the idea of >having to 'fix things' everytime they update their zope version. Who speaks about every time (of an upgrade). I remember 2 (small) ZClass related problems after Zope upgrades and 1 time (for Zope 2.8) where ZClasses were not ready for the Zope beta version. The Zope 2.8 port of ZClasses was probably a significant effort (Thank's Jim). It is not unlikely that they will die should another such effort be necessary. However, for the next releases, no such effort is on the horizon. We might see small (unanticipated) problems like the 2 mentioned above. >In this particular instance, I am going to have to 'bite-the-bullet' and >remove all traces of ZClasses, so that they can upgrade to future versions >of zope without fear. It is your choice. I will not argue against it -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Future of ZClasses
Philipp von Weitershausen wrote at 2006-9-28 14:23 +0200: > ... >Why not set marker interfaces directly on the objects? That whole "type" >thing is unnecessary. Just use interfaces. Usually, a type is seen as a set of objects, its type instances. It is quite nice to be able to work on a object set meta level rather than on individual objects -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Future of ZClasses
- Original Message - From: "Dieter Maurer" <[EMAIL PROTECTED]> To: "Jonathan" <[EMAIL PROTECTED]> Cc: Sent: Thursday, September 28, 2006 2:49 PM Subject: Re: [Zope-dev] Future of ZClasses Jonathan wrote at 2006-9-27 12:42 -0400: I found a thread (from March 2006) discussing the future of zclasses, but i could not determine if a 'final' decision had been made. According to Changes.txt for Zope 2.10.0: "ZClasses are deprecated and should no longer be used. In addition any code related to the ZClasses (re)distribution mechanism is removed." Does this mean that any application which incorporates zclasses will break if upgraded to zope 2.10.x? I do not think so. Jim invested considerable time to make ZClasses working for Zope 2.8. Future modififications will probably not break ZClasses severely. Also the thread that ZClass (re)distribution code will be removed need not worry you too much. Fortunately, Zope is open source and you can simply combine the new release with pieces of an older release to retain features essential to you. This way, the power of overly eager release managers (and other removal friendly Zope developers) is limited :-) We have a large ZClass based application. And I will keep it working. However, our current strategy is to skip more and more Zope releases (we are still at Zope 2.8.1) because the features newly introduced in the newer Zope releases are not worth the upgrade efforts. Currently, we plan our next upgrade to Zope 2.11 (to make use of "eggification"). Therefore, I cannot promiss to fix potential ZClass problems in Zope 2.10 in a timely manner. If eggification comes with Zope 2.11 (otherwise, we may delay our upgrade until Zope 2.12), then ZClasses will work again for this release. For internal applications I would rather leave the ZClasses in place and try to fix whatever breaks when zope is upgraded, however the application that caused my initial question is for an external client (with no in-house zope expertise of their own) and they are not at all pleased with the idea of having to 'fix things' everytime they update their zope version. In this particular instance, I am going to have to 'bite-the-bullet' and remove all traces of ZClasses, so that they can upgrade to future versions of zope without fear. On the plus side, they will end up with a more stable/robust application which, hopefully, will last for years to come! Jonathan ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Future of ZClasses
Jonathan wrote at 2006-9-27 12:42 -0400: >I found a thread (from March 2006) discussing the future of zclasses, but i >could not determine if a 'final' decision had been made. > >According to Changes.txt for Zope 2.10.0: > >"ZClasses are deprecated and should no longer be used. In addition any code >related to the ZClasses (re)distribution mechanism is removed." > >Does this mean that any application which incorporates zclasses will break if >upgraded to zope 2.10.x? I do not think so. Jim invested considerable time to make ZClasses working for Zope 2.8. Future modififications will probably not break ZClasses severely. Also the thread that ZClass (re)distribution code will be removed need not worry you too much. Fortunately, Zope is open source and you can simply combine the new release with pieces of an older release to retain features essential to you. This way, the power of overly eager release managers (and other removal friendly Zope developers) is limited :-) We have a large ZClass based application. And I will keep it working. However, our current strategy is to skip more and more Zope releases (we are still at Zope 2.8.1) because the features newly introduced in the newer Zope releases are not worth the upgrade efforts. Currently, we plan our next upgrade to Zope 2.11 (to make use of "eggification"). Therefore, I cannot promiss to fix potential ZClass problems in Zope 2.10 in a timely manner. If eggification comes with Zope 2.11 (otherwise, we may delay our upgrade until Zope 2.12), then ZClasses will work again for this release. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] wsgi/paste pipelines in Zope 2 or 3?
On Thu, Sep 28, 2006 at 01:11:05PM -0400, Brad Clements wrote: | I've been doing a lot of work with Paste in the past year, cutting down on my | deployments of Zope. | | Now I'm taking a new look at Zope 3 and Zope 2, and wondering if it's possible to | use paste pipeline/filter in either version of Zope. I've looked at | | http://cheeseshop.python.org/pypi/zope.paste | | and | | http://awkly.org/archive/zopepaste-wsgi-applications-in-zope-3-using-pastedeploy/ | | But what I need is not just a wsgi application hosted in Zope, but rather, a wsgi | filter that can intercept the call chain during traversal. | | Has anyone else encountered this need or have thoughts about it? Hi Brad, The fine folks from The Open Planning Project are developing 'topp.wsgi', which is pretty much what you're looking for. You can find them in #openplans on irc.freenode.net -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] wsgi/paste pipelines in Zope 2 or 3?
I've been doing a lot of work with Paste in the past year, cutting down on my deployments of Zope. Now I'm taking a new look at Zope 3 and Zope 2, and wondering if it's possible to use paste pipeline/filter in either version of Zope. I've looked at http://cheeseshop.python.org/pypi/zope.paste and http://awkly.org/archive/zopepaste-wsgi-applications-in-zope-3-using-pastedeploy/ But what I need is not just a wsgi application hosted in Zope, but rather, a wsgi filter that can intercept the call chain during traversal. Has anyone else encountered this need or have thoughts about it? Thanks (ps, I have something like xslfilter, but using wsgi and libxml2 and also an XSL version of TAL/METAL that I'd like to use in Zope) -- Brad Clements,[EMAIL PROTECTED](315)268-1000 http://www.murkworks.com AOL-IM or SKYPE: BKClements ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Distributed Object Use Case for Zope 3 developers.
Martijn Faasen makes the point that it is important for the Zope 3 developers to have good use cases. So here we go. Here is my distributed Object use case for Zope 3 developers. Can I do this in Zope 3? I run a job board for each technology. I have one job board for zope/plone developers, and another one for Linux System Administrators. Right now I have quite low traffic, and I run all my job boards off of one zope instance. But if this should ever be a hit, I can imagine running one zope instance per job board, or even multiple zope instances for one job board using zeo on its own server. The available parallelism is quite strong in Zope 2. Now here is the problem. Say one of you is both a Linux Admin and a Zope/Plone developer. Right now you would have to post your resume twice on two different job boards. If you changed your resume, you would have to change it in two different servers. Sometime soon, I hope that you will be able to just apply once. You would fill out the Zope skills question box, and the Linux Administrator skills question box, and the server will automagically create copies of your record on both job boards. If those are on separate servers, then that is a distributed migration of objects. When you return to edit your data and update your resume, that information needs to be propogated to the other job board on the other server as well. I hope that is a helpful use case for the Zope 3 developers. Of course maybe things are done totally differently in Zope 3 than in Zope 2. Here is another distributed use case, which I do admit is more speculative. Performance reasons might encourage me to have one server in the US, and one in India. Reportedly Google localization takes into account where the server is located. So if I want to compete globally in the US and India, I would want my Indian candidate objects to migrate to my Indian server, and my US candidate objects to migrate to my US server. I think I could do this with ZClasses. Can I do it with Zope 3? I hope that helps. Chris ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: ZClass Maintenance
ZClasses don't get better from writing long postings. Ah, yes but I can write much faster than I can code. What am I doing on this list!?! All I have to do is to motivate someone else to do the work! programmers are generally motivated by concrete contributions ie money, code, beer, or trips to exotic places to get money, code, or beer. hope that helps, -w ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Future of ZClasses
Thanks for the comments. For all the things you wrote that I deleted, I would just say "Exactly!" :-) Here are the things that are not "exactly!": On 9/28/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: Have you looked at zope.app.schemacontent, Sidnei's prototype for TTW-schemas and content based on that? Nope. But thanks for the hint. > 2. On the type you can set marker interfaces, Why not set marker interfaces directly on the objects? That whole "type" thing is unnecessary. Just use interfaces. Because you want to be able to add a new functionality (by setting a new marker interface on the type), and get it added to all the objects that have that type. Of course, the type assignment would, I expect, in itself be done by a marker interface, but that's implementation details I don't want to think about yet. :-) I was unfortunately talking too much implementation details. I should have tried to be more conceptual. From now on, I will call the functionality adapters for "aspects". :) > that enables adapters with different functionality, such as indexing > awareness, and whatnot. Yes and no. "catlaog awareness" is a Zope 2 thing, with the CA you'd use events. Well, that was the one example I could think of just then, although I knew it was a crap one. I could think of specialized aspects, such as an aspect to automatically ping a site like del.icio.us when you post your bloggentry, but I couldn't think of anything truly generic. However, during this answer, I did think of something better: Workflows: You could for example have an aspect for a simple publishing workflow. So if you enable this, the objects of the type gets a publishing workflow. And another aspect could enable the wmfc workflow module for the object, for example. (Which makes me realize that some aspects could need settings on the type... Hmmm...) > 3. Each type also has schemas Type, schema, and interfaces should be synonymous: interfaces. Don't invent more concepts than we already have. Nah, they should not be synonyms. But I was as mentioned mixing implementation and concepts before. I'll explain: The people who use these new ZClasses want to be able to create content types that has forms with a set of fields and informations like if a field should be required or max length and stuff. They also want to be able to create specialized views, and enable "aspects" for the type, like saying that objects of this type should have this workflow. They will never understand you if you call both the forms, and the views and the aspects for "interfaces", because although technically there are interfaces below all of this, the functionality in the end is wildly different, and the way you use it is also wildly different. How all this is implemented and attached to the object is nothing the user want to be aware of. However, you may be right in that maybe one schema, and a set of views, in themselves should be an aspect, so that you do not assign these to types, but you create a form-aspect and a view-aspect, and assign these to the type. > 4. When you then run into a thing you can't do through the web you are > not stuck. Wrong. You write it in Python and register it locally for your "type" (read: interface). I think you missed a "not" there. :) > If you want to add new event handler for your type, you can write a > new functionality adapter on disk, and then enable it via marker > interfces for your type. No need for the marker interface. You already have your "type" interface. Just use that. Yes, and no. If I do that, I can't use the aspect for other types. Then I'm stuck with using it ONLY for that type. This may be what I want, or it may not be. So, when are you going to write it? :) My crystal ball blue-screened. :-) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: In Defense of ZClasses
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: PYTHONPATH
Paul Winkler wrote: On Wed, Sep 27, 2006 at 06:26:49PM -0500, whit wrote: It seems like if you've set your PYTHONPATH and start zope, you would expect that path to be available. Indeed. Anyone object to this going forward? Anyone think this is a bug that should be fixed(on older versions)? I think it's a bug, but then, I don't recall ever stumbling on it in practice. alright... if noone objects, I'm filing this as a bug and making the change. will wait another 24 hours. -w ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: In Defense of ZClasses
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: In Defense of ZClasses
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:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: In Defense of ZClasses
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] In Defense of ZClasses
On 9/28/06, Lennart Regebro <[EMAIL PROTECTED]> 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. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: In Defense of ZClasses
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 signature.asc Description: This is a digitally signed message part ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Future of ZClasses
Lennart Regebro wrote: On 9/27/06, Andreas Jung <[EMAIL PROTECTED]> wrote: It's definitely time to work on a replacement. Yes. And here is my short vision of that. Comments are appreciated. Have you looked at zope.app.schemacontent, Sidnei's prototype for TTW-schemas and content based on that? 1. We have a base content class used to create content objects. This has the concept of type, pretty much like CMFs portal_type. The type is defined in the ZODB. Possibly. It's important to keep this content class really really dull ("one size fits all") so that we don't need to magically create persistent classes or something. 2. On the type you can set marker interfaces, Why not set marker interfaces directly on the objects? That whole "type" thing is unnecessary. Just use interfaces. that enables adapters with different functionality, such as indexing awareness, and whatnot. Yes and no. "catlaog awareness" is a Zope 2 thing, with the CA you'd use events. These adapters are written in diskbased pythons. Hence any type of basic functionality like this still needs to be disk-based. Except for views, perhaps. Simple template-based views could still be done through-the-web, perhaps even views that are implemented as Python Scripts. 3. Each type also has schemas Type, schema, and interfaces should be synonymous: interfaces. Don't invent more concepts than we already have. and forms, those can be automated from the schema 4. When you then run into a thing you can't do through the web you are not stuck. Wrong. You write it in Python and register it locally for your "type" (read: interface). If you want to add new event handler for your type, you can write a new functionality adapter on disk, and then enable it via marker interfces for your type. No need for the marker interface. You already have your "type" interface. Just use that. If you python scripts security becomes a hindrance, you can easily move that to disk by making another marker interface and building views for that. We could even have a button "Export to disk module" which exports the current templates + scripts to a view + methods + templates all on disk. This combines and easy plug-and-play attitude with TTW programming without providing a dead end. Hopefully. So, when are you going to write it? :) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: In Defense of ZClasses
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 :) ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Future of ZClasses
On 9/27/06, Andreas Jung <[EMAIL PROTECTED]> wrote: It's definitely time to work on a replacement. Yes. And here is my short vision of that. Comments are appreciated. 1. We have a base content class used to create content objects. This has the concept of type, pretty much like CMFs portal_type. The type is defined in the ZODB. 2. On the type you can set marker interfaces, that enables adapters with different functionality, such as indexing awareness, and whatnot. These adapters are written in diskbased pythons. Hence any type of basic functionality like this still needs to be disk-based. 3. Each type also has schemas and forms, templates and python scripts in the ZODB. The schemas and forms are to generate edit and create forms, the python scripts act like methods on a view, and the templates as, well, templates. 4. When you then run into a thing you can't do through the web you are not stuck. If you want to add new event handler for your type, you can write a new functionality adapter on disk, and then enable it via marker interfces for your type. If you python scripts security becomes a hindrance, you can easily move that to disk by making another marker interface and building views for that. We could even have a button "Export to disk module" which exports the current templates + scripts to a view + methods + templates all on disk. This combines and easy plug-and-play attitude with TTW programming without providing a dead end. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] In Defense of ZClasses
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. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] In Defense of ZClasses
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Future of ZClasses
Jonathan wrote: BTW - nothing beats ZClasses and DTML for quick-and-dirty demos, one-time applications, and rapid-prototyping! I prefer to use page templates, python scripts and PropertyManagers for this ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] buildbot failure in Zope branches 2.10 2.4 Windows 2000 zc-bbwin2
The Buildbot has detected a failed build of Zope branches 2.10 2.4 Windows 2000 zc-bbwin2. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 7900 Blamelist: andreasjung,baijum,ctheune,dobe,faassen,fdrake,gintautasm,hdima,jim,jukart,mkerrin,opetznick,poster,srichter,wosc BUILD FAILED: failed compile sincerely, -The Buildbot ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] buildbot failure in Zope branches 2.10 2.4 Linux zc-buildbot
The Buildbot has detected a failed build of Zope branches 2.10 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 7900 Blamelist: andreasjung,baijum,ctheune,dobe,faassen,fdrake,gintautasm,hdima,jim,jukart,mkerrin,opetznick,poster,srichter,wosc BUILD FAILED: failed test sincerely, -The Buildbot ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] buildbot failure in Zope trunk 2.4 Windows 2000 zc-bbwin6
The Buildbot has detected a failed build of Zope trunk 2.4 Windows 2000 zc-bbwin6. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 7897 Blamelist: andreasjung,baijum,ctheune,dobe,faassen,fdrake,gintautasm,hdima,jim,jinty,jukart,mkerrin,opetznick,poster,regebro,srichter,tseaver,wosc,yuppie BUILD FAILED: failed compile sincerely, -The Buildbot ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] buildbot failure in Zope trunk 2.4 Linux zc-buildbot
The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 7897 Blamelist: andreasjung,baijum,ctheune,dobe,faassen,fdrake,gintautasm,hdima,jim,jinty,jukart,mkerrin,opetznick,poster,regebro,srichter,tseaver,wosc,yuppie BUILD FAILED: failed test sincerely, -The Buildbot ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )