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

[Uli Fouquet]

Hi Shane,

Am Freitag, den 21.09.2007, 16:37 -0600 schrieb Shane Hathaway:

> > 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.

It's more my ignorance and dumbness than a bad sign ;-) But that was,
what I called drawback.

> 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.

Charming :-) I'd support this approach. What do others think? Anyway,
for the beginning we need the admin UI to be a separate application. I
will start this right after the upcoming sprint.

Until then people might consider apache or some other frontend and
virtual host root rewriting to map subdirectories to the root.

Thanks for this idea and

kind regards,

-- 
Uli