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.

You have an incredibly annoying tendency to take the words of someone "important", drop their name and qualify their "importance" and then bend their statements to fit your point of view. Alex co-founded Plone, and I'm sure he likes being referred to as an expert on HCI, but he didn't exactly say that the path you're going down has much merit either.

What there seems to be support for, is that in a CMS like Plone, administrators may have a need to define schemata (as in - I want these fields with these labels and this validation) for content types, in order to capture domain-specific information. That is, within the high-level UI constructs which Plone affords all content.

There does not seem to be very much support for building complex systems, with significant amounts of custom logic TTW. By all means, knock yourself out, but at least try to weigh the arguments that are being presented.

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.

Grok (or Archetypes in Plone) would allow you to build that in a couple of lines of code, and ArchGenXML (with Archetypes/Plone) in a couple of clicks in ArgoUML.

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.

I'd contend that you possibly haven't quite understood how these things would work in Zope 3, and if you are going to build your own abstractions anyway, you will probably find it *way* easier to do that on top of Zope 3's primitives than Zope 2's. I've been developing on top of Zope 2 (with Plone) for a long time, and I still find things like product factories and dispatchers and the security model confusing. By contrast, the ones in Zope 3 are better documented and burdened by a lot less legacy.

Zope 2 still has a lot going for it, and is evolving and growing and I still love it, but if you're about to set out building some new development tool, and you don't already understand the low level of what you're about to try to plug into, you'll probably find it much easier to start with a copy of Web Component Development with Zope 3 ( and Zope 3.


Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to