This notion of implementing fbplyons as middleware comes from the
original Facebook-for-Python implementation, pyfacebook. As a package,
it provided WSGI middleware that put a "facebook" object in the
request's environment that a programmer could talk to without having
to deal with all those ugly Facebook request parameters. I believe it
stripped them out of the request in the process, leaving it ugliness-
free. There is parsimony in that, methinks.
Much more impressive "magic" could be implemented by allowing an
fbplyons middleware to filter the response as well. For example, it
would be exceedingly simple to insert the requisite HTML tag options
and <div> in an HTML response, thereby transparently returning a
document that loaded the Facebook javascript library and allowing for
quick XFBML site construction.
In general, though, dealing with the various authentication states is
a little bit tricky. "Is the user logged in?" "Is the user in the
canvas?" "Has the user granted extended permissions?" I've found that
I like to implement these sort of checks as decorators on my
controller methods, a design pattern that was promoted by pyfacebook.
In building fbpylons I've been experimenting with a syntax like this:
class MyController( ... ) :
@require( fbrequest.has_auth() or fbresponse.get_auth() )
def someprotectedmethod( self, .... ) : ....
In this case, fbrequest and fbresponse are objects instantiated from
classes that inherit from classes in fbpylons. The fbpylons classes
provide some basic functionality, the child classes use it to
implement application-relevant behavior.
In my mind, the major drawback of working with a middleware would be
that such application-specific customization of basic fbpylons
functionality would be difficult to achieve. If you wanted to do
anything really complicated, you'd have to send messages, presumably
via the response object, to the middleware. The fbpylons middleware
would probably also need to be overloaded to handle the messages. At
that point, it seems to me that you're probably breaking the
"middleware is for general functionality, controllers are for
application-specific behavior" rule.
Thoughts?
~br
On Aug 29, 9:58 pm, cd34 <[email protected]> wrote:
> One thing I seriously debated was whether a single Pylons instance
> would be used per app, or, whether a single Pylons instance would have
> multiple controllers, each handling a separate Facebook application.
>
> Currently, I have one Nginx with uWsgi (4 threads on a quadcore) that
> talks to a single Pylons instance. I have three different Facebook
> applications that utilize the Pylons virtualenv and three separate
> controllers. While the applications are somewhat interconnected and
> share the same database, tables are separated with prefixes for the
> non-interconnected pieces. I do have two other apps, one that uses
> Apache2/mod_wsgi/Django and one that uses Apache2/mod_wsgi/Pylons.
> I'm working on another using Nginx/uwsgi and Tornado for a portion.
>
> In my case, I felt creating separate virtualenvs outweighed some of
> the other issues I would run into. Whether my requirements justify a
> more generic approach, I don't know.
>
> As for whether it should be middleware, or a new controller, I think I
> would like to avoid it being middleware, though, I can see advantages
> for both.
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
