wsgiappfilter
Christian Wyglendowski
I added the wsgiappfilter to CP over the weekend. To make it work like
the other built-in filters, I modified it so it can be controlled
through the config system. Thus you can add an external WSGI
application to CP through the config file.
I'm not so sure I like that, but I want to get feedback from others.
Should one be able to "mount" external apps in the config system, or
should that continue to happen exclusively in code with
cherrypy.tree.mount?
I would lean towards the latter, but that would mean that the
wsgiappfilter would behave differently than the other built-ins.
Whadda we do?
Christian
http://www.dowski.com
Kevin Dangoor
> Should one be able to "mount" external apps in the config system, or
> should that continue to happen exclusively in code with
> cherrypy.tree.mount?
>
> I would lean towards the latter, but that would mean that the
> wsgiappfilter would behave differently than the other built-ins.
Tricky. That means that you're either treating external apps different
than cherrypy apps or wsgiappfilter different than other filters.
I haven't looked at what mechanism is used to mount external apps in
the config system, but if you could make something mount CP apps that
way as well, then you've cleared up some inconsistency.
It seems to me that wsgiappfilter *is* somewhat different from others
in terms of what it's doing, so it may not be unreasonable for it to
behave differently.
Kevin
Christian Wyglendowski
> It seems to me that wsgiappfilter *is* somewhat different from others
> in terms of what it's doing, so it may not be unreasonable for it to
> behave differently.
That's the direction I am leaning. Using an external WSGI app along
with some CP apps would look like this:
import cherrypy
# and then maybe ...
from cherrypy.lib.cptools import WSGIApp
# ... since it is a convenience class that uses the filter
import mymainsite
import cpblog, cpforum
from webpystats import stats_wsgi_app
# other stuff
# ...
cherrypy.tree.mount(mymainsite.Root(), '/')
cherrypy.tree.mount(WSGIApp(stats_wsgi_app), '/stats')
cherrypy.tree.mount(cpblog.Blog(), '/weblog')
cherrypy.tree.mount(cpforum.Forum(), '/forum')
Hhhmmm.
Christian
http://www.dowski.com
Robert Brewer
> I added the wsgiappfilter to CP over the weekend. To make it
> work like
> the other built-in filters, I modified it so it can be controlled
> through the config system. Thus you can add an external WSGI
> application to CP through the config file.
>
> I'm not so sure I like that, but I want to get feedback from others.
>
> should that continue to happen exclusively in code with
> cherrypy.tree.mount?
>
> I would lean towards the latter, but that would mean that the
> wsgiappfilter would behave differently than the other built-ins.
Not to put too fine a point on it, but what does "mounting" a WSGI app
inside of CherryPy buy you at all? In other words, why would you wrap it
in CherryPy instead of running it "standalone"?
Robert Brewer
System Architect
Amor Ministries
fuma...@amor.org
Sylvain Hellegouarch
name to a WSGI aware server and a WSGI application. It's so damn confusing.
Robert Brewer a écrit :
Christian Wyglendowski
> Not to put too fine a point on it, but what does "mounting" a WSGI app
> inside of CherryPy buy you at all? In other words, why would you wrap it
> in CherryPy instead of running it "standalone"?
That's a perfectly valid question.
To me, it buys flexibility and simplicity. I can have a single site
running behind Apache + mod_proxy (or what have you) that is really a
combination of a couple CherryPy applications, a PyBloxsom blog and a
web.py forum. I can define the URL space in my CherryPy application
alone, so when I look at my site layout in CP I am seeing the big
picture. I also don't have to resort to 3rd party applications or
middleware to glue stuff together.
I can also apply CherryPy filters to hosted WSGI applications. I can
use the CP session filter with the web.py forum:
cherrypy.tree.mount(WSGIApp(webpy.forum_app, {'sess':cherrypy.session})
Those are just a few things I see. If it doesn't seem like a good fit
to everyone else though, I am fine with keeping it a standalone filter.
Christian
http://www.dowski.com
Remi Delon
I also think that the "wsgi_filter" is not really a filter anyway so I like
this syntax.
The question is: how do you configure the "stats_wsgi_app" ?
Remi.
Christian Wyglendowski
Kevin wrote:
>>> It seems to me that wsgiappfilter *is* somewhat different from others
>>> in terms of what it's doing, so it may not be unreasonable for it to
>>> behave differently.
Christian wrote:
>> That's the direction I am leaning. Using an external WSGI app along
>> with some CP apps would look like this:
[snip my example]
Remi wrote:
> I also think that the "wsgi_filter" is not really a filter anyway so I like
> this syntax.
Cool. That will simplify the filter a bit and seems like a more natural
way to use it. I'll make those changes soon.
> The question is: how do you configure the "stats_wsgi_app" ?
Well, that depends on that app. It should load its own config file or
pull config values from elsewhere. Or maybe there is a make_stats_app()
function that takes a dictionary of config parameters and returns a WSGI
callable that is properly configured.
Looking at a real-life scenario (why didn't I do that in the first
place?), PyBloxsom reads configuration settings from a config.py file.
I think that MoinMoin uses a similar setup for each wiki instance.
I guess the bottom line is that each external WSGI application will
probably need to be configured differently.
Christian
http://www.dowski.com