[ZPatterns] Model/View/Controller in Zope?

Jean Jordaan [email protected]
Thu, 30 Jan 2003 17:48:39 +0200


Hi all,

Referring to this thread:
http://lists.zope.org/pipermail/zope-dev/2002-September/thread.html#17492

In particular, this post:
http://lists.zope.org/pipermail/zope-dev/2002-September/017578.html
where Craeg Strong writes:

   Our application is a typical forms-based business app.  Each page
   is a ZPT with one or more forms on it.  Each business transaction
   is encapsulated by a Command (a la GOF Command pattern).  That
   gives us "undo", logging, etc. for every command in a uniform way
   and separates business logic from GUI logic.

   Every business object is published at a unique URL. [...]

We find ourselves going down exactly this route.
At the moment, we're at the point of defining the web face of our
framework (i.e. forms, views, URLs, etc), and I wanted to revisit
ways of implementing Model/View/Controller in Zope.

So far, our framework looks like this:

  Our application is a Zope Python Product, call it App. App is a
  ZPatterns Specialist in the ZODB. For each Class defined in App,
  the following is generated:

  - a Specialist (which provides methods defined in Class) to
    manage all instances of the class,

  - a Data Manager which encapsulates storage (RDBMS, LDAP, ...),

  - and web forms and views.

  We autogenerate SQL and SkinScript from the Class schema.
  All the autogenerated code can easily be overridden.

  Forms and views are expressed as Python classes that are
  seperate from the Class schema, uncoupling the UI from the
  business logic embodied in the Class. The forms and views are
  surfaced as ZPTs in Filesystem Directory Views in CMF skins,
  so they can be customized through the web.

  Sorry if that's terribly cryptic, please ask if you're
  interested in more detail.

That takes care of the business logic. What remains to be done
is the user's flow of through-the-web navigation. We aim to
have a Controller, which overrides
__before_publishing_traverse__. It then examines traverse_subpath,
the user's State, and the context, to determine the right next
URL to hand off to and set the next State.

Have any of you implemented this kind of pattern? Or do you
know of somewhere we could look for tips?

Thanks,
-- 
Jean Jordaan
http://www.upfrontsystems.co.za