On Dec 18, 2007, at 1:07 AM, Mike Orr wrote:
Ugh, you really expect people to want to memorize this? Sessions are supposed to be built into megaframeworks, not require some obscure import. "I think I'll just use Rails instead; it's more straightforward."
No, I expect someone using sessions to read the session docs, and the first thing it says is to add that line. Or it could be commented out but included. The thing is, Pylons is not a megaframework, its the opposite, its a lightweight framework, that loosly couples some WSGI components into a WSGI stack and puts the stack under your control.
Notice that in the middleware.py now, you import SessionMiddleware and put it in your stack. How does it help a user understand things when PylonsApp then goes and makes another reference to the object made by SessionMiddleware and stashes it in pylons.session?
Consider how simple sessions and the WSGI layer can be explained:Beaker has middleware that sets up and handles sessions for you, by adding the SessionMiddleware to your stack, you can now use sessions in your controllers. Import beaker's session like so ....... then proceed to use them in your controller.
The user now knows exactly where it came from, what it does, and how to *not* use it as well. There is no ambiguity, and no explanations needed later about, "oh, so why do you import it from pylons when beaker actually does everything? uhh.... well....". It provides a better picture of how things are assembled, without magic or unknown tasks wrapped up in PylonsApp for literally no other reason than having another session reference in a different spot.
Of course, there's never anything stopping someone from continuing 'from lib.base import *' and doing the session import there. Those that aren't 'scared' or annoyed by that would be welcome to do that.
Cheers, Ben
smime.p7s
Description: S/MIME cryptographic signature
