[Grok-dev] letting Grok take over the site

Brandon Craig Rhodes brandon at rhodesmill.org
Mon Sep 17 08:48:11 EDT 2007


PvW suggested this belongs in a separate thread, and I agree, since
there's an issue of terminology to settle as well.

There should be a simple way to create a Grok app that "owns the whole
Zope instance" that it runs inside.  People to whom I've shown Grok
are confused that, having written my app, I don't just get to access
it at the root "/" URL of my web site.  They don't understand why I
should have to then enter a GUI and instantiate my app.

And, really, they are even more concerned that everything inside of my
web app then lives "one level deep" beneath the app name.  They don't
like the idea of having an extra level to type and deal with in URLs.
And my telling them that we can proxy Grok behind something that
removes the extra level does not make them much happier.  Though they
agree in principle that proxying is a good thing, they don't like it
to be necessary.

So it would be neat to have a Grok component named something like
"Site" that you could inherit from to build an app that owns the root:

 class MyApp(grok.Site, grok.Container):
     ...

But here we hit a terminology conflict - there already seems to be a
notion of a "Site" in Grok, and it does *not* mean the whole web site!
There is a function called "grok.getSite()" that, contrary to its
name, returns the application instance you are running inside of!  One
would have thought it would have been called "getApplication()" so
that it would be symmetric with the class name "grok.Application".

It would therefore seem most consistent if:

 - grok.Application declared an application.
 - grok.getApplication() returned the application you're inside of.
 - By default you were inside of a site that holds Grok app instances.
 - grok.getSite() returns the root of the whole site.
 - By inheriting an object from grok.Site, your code could take it over.

But this would, of course, though making things more consistent, break
existing code, so I'm open to other ideas about how this should be
accomplished.  Thanks for any input!

-- 
Brandon Craig Rhodes   brandon at rhodesmill.org   http://rhodesmill.org/brandon


More information about the Grok-dev mailing list