On Nov 8, 2007, at 2:21 PM, Mike Orr wrote:
+1It's straightforward to tell the user, "Use self._py_request instead of pylons.request in bla bla circumstances... and self._render. By the way, all controller instance variables are private to the current request and thread, so there may be more added later."
Well, private methods in a controller start with _, so ppl do write helper methods for their controller that being with _, possibly including _request, or _render. In fact, one of my projects has a variant of the render that is hanging off self._render all ready.
- users asks for them in function args We get in the way of anyone wanting to use request, response, session, or c as a routes dict variable+0.5 It also violates the rule that action args come from the routes dict and from no other place. Having two kinds of args here is as messy as passing both template options and data variables as keyword args to render() -- another of my pet peeves. Plus, what if Pylons adds another SOP later?
That rule isn't totally strict right now, as you can actually ask for environ and start_response on an action, and you'll get them. So it still seems better to have one special one used rarely in the function args, vs preventing the user from using a half dozen private controller methods.
So I'm still leaning toward a single pylons object that looks and feels similar to the existing pylons. API. I have that version of it in the pylons-dev source right now, so we can play with it and see how it feels.
Action names won't begin with an underscore. They may conflict with utility methods, but users don't have any business naming those ._pylons_c.
I'd still consider that awfully inconvenient, self._pylons_c = ... vs: pylons.c = ....I'm open to trying them both out in a few examples, and seeing what the experience is like (which one tastes better?). :)
Cheers, Ben
smime.p7s
Description: S/MIME cryptographic signature
