On Sat, 4 Jan 2003 09:58, you wrote: > > i think the OBJECT_DATA column should be removed ... it's > > easy to extend > > the user object .. > > > > martin > > Do we need to keep the access counter? I can't imagine why this > would even be of use to anyone.... If we do (and I suppose it can't > hurt anything), it should get its own column.
Hi Quinton, The problem the access counter was designed to solve is that when a user hits refresh, an action could be performed twice. >From John McNally: ----------- To use this you keep a session counter and embed the current count in the form. Then check the request count parameter with the session counter to see if it is stale. There is code in the default session validators that does this and a session counter is incremented in $data.User.AccessCounterForSession. This can be used to internally redirect the user to an error screen asking them to refrain from using the back/reload button and does not require a redirect for every action that is requested. ----------- Regards, -- Rodney > We should change the storage of the persistent pull tools to a new > column or simply drop support for persistent pull tools. The only > benefit that you would get out of a persistent pull tool is that its > state would be automatically saved between sessions. It seems that a > better implementaion would be to store the state information from the > pull tool into additional columns either in TURBINE_USER (by > extending) or a separate table altogether. > > If those two issues are addressed, we can deprecate the methods to > access it in 2.3. It could disappear altogether in a later version. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
