On Dec 18, 2007 4:06 PM, Ben Bangert <[EMAIL PROTECTED]> wrote: > 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.
People have really been asking that? I always thought, "Wow, Pylons provides sessions for me, cool! And I didn't have to write the persistence code myself!" So if you import it from beaker.middleware, does it still have to be a StackedObjectProxy? If not, why does it have to be a SOP when imported from one place but not from another? If yes, how does PylonsApp know to register it; is it hardcoded? -- Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en -~----------~----~----~----~------~----~------~--~---
