I will put together a simple session tool that can be used to replace
setTemp() and getTemp().  We should document this in the tutorial.

--------------------------------------------
Quinton McCombs
NequalsOne - HealthCare marketing tools
mailto:[EMAIL PROTECTED]
http://www.NequalsOne.com 

> -----Original Message-----
> From: Chris K Chew [mailto:[EMAIL PROTECTED] 
> Sent: Friday, March 21, 2003 11:50 AM
> To: Turbine Developers List
> Subject: RE: Tool Scoles (test application url inside. :-) )
> 
> 
> Hi Henning.
> 
> I like the idea of a Tool tutorial.
> 
> For other readers, note that the war is mapped to /app, so I 
> started tomcat and browsed to 
> http://localhost/tooltime-1.0/app/ to get started.
> 
> FYI, I couldn't get the "Restart new Session" link to work 
> with IE6, with or without cookies.  I think this is something 
> we would want to work on before it is rolled out.
> 
> As far as the doco, how do you picture the logistics working? 
>  Do we put the war and source on the turbine web server, and 
> then refer to it in the Tools section?
> 
> And as far as the authorized tool scope, I am a big fan of 
> it.  I also agree with Quinton that session tools should be 
> available pre and post login. Putting session tools in the 
> session seems like a logical why to do this.  I have secretly 
> thought for some time now that user.setTemp() was awkward.  I 
> would like to see an official way of storing things in the 
> session directly.
> 
> Thanks,
> 
> Chris
> 
> > -----Original Message-----
> > From: Henning P. Schmiedehausen [mailto:[EMAIL PROTECTED]
> > Sent: Friday, March 21, 2003 6:57 AM
> > To: [EMAIL PROTECTED]
> > Subject: Tool Scoles (test application url inside. :-) )
> >
> >
> > "Quinton McCombs" <[EMAIL PROTECTED]> writes:
> >
> > >> If you have a session tool added with the anonymous 
> user, you get 
> > >> these added to the anonymous users temp data. This 
> happens in the 
> > >> Velocity Service _before_ the login action is run. Now 
> you log an 
> > >> user in and get a new user object _without_ the session 
> tools and 
> > >> your first screen will not have any session tools.
> >
> > Quinton,
> >
> > it is much worse. Even with the current code, the session 
> tools might 
> > change if an user logs in a second time while the first is still 
> > active.
> >
> > I was thinking long and hard about this but didn't come to a really 
> > good idea. So I decided to get a little more visual about the tool 
> > scopes and wrote a test application. :-)
> >
> > You can get it from
> >
> > ftp://ftp.hometree.net/pub/java/tooltime/tooltime-1.0.war
> >
> > and the source from
> >
> > ftp://ftp.hometree.net/pub/java/tooltime/tooltime-1.0.tar.gz
> >
> > The included turbine-2.3-dev.jar has a few patches, 
> noticeably one for 
> > debugging the pool code which forces the pool to hand out a 
> new object 
> > for each request until the pool is half full. By doing so, you will 
> > catch bugs where you expect to get the same object all the 
> time but in 
> > reality the object goes through the pool, gets recycled and you get 
> > the same object by accident (or because there isn't enough 
> pressure on 
> > the pool).
> >
> > You can control this behaviour by setting 
> > services.PoolService.pool.debug to true or false. I intent to put 
> > these fixes into the jakarta repository sometime later.
> >
> > This might be interesting for people not too much into this 
> specific 
> > problems; the source/war contains a working (:-) ) application on 
> > Turbine-2.3 dev HEAD using pull tools and a dummy security service 
> > (you can log on with any user and any password and get 
> authenticated).
> >
> > You can try this app out by simply dropping the .war into 
> your webapps 
> > directory of your servlet container and restarting (or deploying, 
> > whatever).  Success stories welcome!
> >
> > Chris, I'm more than willing to donate that code to the 
> documentation 
> > project as an example for tool scopes and stuff. Please 
> take look at 
> > it.
> >
> > The displayed ids are the HashCodes of the tool objects, you can 
> > verify which object you got by looking at the ids.
> >
> > There are two authentication scopes in this applications. 
> They can be 
> > used simultaneously.
> >
> > - The "classic" Turbine scope. The app has either an anonymous User
> >   object which is never logged in or a "real" user which is 
> logged in.
> >
> > - A scope with I use in one application. Here you can select a user
> >   first and then authenticate it later (no, in the real 
> application you
> >   must authenticate in the first step too, there is no simple 
> > pulldown)
> >
> >   Here you can have
> >
> >   - an anonymous user which is never logged in
> >   - a real user object that has never logged in
> >   - a real user object that is logged in
> >   - a real ser object that is not logged in but has been logged in 
> > before
> >
> > Problems that I currently see:
> >
> >   - Tools right after selecting the user compared to the tools after
> >     the next "Reload page"
> >
> >   - Tools right after authorization compared to the tools after the
> >     next "Reload page". Same after "unauthorize".
> >
> >   - The session tools "jump" if you log in the same user 
> from two browser
> >     windows (set "accept cookies" to false in your browser or the
> >     container to provide cookie free session ids) with different 
> > sessions.
> >
> >
> > I will think about the tool scopes on the weekend and send out some 
> > ideas while doing so. Discussion very welcome!
> >
> > >But this is a breaking change.  It has been possible up 
> until now to
> >
> > Yep. I have such a comment in our internal CVS, I forgot to 
> transfer 
> > it to jakarta. My fault, sorry.
> >
> > >have session pull tools available before the user logs in. 
>  There is 
> > >a Scarab issue for the the issue with losing the session 
> scope tools 
> > >after the login executes.  I have a simple hack in my 
> application to 
> > >avoid this problem.
> >
> > Ok, we definitely need to think about this much harder. =:-(
> >
> > >I am looking at a way to fix the problem with session scope tools 
> > >being removed by login.  IMHO, session scope tools should 
> not be in 
> > >the user. They should be in the session.  I just don't have this 
> > >working cleanly enough to commit yet.
> >
> > Yes.
> >
> >     Regards
> >             Henning
> >
> > --
> > Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
> > [EMAIL PROTECTED]        +49 9131 50 654 0   http://www.intermeta.de/
> >
> > Java, perl, Solaris, Linux, xSP Consulting, Web Services freelance 
> > consultant -- Jakarta Turbine Development  -- hero for hire
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to