[Grok-dev] Re: Admin UI name change suggestion
Philipp von Weitershausen
philipp at weitershausen.de
Fri Oct 5 05:22:11 EDT 2007
Martijn Faassen wrote:
> Wichert Akkerman wrote:
>> Previously Martijn Faassen wrote:
>>> How this is actually going to make everyone's life better? So far
>>> I've heard "people are confused", but it's not clear to me that this
>>> change would make people less confused or if so, it would actually
>>> improve their lives?
>> To a large part it is a deployment issue. When I deliver an application
>> to a customer I do not want to have to explain them that they need to
>> login to a ZMI, create an application and setup a rewrite rule in
>> apache to use it.
>> I want to tell them: here is the whole thing. Update buildout.cfg for
>> your specific environment (IP address, port, etc.) and start the
>> Pylons makes this even easier by using a configuration file in which
>> you can also configure the application (useful for things like database
>> connection info). That would be a very welcome next step for grok as
> Okay, point taken. That doesn't explain why so many beginners were
> confused with Grok, so that seems to be a separate issue.
People are just confused by the fact that you have to *instantiate* your
application. The asked me: Why doesn't that grok.Application thing
simply represent /?
> A filesystem-level configuration file sounds like a useful idea. You can
> configure it so that a particular application is installed by default
> upon building out the system (of course this assumes the application
> shouldn't be installed with parameters filled in with some form). If you
> then for some reason decide to go back, it should be very easy to turn
> it back again on the filesystem. Now how would this work in detail?
I have an idea what would make it work well in the Paste scenario (you'd
use the PasteDeploy configuration file). I'll sketch out an implementation.
> The benefit of a traversal trick is that it seems simpler to implement,
I doubt that.
> we have more compatibility with existing applications, and it's far
> easier to switch back to a 'multiple applications in one root' model.
Applications could be nested. I don't see how the "application is the
root" model prevents us from still installing multiple applications. For
instance, you could have a "mother application" if you explicitly wanted
to allow that use case.
http://worldcookery.com -- Professional Zope documentation and training
More information about the Grok-dev