[Grok-dev] Re: Admin UI name change suggestion
faassen at startifact.com
Fri Oct 5 04:46:11 EDT 2007
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.
It'd be a good idea to look at ways to make such deployment more easy.
That doesn't mean I think it necessarily should affect development, or
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?
Taking over the Zope root doesn't appear necessary to accomplish this
effect. The benefit to doing so would be that the system is potentially
somewhat more simple in the end, but this seems minor as the classic
Zope 3 root isn't that complicated, and it's going to be hidden anyway.
The benefit of a traversal trick is that it seems simpler to implement,
we have more compatibility with existing applications, and it's far
easier to switch back to a 'multiple applications in one root' model.
More information about the Grok-dev