[Twisted-Python] New Guard question

Glyph Lefkowitz glyph at twistedmatrix.com
Mon Jun 23 02:20:17 MDT 2003


On Monday, June 23, 2003, at 12:02 PM, Jonathan Lange wrote:

> So, I guess this means that for a web application with that allows 
> anonymous
> users to do and see many things on many pages, there'll be many Portal 
> and
> Realm instances? Or is this where the mysterious mind comes into play?

Assuming you mean a single application, there will be one Portal to 
access the site, one Realm to dish out resources, and then each 
resource will return a tree.  But, of course, "application" is a funny 
word; if you are making a site that integrates lots of different 
pre-existing components there may be multiple Realms, arranged in some 
sort of hierarchy with rules for how and when one dispatches to 
another.  (For example, the top-level Realm, attached to the Portal, 
may specify that a certain child URL maps to another Realm's IResource 
children, and that the user is preauthenticated ... this will probably 
need some infrastructure work.)

> Also, your badidea example didn't really help me. Firstly, I don't use 
> weird
> guard sessions, I just use normal sessions.

"normal" sessions are kinda broken; you should probably update your 
code to use guarded sessions.  In fact, I sure would like to deprecate 
the old session code (for reasons related to browser eccentricities 
that are out of scope for this discussion) but I will probably never be 
able to because it's so widely used at this point.

> Secondly, much of the if/then logic is wrapped in Views that provide 
> patterns to the templates. Example:
>
> <div view="authProtected">
>   <span pattern="anonymous"><a href="login">Login</a></span>
>   <span pattern="loggedIn"><a href="logout">Logout</a>
>     (<a view="personLink"/>)</span>
> </div>
>
> It's hard to see how to do this with guard.

Your Realm will return a View which wraps a Model.  The anonymous model 
is different from the logged-in one, but the top-level Views will 
likely be of the same class.  You might want to write a generic 
'switch' view that looks something like this:

<div view="switch" attribute="hasUser">
   <span case="1"><a href="logout">Logout</a></span>
   <span case="0"><a href="login">Login</a></span>
</div>

If this is not obvious - the idea is that you specify a submodel (or 
perhaps some other interface which the View can talk to) "hasUser".  
The 'anonymous' model will say "0" and the logged-in-user model will 
say "1".  This kind of functionality is also useful to specify 
'template adapters' in your template code, to specify different display 
styles in-line in a list for different model classes.

I've done this in ad-hoc ways once or twice; I should probably check in 
a "real" version to woven at some point.

> This email is probably premature, as I'm still fiddling around with 
> some
> trivial examples trying to get stuff to work. (Examples using 
> Page.wchild_*
> and getDynamicChild methods, rather than resource.putChild)

Nevertheless, I don't have the time to write coherent documentation for 
this stuff right now, so hopefully these emails are generating fodder 
for someone who can :).





More information about the Twisted-Python mailing list