> -----Original Message----- > From: Henning P. Schmiedehausen [mailto:[EMAIL PROTECTED] > Sent: Saturday, March 22, 2003 6:36 AM > To: [EMAIL PROTECTED] > Subject: Re: cvs commit: jakarta-turbine-2/xdocs changes.xml > > > [EMAIL PROTECTED] writes: > > >quintonm 2003/03/21 14:29:36 > > > Modified: xdocs changes.xml > > Log: > > Added information about the deprecation of User.getPerm(), > > User.setPerm(), and perm scope pull tools. Also added > info about the > > new sessionData pull tool. > > This went a little fast with me. > > If I understand you correctly, you want to have > > global - No discussion here > request - No discussion here > > (I'm starting to wonder whether the original Turbine apps had > only tools of these scopes so the real problems were never > really visible. :-) )
A good point. Once we get the documentation into better shape, I think that we will see more people using the different scopes. > session - bound to the java session, > instantiated when the > session is set up and cleaned up when the session > is unbound. > > > authorized - added when the user is authorized, removed when the > user is no longer authorized. Might be put in the > user temp table > > > persistent - Up to now: Bound to the user object, > serialized at User > Logout. > > From now on: No longer directly supported. > Will be gone > post 2.3 (which means we must not break > them pre-2.3!) > > > > + A new pull tool is available in the session scope > called $sessionData. > > + This tool can be used to store data that will > persist for the duration > > + of the session. This should be used instead of the > getTemp() and > > + setTemp() methods in TurbineUser. > > This is too muddled for me. Up until now, setTemp and getTemp > (which do still exist and I have no intention of deprecating > them yet) are bound to the User object. Your suggested > replacement is bound to the session which has a distinct > different scope. It does have a little different scope. However, the primary reason for storing data in this manner was to have data that persistented across requests. I am not suggesting that we deprecated setTemp and getTemp in the user object although I would have no objections. This simply makes it easy to store data in the session without having to worry about dealing with the session object directly. I just don't like the idea of storing temporary data in the user object. I don't have a convincing argument of why it is wrong though. > 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]
