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

Martin Aspeli optilude at gmx.net
Tue Jan 8 03:52:09 EST 2008

Wichert Akkerman wrote:
> Previously Martijn Faassen wrote:
>> Paul Everitt wrote:
>> [snip]
>>> 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.
>> What you describe is a slightly different area then the one I'd like to 
>> tackle with the ZPT step (though the model step is related). Allowing 
>> ZPT overrides indeed opens up the danger of untrusted people going in 
>> and breaking things. I hope that can be mitigated by allowing good 
>> export facilities to the filesystem-style of development.
>> Also whatever it was worth, people *did* use the ZMI for TTW 
>> development, and it was very popular for a while until the drawbacks 
>> became clear. There's just about nothing that beats "Hello world" in the 
>> Zope 2 ZMI in speed of development.
> There is a very important use case for Plone that may be just as
> important for grok: being able to quickly make changes that are
> immediately visible without any access to the filesystem or needing an
> application restart. This is extremely useful when you get a support
> call from a customer and you need to make a change without being
> able to have access to the server. In my experience that is a common
> scenario. Another useful benefit is being able to very quickly test
> small changes (most often layout tweaks).

I suspect this kind of use case is more valid when it comes to 
customisable applications such as Plone, than at the level of the 
development framework. That is, this is something you do *after* you've 
built and deployed the application. That doesn't mean Grok shouldn't 
have this feature available as an optional (maybe default-on) feature 
for application builders (and I think it should). However, the message 
to developers is subtly different: You're not saying "start here", 
you're saying "here's a powerful tool for experimentation and bespoke 
customisation of any application".

For the most basic "start here" use case, I think grokproject/Paste 
Script are more appropriate.


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 mailing list