"Damjan" <[EMAIL PROTECTED]> writes:
> Exactly, but TurboGears needs to make use of it... for example the
> decorator:
> @identity.require(identity.in_group("admin"))
> would use the WSGI environ['REMOTE_USER'] to create a User object and
> check it's permissions..
Hmmm... From what I've been seeing it is somewhat transparente. Your WSGI
middleware receives two parameters -- env and a method -- and then process
it. Inside "env" there would be the information needed to validate the
username and password. The other parameter would be called "on success" (for
this case) and would proceed with your application. On failure you could do
something else.
So, you don't really need to be bound to the exactly same syntax that we have
now. And I believe that this is one of the things that will make us work
more.
On the other hand, I might be wrong on my thoughts since I haven't studied or
played much with WSGI (it's on my plans...).
> Also what about sessions? There are several interesting WSGI session
> middleware implementations alredy (supporting memcache for ex.). Will
> it be easy to plgug any of those in TG-2.0?
Again, from what I understand WSGI decouples your application from a normal
flow. You just have to pass information for several middlewares and things
will get going. Your own application will be kind of a middleware in that it
will have access to the same things, the difference is that it will interact
with the user and also have much of the business logic.
--
Jorge Godoy <[EMAIL PROTECTED]>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears Trunk" 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/turbogears-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---
