[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.
Martin
--
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