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

Paul Everitt paul at zeapartners.org
Mon Jan 7 14:13:38 EST 2008

My oh my, what a thread. :^)

Like Martin, I don't have enough time at the moment to say too much, but 

1) The ZMI was an outgrowth of Principia, which wanted to hide Python. 
As such, it (for better or worse) brought in a number of people whose 
goal wasn't to do "programming".  (Think of it as: would you rather type 
in Visicalc or write COBOL?)

However, it brought up an interesting point Jon Stahl brought up.  It 
wasn't just that this audience *couldn't* program, it was also that they 
weren't *trusted* to program.  Meaning, you'd never let that group of 
power users ssh into the server, hack stuff, and restart.

I think for customer projects, this is an important point.  It's hard to 
make customers into full-fledged developers of the stack *and* maintain 
a service level agreement.

2) I think ArchGenXML shows that there is a variant of TTW vs. 
Filesystem.  Meaning, people can do meaningful stuff in a pointy-clicky, 
model-driven approach.  They aren't writing anything that would resemble 
code.  But they *are* doing a tremendous amount of business specification.

Thus, a new ZMI wouldn't have to do TTW *development*.  We could leave 
out restricted Python.  We could even leave out ZPT.  In fact, we could 
freaking leave out the browser.  Instead, it would be about 
pointy-clicky model specification.

Instead, produce a "model", as Martin says, that can be checked into SVN 
and address all the concerns about ZODB black box.  It then becomes 

I confess that I'm working on such an idea.  Since I have been full of 
shit on this story since before Martijn Pieters joined Digital 
Creations, I need to keep my mouth shut until I show anything.


Martin Aspeli wrote:
> 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

More information about the Grok-dev mailing list