[Grok-dev] Re: grok futures: the return of the ZMI

[Martin Aspeli]

Hi Martijn,

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 
Plone.

  - 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 
Archetypes did.

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.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book