On Sun, Aug 15, 2010 at 11:31 AM, BrianTheLion <[email protected]> wrote: > Thanks again for all the advice, guys. I've been tooling around with > my code this week and I think I've made significant (mental) progress > on this issue of building complicated UIs out smaller, well- > encapsulated, reusable pieces. I'll give a full report on that later - > folks may find it useful - but first I'd like to address a new > question that has come up in my explorations: > > How do you know when to build middleware?
Writing middleware is hard to get right; there are unexpected edge cases. If you do write middleware, using WebOb makes it much easier because it handles them for you. So I would put middleware last in priority, below a shared function library. But there are certain tasks that fit the middleware paradigm well, so I just think about implementing it both ways and see which one feels more elegant. > Let's take authentication as an example. I find myself building a proj/ > lib package for handing lots of common authentication operations. The > authentication process makes heavy use of certain parameters of the > request that, by-and-large, the rest of the application doesn't care > about. I started thinking about having my proj/lib code store the > relevant parameters and then delete them from the request. That's what > got me thinking about middleware; permanently modifying the request is > something that middleware - not application code - tends to do. > > The fact is that the meat of the application is altogether agnostic to > the authentication process, forcing me to wonder if the authentication > code should "live" inside the application at all. For encapsulation > purposes, it would seem like moving it to middeware makes sense. "Want > to change the auth protocol? Just replace the middleware." Sounds > great, but I'm worried that there may be some GOTCHAs hiding around > the corner. For auth, what do you need to do that Repoze.who/what doesn't, especially if you write a plugin class for it? It's best to use an expertly-supported middleware rather than writing your own, unless it's a bad fit for your application. There are simple auth schemes, but they're implemented in the application rather than middleware. http://wiki.pylonshq.com/display/pylonscookbook/Authentication+and+Authorization Authorization is normally in the application anyway, unless it's a blanket yes-or-no for the entire site. -- Mike Orr <[email protected]> -- 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.
