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#. 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 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] > > --------------------------------------------------------------------- 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]
