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

[Philipp von Weitershausen]

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 
application factory:

   def application_factory(global_conf, ...):
       # load zope.conf, site.zcml, etc.
       # open database

       install_root_object(factory=todolist.app.TodoList)

       return zope.app.wsgi.PublisherWSGIApplication(...)


Basically, during Zope starup, it will install the TodoList application 
into the root (unless it's already installed). You can easily change 
this, e.g.:

       install_root_object(factory=zope.app.folder.rootFolder)

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

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

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

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