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

[Lennart Regebro]

I totallt agree with what Paul writes here. Although I thing that
schema and workflow editing is not something that Grok should do, but
rather something to be written *with* grok. :)

I do like the ideas CRUD/BREAD support and that would be very ZMI-like
indeed. I think it's important to point out that in a Grok world, such
a thing would not be a part of Grok, as the ZMI was a part of Zope,
but that rather such a CRUD/BREAD application is in fact just another
application.

So it doesn't need to be a part of Grok core. However, it's so useful
that it could be argued that it *should* be. :)

On Jan 7, 2008 8:13 PM, Paul Everitt <paul at zeapartners.org> wrote:
>
> 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
> >
>
>
> _______________________________________________
> Grok-dev mailing list
> Grok-dev at zope.org
> http://mail.zope.org/mailman/listinfo/grok-dev
>



-- 
Lennart Regebro: Zope and Plone consulting.
http://www.colliberty.com/
+33 661 58 14 64