Well I have finally reached the stage where I am pushing the limits of ZClasses and would love an upgrade. Guess I need to do it myself. I run 38 specialty job boards, and am getting close to automatically putting up 300 more, each one has a custom ZClass. I am automatically generating ZClasses, Indexes, and Formulator Form's Fields. I don't like that each parent class lists its legal children, I think it would be better if the child listed the legal parents. The creation of an add permission for each of the 300 ZClasses I am about to generate also bothers me. I do not quite understand the design of ZClasses. I would expect that a class has three branches. One would be the class methods, one would be the instance methods, and one would be the list of instance variables. It would be nice if each instance variable had its own permission. Instead ZClasses has the create method and permissions at the same level as the ZClass. I think this is related to how zope handles Products. And then the instance variables are all on a propertysheet. I suspect this is because of how permissions are handled, there is computational efficiency in sharing a permission among the properties on a propertysheet. But I am not quite sure. Anyone want to enlighten me on this matter. I may take the liberty of calling up Jim Fulton for him to explain the history to me. On a related matter I think it would be great if we do a version of ZClasses that used the new Zope 3 permissions in 5, and that worked with the new ZODB concurrency control mechanisms. Regards Chris
--On 16. April 2007 22:21:33 -0700 Christopher Lozinski <lozinski@freerecruiting.com> wrote:
But I am not quite sure. Anyone want to enlighten me on this matter. I may take the liberty of calling up Jim Fulton for him to explain the history to me.
On a related matter I think it would be great if we do a version of ZClasses that used the new Zope 3 permissions in 5, and that worked with the new ZODB concurrency control mechanisms.
I think you are talking to a wall. ZClasses are dead...none of the current maintainers cares about ZClasses...but we discussed that already a bunch of times. Rewrite your apps from scratch using decent technologies - either on top of Zope2/CMF or Zope 3. Andreas
----- Original Message ----- From: "Christopher Lozinski" <lozinski@freerecruiting.com> To: <zope-dev@zope.org> Sent: Tuesday, April 17, 2007 1:21 AM Subject: [Zope-dev] ZClasses Maintenance and Upgrade
Well I have finally reached the stage where I am pushing the limits of ZClasses and would love an upgrade. Guess I need to do it myself.
I run 38 specialty job boards, and am getting close to automatically putting up 300 more, each one has a custom ZClass.
I am automatically generating ZClasses, Indexes, and Formulator Form's Fields. I don't like that each parent class lists its legal children, I think it would be better if the child listed the legal parents. The creation of an add permission for each of the 300 ZClasses I am about to generate also bothers me.
You may want to rethink your approach before you launch 300 new job boards based on ZClasses; as of Zope 2.10.x ZClasses are officially deprecated (see http://www.zope.org/Products/Zope/2.10.3/CHANGES.txt). I know this is a serious PITA... I just spent 3 months replacing ZClasses with a custom product in a client's web site because they did not want to get stuck in an old version of Zope. If long term maintainability is of interest then you may want to consider something other than ZClasses. Jonathan
Jonathan skrev:
----- Original Message ----- From: "Christopher Lozinski"
Well I have finally reached the stage where I am pushing the limits of ZClasses and would love an upgrade. Guess I need to do it myself.
I know this is a serious PITA... I just spent 3 months replacing ZClasses with a custom product in a client's web site because they did not want to get stuck in an old version of Zope.
Come on now. I wrote this 5 message years ago: http://mail.zope.org/pipermail/zope/2002-May/115427.html ZClasses have not changed since. It cannot be a surprise. :-) -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science
On Wed, Apr 18, 2007 at 11:52:03AM +0200, Max M wrote:
I wrote this 5 message years ago:
I've just added a link to that message on this wiki page: http://wiki.zope.org/zope2/ZClassesAreEvil Max (or anybody), feel free to merge the text of Max's message into the wiki page. -- Paul Winkler http://www.slinkp.com
Christopher Lozinski wrote at 2007-4-16 22:21 -0700:
... I am automatically generating ZClasses, Indexes, and Formulator Form's Fields. I don't like that each parent class lists its legal children,
Where does the parent class lists its legal children?
I think it would be better if the child listed the legal parents.
But, then you need to have somewhere (else) a registry to list the children types which can be added in the current place. When you want to add something to a container, the container is already there but not the child. You can, of course, put the registry somewhere else (rather than in the parent). And the lookup can even be quite complex and look into defined ZClasses to find adequate types.
The creation of an add permission for each of the 300 ZClasses I am about to generate also bothers me.
Several ZClasses can easily share a common add permission.
I do not quite understand the design of ZClasses. I would expect that a class has three branches. One would be the class methods, one would be the instance methods, and one would be the list of instance variables.
Why do you want to distinguish between class and instance methods? Even Python has learned this distinction only quite recently. By the way, there are class methods for ZClasses -- but you cannot change them. They are fixed for all ZClasses.
It would be nice if each instance variable had its own permission.
Zope can protect simple values only since version 2.8. Far too late for "ZClass"es.
Instead ZClasses has the create method and permissions at the same level as the ZClass. I think this is related to how zope handles Products.
I think this is very normal: Of course, you have the "create" method on the class level as the class already exists but not the instance. Of course, you define the permissions on the class level to affect all instances. That is how Zope's security works everywhere (and not only on "ZClass"es).
And then the instance variables are all on a propertysheet. I suspect this is because of how permissions are handled, there is computational efficiency in sharing a permission among the properties on a propertysheet.
The main reason is that Zope only learned with Zope 2.8 how to protect attributes with elementary values. -- Dieter
Dieter Maurer wrote:
Where does the parent class lists its legal children?
In the Products Folder, for each ZClass there is a tab listing allowed subobjects.
I think it would be better if the child listed the legal parents.
But, then you need to have somewhere (else) a registry to list the children types which can be added in the current place.
That explains why they are listed where they are listed. Thank you.
Why do you want to distinguish between class and instance methods?
So I can send a create message to something before I have any instances.
Regards Chris
Dieter Maurer wrote:
The main reason is that Zope only learned with Zope 2.8 how to protect attributes with elementary values.
It took me a few minutes to get the full meaning of this. You mean I can do individual permissions on instance variables in Zope 2.8+ ! That means I can get rid of ZClass propertysheets in Zope 2.8 + And I can replace them with proper instance variables, with different permissions! AWESOME. BRILLIANT. FANTASTIC. Back into the ZClass source code I go. This is going to be very painful. Regards Chris
participants (6)
-
Andreas Jung -
Christopher Lozinski -
Dieter Maurer -
Jonathan -
Max M -
Paul Winkler