[Zope-dev] Re: Killer App for ZClasses

[Christopher Lozinski]

Lennart Regebro wrote:

> On 4/26/07, Dieter Maurer <dieter at handshake.de> wrote:
>
>> Andreas Jung wrote at 2007-4-25 22:13 +0200:
>> > ...
>> >But readable and comprehensible magic...but I would not call that 
>> magic.
>>
>> If I see at class level a function call "grok.context(something)",
>> this does not look like "comprehensible magic".
>
>
> It sets the grok context to something. Is that really incomprehensible?
>
 From people's comments, here and on the archetypes mailing list, I am 
pretty convinced that there is support for a through the web editing 
environment, even from Alexander Limi, expert on human interfaces and 
co-author of Plone. 

There was talk about TTW for Zope 3, for Archetypes, but not for Zope 2.

I understand that ZClasses are crufty inside.   I now understand we can 
toss out propertysheets becasause Zope 8 allows protection of individual 
properties.  I wish I had time to implement that.   Right now I do not 
even have time to update the upgrade plans for ZClasses.  They are on 
the wiki.

I would love to see detailed documentation of Zope Product Classes.  
Perhaps we could create a cleaner ZClasses that just drives the Zope 
Product class.  I would not even mind a server restart for each new 
class, evidently that is required for file system classes, but not 
ZClasses.  No wonder ZClasses is strange.   It had to be to make it 
possible to do more than Products can do.

Detailed design documentation of Zope 2 Products would perhaps make it 
clear why ZClasses are implemented the way they are implemented. 

As for grok contexts, you are arguing about a blade of grass.  Look at 
the forest.
I would like to be able to build a complete app, a network of objects 
persisted on the the ZODB, with a couple of clicks.   Then I could add 
methods on top of that.   ZClasses gives me a path in that direction.  I 
have some of my own tools to take me further.

Why am I not going with Zope3?    It seems like way too much overhead.  
But most importantly it does not give me the stuff I am really looking 
for.  Sure it does some schema stuff, but that is mostly for 1 object 
and its user interface, rather than over the whole network of objects.   
Why are there schemas for the user interfaces, and interfaces for the 
other interfaces? Lack of symmetry.   Zope3 checks that the next object 
in the network has the right interface.  That is too complex for me.   I 
just want to say that a person can have a role hiring manager, a role 
candidate, a role recruiter, or a role accountant.   So Zope 3 does not 
provide the abstraction that I am looking for.  Which leaves me with 
Zope 2. And I am back to building up my own desired abstractions on Zope 
2.  

My point is not to make this flame war break out again.   I just want to 
make sure there is clear documentation for an alternative point of 
view.   Actually all of the criticism has been very helpful in getting 
me to better understand the issues.

Regards
Chris

>