Lennart Regebro wrote:

On 4/26/07, Dieter Maurer <[EMAIL PROTECTED]> 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.


Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to