[Grok-dev] Re: letting Grok take over the site

[Shane Hathaway]

Uli Fouquet wrote:
> Hi Shane,
> 
> Am Mittwoch, den 19.09.2007, 17:19 -0600 schrieb Shane Hathaway:
> 
> First many thanks you for your input. Reviewing your proposal, it sounds
> charming.
> 
>> Once you have mapped a different application to the root, how do you
>> access the grok admin UI again, let alone other application instances?
>> ++app++ is one possible solution.
> 
> I see the point. I thought, this would be handled even by a modified
> traverser in a manner, that you can still access root applications by
> their name. If the admin UI was installed as 'grokadmin' then I would
> have expected it to be still accessible as
> 
>      localhost:8080/grokadmin
> 
> This seems to have been a false assumption. 

I'm trying to avoid name collisions.  In your example above, you have
broken any Grok applications that happen to have an object named
"grokadmin".  (This could easily happen if, for example, the application
is a Wiki and someone creates a page about grokadmin!)  You have also
made all other application instances impossible to access.

> Using the ++app++-namespace, you need to inject the namespace to access
> any object in the ZODB (except the one choosen 'root application'),
> right?

Yes, with one clarification: I expect the root folder to hold nothing
but application objects.

> Wouldn't that mean heavy side effects for many existing non-grok
> objects/applications/components?

I don't think so.  We just have to be careful about computing URLs: when
an application is accessed via ++app++, URLs computed for objects
contained in that application must include the ++app++ parameter.  One
way to accomplish that is to set the application's __name__ to
'++app++myapp'.

> BTW: right now, the index page of the admin UI is only a redirect to the
> applications page. This could also be a redirect to any other
> application index page, decoupled from the admin UI (given that the
> admin UI becomes a 'standalone' grok.Application). Maybe modifying the
> index view in an intelligent manner would be a more intuitive approach
> (though less Zope3ish), especially if it comes to
> applications/components, which compute URLs without any knowledge of the
> need to insert the ++app++myname namespace. 
> 
> The drawback would be, that any other view would be dependent of the
> object name: calling '/' would then for example redirect to '/hello' but
> the 'myview' view of the hello-application could only be accessed by
> 'hello/myview' and not by '/myview'.

Some people are willing to mix in Apache just to make the URLs look
right.  'hello/myview' would not be acceptable to them.

I can see that this idea is not easy to explain, and that's a bad sign.
 We should have people continue to use Apache rewriting, like they have
always done with Zope, until we think of something clearly better.

Wait... here's something simpler.  There could be a page in the Grok UI
that lets people configure which application to use by incoming port
number.  For example, I might say that port 8080 serves helloapp, 8081
serves helloapp-dev, and 8082 serves grokadmin.  If the server gets a
request on an unconfigured port, it falls back to grokadmin.  Adding a
port requires a change to zope.conf, but that's easy to explain.  Hmm,
yeah, I like that idea a lot better.  No funny ++app++ names, and if
users accidentally lock themselves out of the grok administration UI,
all they have to do is add another HTTP port to zope.conf.

Shane