If you could, please take a moment to surf on over to
to understand the design choices made in zope, one could summarize its
- a genuinely great idea that allowed to publish python objects on the
web in a completely transparent way. That was revolutionary at the time
compared to CGI programming.
then starting from here, the rest is mostly about fixing the original
design in order to allow for:
- defining an automatic mapping between objects (and their methods) and
- protecting potentially hundreds of python objects from being accessed
- persisting the changes done on these objects
- finding objects in an object space that knows nothing about unique
ids, indexation, and other query languages
- presenting these objects in a browser
ZODB, acquisition, DTML, ZPT, views, the 5 or 10 different security
models, even zope3, are all attempts at solving these issues in one way
or the other, each layer adding more complexity to the original stack.
Zope developers who have been there since the beginning know about of
all the stacks, other programmers will probably stumble on some
documentation about acquisition or ZClasses, some bobobase or principia
archaisms... and will fail to make sense of it.
Zope maillist - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -