[<<] Industrie Toulouse

I wish I was here (almost). At the SolutionsLinux Expo, a Zope 3 UI sprint is happening, based on Jim Fulton's Through-The-Web development proposal. This is an area where Zope 2 gets tough when you:

  1. Want to make persistent content objects in Python (aka "Products")
  2. Don't want to use the CMF (it's too heavy for the project in question)
  3. Don't want to use ZClasses (lack of familiarity)
  4. Want to keep the application specific pieces (ie - "browser views", page templates and python scripts) defined in the ZODB, and not on the file system, for a richer UI. Yet the content objects need to get bound to views somehow, and those views have to exist somewhere logical so that they can be maintained easily using tools like Adobe GoLive.

This is not an unreasonable list. And usually ZClasses, using your Python products as the base class, do a reasonable job of holding view-level information, particularly if you refer to a common containing template (standard look and feel - typically "standard_template.pt" for page templates and the duo "standard_html_header/footer" for DTML). But for my application to work, this wasn't a valid solution (for reasons longer than I can go into at this time).

Much Zope development, particularly project's I've been involved in, have operated on one of two axioms:

  1. First class views, second class data. This is where the data is coming from a non-ZODB source, such as a relational database, and the primary structure of the website is folders of templates/scripts/sql. This is similar to most web development.
  2. First class data, second class views. This is where the primary structure of the site is made out of content objects, and the views are coming in from another source. This can be the filesystem and DTMLFile/PageTemplateFile objects, or the complex (and powerful) CMF "Skins" system, which is a folder containing a multitude of folders whose namespaces get compacted down to one where they can be accessed by the content objects in the ZODB. Usually there are some intervening tools to define which names to look for (ie - what's the edit form, what's the view template, etc).

What I'm needing - at the very least - is something like the second (first class data) without the weight of the CMF if I don't need it. I'm hoping that Zope 3 can deliver on this somehow. There's already a lot of really cool things you can do with views in Zope 3, at least at the file system level, that have been tricky to do up until now. Hopefully the Z3 UI sprint at SolutionsLinux can yield something decent here.