RE: How do you keep your session junk free?
AFAIK, why not put form bean in hashtable under well known name in application scope - last resort, cause as you mentioned request not applicable, session not available you are in full charge of form bean. populate that bean in application scope as you like from newly created form bean or replace it all at once. Have to e.g. prepend key with user information(getSessionID()) to get same bean for user back? Greets Jörg -Original Message- From: julian green [mailto:[EMAIL PROTECTED] Sent: Freitag, 07. März 2003 10:33 To: Struts Users Mailing List Subject: How do you keep your session junk free? How do you prevent the session from filling up with junk from previous screens? Or to put it another way: I have written some screens that have to store the form bean in the session scope as each screen is interconnected and uses the same instance of the form bean. If I change the scope to request a new form bean is created for each screen (every time a jsp file is rendered). Is there a way of implementing multiple screens with the same form bean with a request scope? Julian - 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]
Re: How do you keep your session junk free?
A few years ago, when Struts was not still available, we programmed a web layer framework much more primitive than Struts but with similar functionality for the project I was involved. One of the functionalities we had was request flow control, so we were sure that the user wasn't going back and forth and we had the right information in the session. Whenever there was a request that was not proper following the current flow, a message error was showed to the user, with the suggestion to begin the flow again. We didn't reach that far, but I think such a functionality may provide a way to define wizards or page flows and let the application have a callback method to clean the session stored in data in case the user leaves the wizard. This is a functionality that I'd love to have in Struts. Right now, I try to clean the session when I reach the final step of such a series of pages, but you are not guaranteed that the user ever reaches it. The other solution is having all the data introduced so far by the user in hidden fields (though I don't recommend it). Jose Jörg Maurer wrote: AFAIK, why not put form bean in hashtable under well known name in application scope - last resort, cause as you mentioned request not applicable, session not available you are in full charge of form bean. populate that bean in application scope as you like from newly created form bean or replace it all at once. Have to e.g. prepend key with user information(getSessionID()) to get same bean for user back? Greets Jörg -Original Message- From: julian green [mailto:[EMAIL PROTECTED] Sent: Freitag, 07. März 2003 10:33 To: Struts Users Mailing List Subject: How do you keep your session junk free? How do you prevent the session from filling up with junk from previous screens? Or to put it another way: I have written some screens that have to store the form bean in the session scope as each screen is interconnected and uses the same instance of the form bean. If I change the scope to request a new form bean is created for each screen (every time a jsp file is rendered). Is there a way of implementing multiple screens with the same form bean with a request scope? Julian - 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]
RE: How do you keep your session junk free?
Take a look at the workflow extension. I think it does something along those lines. http://www.livinglogic.de/Struts/ -Original Message- From: Jose Gonzalez Gomez [mailto:[EMAIL PROTECTED] Sent: Friday, 7 March 2003 20:23 To: Struts Users Mailing List Subject: Re: How do you keep your session junk free? A few years ago, when Struts was not still available, we programmed a web layer framework much more primitive than Struts but with similar functionality for the project I was involved. One of the functionalities we had was request flow control, so we were sure that the user wasn't going back and forth and we had the right information in the session. Whenever there was a request that was not proper following the current flow, a message error was showed to the user, with the suggestion to begin the flow again. We didn't reach that far, but I think such a functionality may provide a way to define wizards or page flows and let the application have a callback method to clean the session stored in data in case the user leaves the wizard. This is a functionality that I'd love to have in Struts. Right now, I try to clean the session when I reach the final step of such a series of pages, but you are not guaranteed that the user ever reaches it. The other solution is having all the data introduced so far by the user in hidden fields (though I don't recommend it). Jose Jörg Maurer wrote: AFAIK, why not put form bean in hashtable under well known name in application scope - last resort, cause as you mentioned request not applicable, session not available you are in full charge of form bean. populate that bean in application scope as you like from newly created form bean or replace it all at once. Have to e.g. prepend key with user information(getSessionID()) to get same bean for user back? Greets Jörg -Original Message- From: julian green [mailto:[EMAIL PROTECTED] Sent: Freitag, 07. März 2003 10:33 To: Struts Users Mailing List Subject: How do you keep your session junk free? How do you prevent the session from filling up with junk from previous screens? Or to put it another way: I have written some screens that have to store the form bean in the session scope as each screen is interconnected and uses the same instance of the form bean. If I change the scope to request a new form bean is created for each screen (every time a jsp file is rendered). Is there a way of implementing multiple screens with the same form bean with a request scope? Julian - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How do you keep your session junk free?
Over on another mailing list I'm on the consensus is that continuation-style programming is much better than the present approaches suggested by struts and other frameworks. In particular, they solve the back button/refresh type problems much more cleanly than other languages/frameworks. As a Lisp programmer I find that appealing, and I just wish people in the Java camp knew more about it.. here are a few links that I've been suggested to follow up (I haven't had the time yet to fully evaluate them :) Unfortunately there doesn't seem to be much by way of tool support for these frameworks (yet). http://www.beta4.com/seaside2 http://segment7.net/ruby-code/borges/borges.html Schecoon -- does anyone know the status on this project btw? http://youpou.lip6.fr/queinnec/Papers/www.ps.gz http://youpou.lip6.fr/queinnec/Papers/webcont.ps.gz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How do you keep your session junk free?
On Fri, 7 Mar 2003 10:34:13 -0500 Sundar Narasimhan [EMAIL PROTECTED] wrote: Over on another mailing list I'm on the consensus is that continuation-style programming is much better than the present approaches suggested by struts and other frameworks. In particular, they solve the back button/refresh type problems much more cleanly than other languages/frameworks. Explain how some other approach handles it in any better way? Use of token to prevent duplicate submissions works for me. And what do you mean by a continuation-style programming? -- Rick Reumann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How do you keep your session junk free?
Explain how some other approach handles it in any better way? Use of token to prevent duplicate submissions works for me. And what do you mean by a continuation-style programming? The token approach is an easy solution. One of the sites listed was a Smalltalk web framework. It's good to look at things in different ways but you could probably count the number of Smalltalk web applications on one hand :-). David _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How do you keep your session junk free?
Maybe what we need is an abstraction over the current request mapping stuff. If you think about it, what Struts basically does is mapping a request from a browser to some class that then executes a method (I know Struts has a lot more things, but this is the main one). Maybe we could go a step further, and think about wizards, page flows, data associated with those flows, and why not, set the bases for a direct translation from use cases to one of these abstractions. Please, don't take this as criticism to Struts. I think Struts is a great framework and I'm using it and will be using it in whatever J2EE project I do, but maybe we could start thinking a level above... what do you think? Rick Reumann wrote: On Fri, 7 Mar 2003 10:34:13 -0500 Sundar Narasimhan [EMAIL PROTECTED] wrote: Over on another mailing list I'm on the consensus is that continuation-style programming is much better than the present approaches suggested by struts and other frameworks. In particular, they solve the back button/refresh type problems much more cleanly than other languages/frameworks. Explain how some other approach handles it in any better way? Use of token to prevent duplicate submissions works for me. And what do you mean by a continuation-style programming?
Re: How do you keep your session junk free?
It would be neat if you could group a bunch of action definitions together and have the form bean persist while the group remianed active. Julian David Graham wrote: Explain how some other approach handles it in any better way? Use of token to prevent duplicate submissions works for me. And what do you mean by a continuation-style programming? The token approach is an easy solution. One of the sites listed was a Smalltalk web framework. It's good to look at things in different ways but you could probably count the number of Smalltalk web applications on one hand :-). David _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - 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]
Re: How do you keep your session junk free?
I was thinking exactly about that... usually you could identify that bunch of actions as steps inside an use case of the system. The data collected inside that use case usually is useless outside that use case and is usually used to make a call to business logic sitting in EJBs, or business objects with JDO or whatever. (Wow, what a useful word, use). There could be some automated way to keep the data as far as you were inside those actions, and once the use case is finished, or the user aborts this use case and initiates another, the data could be deleted. For this to happen, beans should be associated to these use cases, groups, whatever you call it, instead of being associated to an action. Jose julian green wrote: It would be neat if you could group a bunch of action definitions together and have the form bean persist while the group remianed active. Julian David Graham wrote: Explain how some other approach handles it in any better way? Use of token to prevent duplicate submissions works for me. And what do you mean by a continuation-style programming? The token approach is an easy solution. One of the sites listed was a Smalltalk web framework. It's good to look at things in different ways but you could probably count the number of Smalltalk web applications on one hand :-). David _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - 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]
Re: How do you keep your session junk free?
I kinda have a class that does that if you want. I have an Action called ChainAction that can call N number of actions in a row and passes the same form and request info through all the actions. The last action in the chain is then used to do a foward to whatever. This is how I control all application flow via the struts-config file. Example: action path=/app/campaign/promotion/type/pantryLoading/introAddChain className=com.symbol.mobilecommerce.analysis.struts.ChainActionMapping type=com.symbol.mobilecommerce.analysis.struts.ChainAction name=pantryLoadingIntro set-property property=ROLE value=admin/ set-property property=PROPERTY_NAME value=action/ set-property property=CHAIN value=Do Delete : /app/campaign/promotion/type/pantryLoading/introSaveMessageAdd, /app/campaign/promotion/type/pantryLoading/deleteBitmapAdd, /app/campaign/promotion/type/pantryLoading/introAddPage/ set-property property=CHAIN value=Add Bitmap : /app/campaign/promotion/type/pantryLoading/introSaveMessageAdd, /app/campaign/promotion/type/pantryLoading/addBitmapAdd, /app/campaign/promotion/type/pantryLoading/introEditPage/ set-property property=CHAIN value=Next: /app/campaign/promotion/type/pantryLoading/introSaveMessageAdd, /app/campaign/promotion/type/pantryLoading/messageTypeAddChain/ forward name=PAGE_CHAIN_ERROR path=/app/campaign/promotion/type/pantryLoading/introAddPage.do/ forward name=PAGE_ACCESS_DENIED path=/app/campaign/promotion/mainPage.do/ /action This action does security first (we have a custom system that does role based security down to the action level). If the user does not have access it send them up the chain one step. They continue up the chain till they hit a point where they do have access. This way we get them to ass deep as they can go (get your mind out of the gutter). Anway.. The chains work by defining a PROPERTY_NAME that relates to an any element in a form. In this case, submit buttons. If the user clicked Do Delete it sends them to introSaveMessageAdd and then to deleteBitmap, and then to the introAddPage. This way my actions a very modular. You can also do a DECHAIN which will run through the actions like normal but the last one is treated as a seperate request and gets a new form and request object (good for going from one form to another and not having bean issues). It also does other things like you can defined a message to put into the session at the end of the chain, etc... Anyway.. I can see if I can release the code if you want. - Original Message - From: julian green [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Friday, March 07, 2003 11:04 AM Subject: Re: How do you keep your session junk free? It would be neat if you could group a bunch of action definitions together and have the form bean persist while the group remianed active. Julian David Graham wrote: Explain how some other approach handles it in any better way? Use of token to prevent duplicate submissions works for me. And what do you mean by a continuation-style programming? The token approach is an easy solution. One of the sites listed was a Smalltalk web framework. It's good to look at things in different ways but you could probably count the number of Smalltalk web applications on one hand :-). David _ Help STOP SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail - 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]
Re: How do you keep your session junk free?
El vie, 07-03-2003 a las 13:00, Jose Gonzalez Gomez escribió: Please, don't take this as criticism to Struts. I think Struts is a great framework and I'm using it and will be using it in whatever J2EE project I do, but maybe we could start thinking a level above... what do you think? I'm no expert, and I apologyse if I'm wrong here, but I think Expresso Framework has this wizard functionality. Doesn't it? Love, Margarita. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How do you keep your session junk free?
Does this model include a means of managing the session objects (I would assume yes, but didn't see anything to that effect)? That is the real problem with wizards or wizard-like control flows. I had cooked up a similar idea, but haven't implemented it yet, because all the wizards already had been built here using hidden fields to pass along values before I started. I'll prolly test it out if we have another wizard come along. In the idea outlined below, I'm using the single parameter attribute, but you could use the set-property attribs as well I guess...do these only exist in Struts 1.1? Note that the part at the bottom, Extension, is something that I would definitely do...I just haven't reformated these notes yet. In a nutshell: Notes for a 1-per-session wizard framework: 1. Use a single wizard bag in session, just an object that contains a hashtable plus identifying logical name for the wizard for which we are storing objects. 2. Use the parameter attribute in action mapping to give logical name of wizard that this action is a part of, if it is a wizard action. Action classes that are used both in and out of wizards should have multiple mappings-a mapping with a wizard parameter should be used only inside a wizard flow. 3. In abstract action superclass, test to see if actionmapping's parameter has a value. 4. If parameter has no value, remove the wizard bag from the session if it exists, as we are no longer in a wizard. 5. If parameter has a value: If no wizard bag exists in session, create one with the parameter's value as the logical name. If the wizard bag does exist in the session, see if it's logical name matches the parameter value-if it doesn't, remove the wizard bag and create a new one with the current parameter value, as we have jumped to a new wizard. 6. Our abstract superclass will have protected methods to access the wizard bag, for use by wizard subclasses: storeWizardObject(String key, Object o); getWizardObject(String key); removeWizardObject(String key); Extension: Use a naming scheme for the parameter values in our wizard actionmappings: wizardName_step#. For example: createEmployee_1, createEmployee_2, etc. We would use the same rules as above, except we would always create a new wizard bag in step one of the wizard (and drop the current one even if it already exists). We would also verify that the wizard bag with our current wizard's logical name already exists in subsequent steps, and if it doesn't, forward to an exception page (because this means we either lost the wizard bag in the middle of the process due to another client browser's request (in the same session), or we jumped into the middle of the wizard somehow - see #2 above). Having the step number may be useful for other purposes as well. --joe -Original Message- From: Sloan Seaman [mailto:[EMAIL PROTECTED] Sent: Friday, March 07, 2003 8:33 AM To: Struts Users Mailing List Subject: Re: How do you keep your session junk free? I kinda have a class that does that if you want. I have an Action called ChainAction that can call N number of actions in a row and passes the same form and request info through all the actions. The last action in the chain is then used to do a foward to whatever. This is how I control all application flow via the struts-config file. Example: action path=/app/campaign/promotion/type/pantryLoading/introAddChain className=com.symbol.mobilecommerce.analysis.struts.ChainActi onMapping type=com.symbol.mobilecommerce.analysis.struts.ChainAction name=pantryLoadingIntro set-property property=ROLE value=admin/ set-property property=PROPERTY_NAME value=action/ set-property property=CHAIN value=Do Delete : /app/campaign/promotion/type/pantryLoading/introSaveMessageAdd, /app/campaign/promotion/type/pantryLoading/deleteBitmapAdd, /app/campaign/promotion/type/pantryLoading/introAddPage/ set-property property=CHAIN value=Add Bitmap : /app/campaign/promotion/type/pantryLoading/introSaveMessageAdd, /app/campaign/promotion/type/pantryLoading/addBitmapAdd, /app/campaign/promotion/type/pantryLoading/introEditPage/ set-property property=CHAIN value=Next: /app/campaign/promotion/type/pantryLoading/introSaveMessageAdd, /app/campaign/promotion/type/pantryLoading/messageTypeAddChain/ forward name=PAGE_CHAIN_ERROR path=/app/campaign/promotion/type/pantryLoading/introAddPage.do/ forward name=PAGE_ACCESS_DENIED path=/app/campaign/promotion/mainPage.do/ /action This action does security first (we have a custom system that does role based security down to the action level). If the user does not have access it send them up the chain one step. They continue up the chain till they hit a point where they do have access. This way we get them to ass deep as they can go (get your mind out of the gutter). Anway.. The chains work
Re: How do you keep your session junk free?
Explain how some other approach handles it in any better way? Use of token to prevent duplicate submissions works for me. And what do you mean by a continuation-style programming? Hi, Rick: CPS is a commonly accepted idiom for representing what a program does next in your language. Some languages such as Scheme (a lisp variant/dialect) have strong support for it.. In languages such as these.. you can actually write int x = 5; x = getValue1(); y = getValue2(); where getValue1 and getValue2 display the appropriate pages etc., and when the user hits the back button your program's state gets unwound to the point where it should be.. w/out ANY extra coding! You as a coder wouldn't have to write any code to set the variable x's value back to what it was etc. Obviuosly in languages w/out continuations and closures, people tend to simulate them w/ tokens, inner classes etc., but these are VERY POOR substitutes for these things. If you google those terms I'm sure you'll get enough hits to keep you busy for a while (I personally learnt cps stuff when I worked w/ Jeff Siskind's Screamer which augmented Lisp with non-deterministic primitives :). I think some of the scheme papers wrt. continuations are classics, and explain how you can do things like co-routines etc. w/ them. Be prepared to bend your mind a lot though -- I've never been able to teach continuations easily -- most programmers (me included) who grew up with Fortran, Pascal and C etc. have a *very hard* time grokking them initially. If you run across good explanations that help you understand it, let me know.. I'm always looking for new pedagogical tools for this. (I understand that both Python and Ruby camps are investigating adding support for this sort of thing :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How do you keep your session junk free?
On Fri, 7 Mar 2003 14:03:08 -0500 Sundar Narasimhan [EMAIL PROTECTED] wrote: Explain how some other approach handles it in any better way? Use of token to prevent duplicate submissions works for me. And what do you mean by a continuation-style programming? Hi, Rick: CPS is a commonly accepted idiom for representing what a program does next in your language. Some languages such as Scheme (a lisp variant/dialect) have strong support for it.. In languages such as these.. you can actually write int x = 5; x = getValue1(); y = getValue2(); where getValue1 and getValue2 display the appropriate pages etc., and when the user hits the back button your program's state gets unwound to the point where it should be.. w/out ANY extra coding! You as a coder wouldn't have to write any code to set the variable x's value back to what it was etc. Very interesting, thanks for the information. Can this kind of behavior be achieved though simply by hitting a browser back button? I wouldn't think that would be possible without using javascript to resubmit the page or to make sure a fresh page was always being looked at? -- Rick Reumann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How do you keep your session junk free?
On Friday, Mar 7, 2003, at 14:16 US/Eastern, Rick Reumann wrote: Very interesting, thanks for the information. Can this kind of behavior be achieved though simply by hitting a browser back button? I wouldn't think that would be possible without using javascript to resubmit the page or to make sure a fresh page was always being looked at? Sorry to drop in like that, but what is the problem with using Tokens? just doing a setToken() before you forward to a jsp page, then doing a isTokenValid() when the action is called, usually on page submit, is enough to stop anything. Even if they click the back button then hit submit, won't work. If they reload the page with the form, they get a new token since reloading calls the action which sent them to the page with the token in the first place. So far it works for me, and in the isTokenValid() check I just forward to a 'you can't resubmit this page dorkie, or you'll give me headaches' page, and all is just fine... plus you can do it in different languages by putting the warning text in the resources.properties file. what more is needed here?
Re: How do you keep your session junk free?
The 1-per-session stuff, you might as well just use the session object to do the storage otherwise you are just adding overhead by putting a Hashtable into a Hashtable just to do get/put. I name all my variable that go into my session object com.symbol.mobilecommerce.so on to make sure I don't clobber anything else. You could also do the storage based on something like javax.xml.namespace.QName to be real unique... The extension idea is not bad. But defining by number can be a pain. If you have 50 steps (1-50) and you have to insert a new one a 2, then you have to renumber the rest. I'd come up with some sort of linked list if I were you. I've got an open source business rules engine that I wrote that someone is supposed to be making into a work flow manager for struts... that may be good as well I'll have to see how far it has come along I don't have anything for session mgmt as of yet myself but it has crossed my mind that it could be an issue. One of the things my ChainAction inherits from a HelperAction I have is the ability to do a set-property property=REMOVE_BEAN value=bean/form name/ That helps in keeping things out of the action that may be coming in. Another thing I do to make it more flexible is that I wrote a class that extends HttpServletRequestWrapper that allows me to put my own parameters in so that the request object going to the action actually has parameters inserted in from my ActionChain. This way the action being chained to can act like it was just taking a normal http request when in fact the ChainAction may be inserting things (as directed from the struts-config) to help it out. Works rather nicely and I have had no session related issues as of yet. I have been thinking about implementing something that would do session storage based on where you are in a package and would make the session variables accessible only if you were in that package. Think private/protected variables like in Java... Now I'm working on a generic action that will use different forwarders based on the calling action. This is because right now I have an ADD and an EDIT action path in my struts-config.xml because if something fails it has to climb back the chain properly for the user. With the new class I am writing if going to an EDIT action fails (say because the db bean didn't exist) it flips over to the ADD. Then, when the user clicks the Next it flips back to the EDIT path, and if that edit doesn't work, flips to ADD, and so on. Lets the user go down an application path in a nice failover manner... Anyway.. that was off topic... but I figured it might be of interest to someone... -- Sloan - Original Message - From: Joe Barefoot [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Friday, March 07, 2003 2:00 PM Subject: RE: How do you keep your session junk free? Does this model include a means of managing the session objects (I would assume yes, but didn't see anything to that effect)? That is the real problem with wizards or wizard-like control flows. I had cooked up a similar idea, but haven't implemented it yet, because all the wizards already had been built here using hidden fields to pass along values before I started. I'll prolly test it out if we have another wizard come along. In the idea outlined below, I'm using the single parameter attribute, but you could use the set-property attribs as well I guess...do these only exist in Struts 1.1? Note that the part at the bottom, Extension, is something that I would definitely do...I just haven't reformated these notes yet. In a nutshell: Notes for a 1-per-session wizard framework: 1. Use a single wizard bag in session, just an object that contains a hashtable plus identifying logical name for the wizard for which we are storing objects. 2. Use the parameter attribute in action mapping to give logical name of wizard that this action is a part of, if it is a wizard action. Action classes that are used both in and out of wizards should have multiple mappings-a mapping with a wizard parameter should be used only inside a wizard flow. 3. In abstract action superclass, test to see if actionmapping's parameter has a value. 4. If parameter has no value, remove the wizard bag from the session if it exists, as we are no longer in a wizard. 5. If parameter has a value: If no wizard bag exists in session, create one with the parameter's value as the logical name. If the wizard bag does exist in the session, see if it's logical name matches the parameter value-if it doesn't, remove the wizard bag and create a new one with the current parameter value, as we have jumped to a new wizard. 6. Our abstract superclass will have protected methods to access the wizard bag, for use by wizard subclasses: storeWizardObject(String key, Object o); getWizardObject(String key); removeWizardObject(String key); Extension: Use a naming scheme for the parameter values in our wizard actionmappings: wizardName_step
RE: How do you keep your session junk free?
Interesting. We are less concerned about work flow that being able to create wizards using session objects, and have them cleaned up in a timely fashion. I think it's nice to be able to manage extra parameters via the actionMapping as you are doing, but to be honest managing everything via request objects in workflows/wizards is a real pain in the ass, I've found. I would much rather be able to store things on the session from actions and have them reliably cleaned up in some fashion, hence the 1-per-session notions I cooked up. The reason you have to have the member Hashtable: The WizardBag (or whatever you call it) needs to have the wizard's logical name stored as a field. One would use a separate, static name as the key to store the bag on the session (WizardBag, or whatever). That way you only have one wizard object as opposed to many session objects on the session. If you just use the session, it is impossible to know what objects have been placed there by sub-classes, and defeats the purpose of automatic session management for a 1-per-session wizard. This way, you only look up the WizardBag object, check it's logical name, yada-yada, and keep, delete, or create it depending on your actionmapping's parameter value. Sub-classes would use inherited methods to store objects in the WizardBag's Hashtable and retrieve them. Using this or a similar framework, it would be fairly easy to store session objects in a 1-wizard-allowed-per-session model and expect those objects to be cleaned up. I haven't been able to come up with anything else. peace, Joe -Original Message- From: Sloan Seaman [mailto:[EMAIL PROTECTED] Sent: Friday, March 07, 2003 12:07 PM To: Struts Users Mailing List Subject: Re: How do you keep your session junk free? The 1-per-session stuff, you might as well just use the session object to do the storage otherwise you are just adding overhead by putting a Hashtable into a Hashtable just to do get/put. I name all my variable that go into my session object com.symbol.mobilecommerce.so on to make sure I don't clobber anything else. You could also do the storage based on something like javax.xml.namespace.QName to be real unique... The extension idea is not bad. But defining by number can be a pain. If you have 50 steps (1-50) and you have to insert a new one a 2, then you have to renumber the rest. I'd come up with some sort of linked list if I were you. I've got an open source business rules engine that I wrote that someone is supposed to be making into a work flow manager for struts... that may be good as well I'll have to see how far it has come along I don't have anything for session mgmt as of yet myself but it has crossed my mind that it could be an issue. One of the things my ChainAction inherits from a HelperAction I have is the ability to do a set-property property=REMOVE_BEAN value=bean/form name/ That helps in keeping things out of the action that may be coming in. Another thing I do to make it more flexible is that I wrote a class that extends HttpServletRequestWrapper that allows me to put my own parameters in so that the request object going to the action actually has parameters inserted in from my ActionChain. This way the action being chained to can act like it was just taking a normal http request when in fact the ChainAction may be inserting things (as directed from the struts-config) to help it out. Works rather nicely and I have had no session related issues as of yet. I have been thinking about implementing something that would do session storage based on where you are in a package and would make the session variables accessible only if you were in that package. Think private/protected variables like in Java... Now I'm working on a generic action that will use different forwarders based on the calling action. This is because right now I have an ADD and an EDIT action path in my struts-config.xml because if something fails it has to climb back the chain properly for the user. With the new class I am writing if going to an EDIT action fails (say because the db bean didn't exist) it flips over to the ADD. Then, when the user clicks the Next it flips back to the EDIT path, and if that edit doesn't work, flips to ADD, and so on. Lets the user go down an application path in a nice failover manner... Anyway.. that was off topic... but I figured it might be of interest to someone... -- Sloan - Original Message - From: Joe Barefoot [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Friday, March 07, 2003 2:00 PM Subject: RE: How do you keep your session junk free? Does this model include a means of managing the session objects (I would assume yes, but didn't see anything to that effect)? That is the real problem with wizards or wizard-like control flows. I had
RE: How do you keep your session junk free?
What we are doing is (not very efficient, but easy and quick to program), we have a class that gets the session and path as parameter. Then this class checks to see what attributes are absolutely required for a path and it removes the rest. We are then calling this class from the processPreprocess hook of ActionServlet. So now by default this class is called for each request and thus session gets cleaned up (at the cost of a little extra processing). -Original Message- From: Joe Barefoot [mailto:[EMAIL PROTECTED] Sent: Friday, March 07, 2003 2:44 PM To: Struts Users Mailing List Subject: RE: How do you keep your session junk free? Interesting. We are less concerned about work flow that being able to create wizards using session objects, and have them cleaned up in a timely fashion. I think it's nice to be able to manage extra parameters via the actionMapping as you are doing, but to be honest managing everything via request objects in workflows/wizards is a real pain in the ass, I've found. I would much rather be able to store things on the session from actions and have them reliably cleaned up in some fashion, hence the 1-per-session notions I cooked up. The reason you have to have the member Hashtable: The WizardBag (or whatever you call it) needs to have the wizard's logical name stored as a field. One would use a separate, static name as the key to store the bag on the session (WizardBag, or whatever). That way you only have one wizard object as opposed to many session objects on the session. If you just use the session, it is impossible to know what objects have been placed there by sub-classes, and defeats the purpose of automatic session management for a 1-per-session wizard. This way, you only look up the WizardBag object, check it's logical name, yada-yada, and keep, delete, or create it depending on your actionmapping's parameter value. Sub-classes would use inherited methods to store objects in the WizardBag's Hashtable and retrieve them. Using this or a similar framework, it would be fairly easy to store session objects in a 1-wizard-allowed-per-session model and expect those objects to be cleaned up. I haven't been able to come up with anything else. peace, Joe -Original Message- From: Sloan Seaman [mailto:[EMAIL PROTECTED] Sent: Friday, March 07, 2003 12:07 PM To: Struts Users Mailing List Subject: Re: How do you keep your session junk free? The 1-per-session stuff, you might as well just use the session object to do the storage otherwise you are just adding overhead by putting a Hashtable into a Hashtable just to do get/put. I name all my variable that go into my session object com.symbol.mobilecommerce.so on to make sure I don't clobber anything else. You could also do the storage based on something like javax.xml.namespace.QName to be real unique... The extension idea is not bad. But defining by number can be a pain. If you have 50 steps (1-50) and you have to insert a new one a 2, then you have to renumber the rest. I'd come up with some sort of linked list if I were you. I've got an open source business rules engine that I wrote that someone is supposed to be making into a work flow manager for struts... that may be good as well I'll have to see how far it has come along I don't have anything for session mgmt as of yet myself but it has crossed my mind that it could be an issue. One of the things my ChainAction inherits from a HelperAction I have is the ability to do a set-property property=REMOVE_BEAN value=bean/form name/ That helps in keeping things out of the action that may be coming in. Another thing I do to make it more flexible is that I wrote a class that extends HttpServletRequestWrapper that allows me to put my own parameters in so that the request object going to the action actually has parameters inserted in from my ActionChain. This way the action being chained to can act like it was just taking a normal http request when in fact the ChainAction may be inserting things (as directed from the struts-config) to help it out. Works rather nicely and I have had no session related issues as of yet. I have been thinking about implementing something that would do session storage based on where you are in a package and would make the session variables accessible only if you were in that package. Think private/protected variables like in Java... Now I'm working on a generic action that will use different forwarders based on the calling action. This is because right now I have an ADD and an EDIT action path in my struts-config.xml because if something fails it has to climb back the chain properly for the user. With the new class I am writing if going to an EDIT action fails (say because the db bean didn't exist) it flips over to the ADD. Then, when the user clicks the Next it flips back to the EDIT path, and if that edit
