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

[Paul Everitt]

My oh my, what a thread. :^)

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

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 
"through-the-REST".

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.

--Paul

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
>