[Grok-dev] Re: grok futures: the return of the ZMI
optilude at gmx.net
Sat Jan 5 15:26:15 EST 2008
I think this is a very interesting post. I don't have time to answer in
kind, but I'll give you a run-down of our experiences and thoughts from
- TTW template, CSS, image and other resource customisation is a very
important use case for us. This is part of what makes Plone attractive
to new developers, and it makes some operations very quick in Plone land.
- TTW programming causes more harm than good, unless you're careful
and you know what you're doing, you're likely to end up with a mess. If
your're careful and you know what you're doing, you're likely to be
happier with a filesystem development model anyway.
- People aren't afraid of the filesystem. They're afraid of elaborate
and time-consuming configuration and setup. We've had reasonable success
with Paste Script-based templates that get people up-and-running
quickly. The more convention-over-configuration this is the better (ZCML
slugs must die...).
Pylons has a nice model here. You run "paster create -t pylons" to
create a new project. Then you run "paster controller MyController"
inside your new package (this is a "local command" in Paste speak) to
create a new package. Some people (Mustapa Benali and others) have been
working on doing this for Archetypes content types in Plone. The
advantage of this approach is that you get "best practice" code in an
instant, all you have to do is fill in the blanks.
- In Plone (4?), we want to have a model of TTW schema definition.
Zope 3's content model (schemata in interfaces, formlib or similar for
forms, annotations for data storage, events) makes this easier than
We think this may involve some kind of hybrid, where a schema
(interface) is persisted to a module (since you need that for
persistence support), but loaded at runtime from an XML file that
describes the entire content type. By having an actual type interface
which can be introspected at run time, we can support a migration path
from something that's TTW defined to something that's filesystem defined.
For example, say a "business user" creates a schema via a TTW UI. This
is ultimately saved to an XML file and then used to build (at runtime
and subsequently on startup) a schema (and an FTI and other Ploneish
stuff). Then, say a "developer" wants to send an email each time an
object of this type is edited. If we don't have a TTW construct for
this, the developer can write some (filesystem) code that defines an
event handler for (IMyContentType, IObjectModifiedEvent). Or, he could
write an adapter of IMyContentType to add some new behaviour. Or, he
could move more of the interface from XML-based to Python-based, perhaps
with some tool that could write out the Python code from an XML file.
That's a very high level sketch, and there are some challenges with this
(security, for example), but we think it's doable, and I'd like to make
as much of that re-usable and shareable. Tres Seaver already has some
code in the userschema package that can create a schema interface from a
CSV (Excel) file, an XML file or an HTML form.
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
More information about the Grok-dev