[Grok-dev] Re: Admin UI name change suggestion

[Martijn Faassen]

Wichert Akkerman wrote:
> Previously Martijn Faassen wrote:
[snip]
>> 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
> instance.
> 
> 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
> well.

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 
*all* deployments

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.

Regards,

Martijn