[Grok-dev] Re: Admin UI name change suggestion
Philipp von Weitershausen
philipp at weitershausen.de
Fri Oct 5 05:31:19 EDT 2007
Jan-Wijbrand Kolman wrote:
> * So far I did not have the experience of finding people confused having
> to place an grok.Application inside the application server "root".
> Philipp says he *does* have this experience; can you explain why you
> think these people were confused?
They were just thrown off by the fact that you have to instantiate this
beast at all. And give it a name. And that it's not simply the root.
> * I think it should be *possible* in a very easy way to configure your
> grok.Application to "take over the zope root", no doubt about that, but
> there's valid use cases to have a zope root that contains multiple
> applications. The argument that grok.Applications can be nested
> basically says that the "root" grok.Application (in whatever way it is
> determined what grok.Application subclass this will be) is a zope root
> again - well, we have that infrastructure already...
Yup. I actually envision something that you have in your Paste WSGI
def application_factory(global_conf, ...):
# load zope.conf, site.zcml, etc.
# open database
Basically, during Zope starup, it will install the TodoList application
into the root (unless it's already installed). You can easily change
to get the current behaviour back.
> * It is not clear to me how you would delete the grok.Application and
> re-add it again during development. It is something you do all the
> time., esp. in the beginning of the development cycle. This also touches
> the issue of intergrating your grok.Application with other Zope-3 based
We could simply add a view for grok.Applications, e.g. /recreate, that
would delete the object and create a new one. *That* I think is easily
> * The idea of using port numbers to point to individual applications
> sounds kinda elegant. However, this means that you have to have a
> frontend server to make it all get served on port 80 to the outside
> world. You can argue that for production, you will have a frontend
> server anyway. Well yes, I fully agree, but we have infrastructure
> already to translate URLs to applications, it is the virtual hosting
Right. If you want different ports for different apps, then what's the
point in using one instance/sandbox? You might just as well bring
several separate Zopes.
> In other words, I personally think the status quo gives us almost the
> full set of flexibility we want already. And by adding the *option* to
> have a grok.Applcation take over the "root" we will complete it.
I think the option of taking over the root should be the default. It's
the most sensible one. Grok is all about making choices for you. Keeping
it simple for starters.
I don't think people who get started immediately want the ability to
have multiple apps in their instance. They don't see the point yet (and
they don't see the point of the admin UI yet for this reason). They just
want to get started, without understanding this yet.
The multiple apps use case is for us experts. I think with what I've
outlined above (change the root object factory in the WSGI app factory),
we experts can easily achieve what we need: flexibility.
http://worldcookery.com -- Professional Zope documentation and training
More information about the Grok-dev