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

[Philipp von Weitershausen]

Martijn Faassen wrote:
> 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.

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