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

[Philipp von Weitershausen]

Martijn Faassen wrote:
> Philipp von Weitershausen wrote:
> [snip]
>> grok.Application is a bit of a confusing itself, I think. Especially 
>> when we allow WSGI, we'll have a "WSGI app" which is distinctly 
>> something different from the "grok.Application". The "WSGI app" is 
>> more like what you consider an application above: something that you run.
> 
> That's an interesting point. We have two levels here that are crossing 
> over and confusing people:
> 
> * starting applications in your OS. Of course in some cases someone 
> *else* might be running the server in which case you won't have to do this.
> 
> * web applications. In many cases someone else is running the web 
> application for you so you don't see these either, except as URL.
> 
> Basically we have "applications in an application". We could call the 
> outer application "application server" to avoid this confusion. An 
> application server can run one or more grok.Applications.
> 
> I'm not sure how WSGI app fits in this. Could you elaborate?

A WSGI app is the thing that deals with incoming requests. In any Zope 
application, this task will be handed off to the publisher, of course. 
The publisher turns the WSGI streams and environments into nice objects 
(request and response), and then traverses the object hierarchy, finding 
our grok.Application. This is really just one object in the object graph 
that is traversed over. I think it deserves a better name. It's only 
conceptually an application to us.

Note that web applications that build on Zope, meaning their WSGI app is 
really just a shim over the Zope publisher, can still have a lot of 
control over how the application is started up in the app_factory (a 
PasteDeploy thing). Typically, applications want to parse zope.conf 
here, then execute site.zcml and then open ZODB databases.

I think it is very useful to be able to override things here on an web 
application per web application basis. That's why the app_factory is 
always defined in each project generated by zopeproject (and the same 
will happen for grokproject soonish). For instance, you can easily 
create ZODB-less appliations this way (provided that you find a 
publication implementation that doesn't need one) because the startup 
code is in your control.


-- 
http://worldcookery.com -- Professional Zope documentation and training