Ben Bangert wrote:
> Controllers can now be set to a WSGI app, like so:
>
> #controllers/wsgi.py
> from base import *
>
> def myWSGIAppFromSomewhereElse(environ, start_response):
> start_response('200 OK', [['Content-type','text/plain']])
> yield str(environ['pylons.r'].environ)
> yield 'Yup, I work'
>
> WsgiController = myWSGIAppFromSomewhereElse
Perfect!
> In the meantime, I'll load up the WSGI vars like this:
>
> pylons.request - obj - Request object
> pylons.m - obj - Myghty 'request' object
> pylons.session - dict - Session object
> pylons.params - dict - Params that would've been passed into
> the controller method (these come from Routes mainly)
> pylons.action - str - Action from Routes
> pylons.controller - str - Controller from Routes
I strongly prefer what was suggested to start with. Looking at this I
have to think to myself, "is pylons.request the r object?" and then I
think, "because pylons.request is r perhaps pylons.params isn't params?"
so it just becomes more confusing. I can see why you want to give things
sensible names but in this case the names have already been decided for
us and calling them something else seems to me to just confuse the matter.
How about this instead:
myghty.r - obj - Request object
myghty.m - obj - Myghty 'request' object
myghty.s - obj - Session object
pylons.action - str - Action from Routes
pylons.controller - str - Controller from Routes
pylons.params - the params
I prefer this since it is instantly obvious what is what. If we want to
we can then set things like pylons.session which can be the same object
as myghty.s so that users need only worry about things named pylons.*
but can access myghty.m and myghty.r if they like.
In fact at the moment what we seem to be doing is finding a happy medium
between exposing the Myghty API and creating a new Pylons one. How about
we agree to stop trying to integrate Myghty variables and state that
users will always do something through a pylons API which exposes the
Myghty one?
If we agree this we can change Pylons actions to this:
def action(self, pylons, ...):
...
instead of r, m etc. Users just learn to always add a pylons variable
after self. Conceptually going from class method to Pylons controller
method it isn't too different from learning to add a self variable going
from function to method.
This pylons object would provide all the Myghty functions through
pylons.myghty. We can then create methods like the
render_comp(controller='name', action='something', id=4) as
pylons.render.comp() so that the only object the user needs to worry
about anywhere in their application is the pylons object.
Another advantage of encapsulating all the functionality in one object
is that it would be much easier to use Cheetah or some other templating
language. You'd just pass the Pylons object in and a large part of the
functionality would still be available.
The more I think about this the more I like it. A lot of the Pylons
functions would map straight onto their Myghty counterparts so there
wouldn't be a lot of programming, just a lot of thinking about how best
to design the overall API.
James