Hafeliel wrote:

If you could, please take a moment to surf on over to

to understand the design choices made in zope, one could summarize its evolution as:

- 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 published URLs

- protecting potentially hundreds of python objects from being accessed anonymously

- 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 - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to