I think having objects in the session is no good solution. It might have a little bit of global variables, but thats only my 0.02$. I try to group objects into own contexts - I call it action-contexts, and allow actions only write information in these context. So you have better control which objects may removed.
I am currently programming an other solution with descriptions of an object flow. Than you can create an object-flow, where it is described which objects may "walk" from ohne action to an other. So it is guaranteed, that action see only those objects, that are designed for it and not objects, that other action has leaved in the session or application context.
As my work I have seen the struts-chain project, which has an other focus but still act with action-contexts too. So it might be a better idea to combine this in the environment of the struts-chain project, because it is necassary to have a chain that do these things.
Below you see a little specifications of my ideas. If they become more concreteness I may write you. You can follow these things in the open source project "struts-it" which is in a very early beginning state an is hosted by sourceforge.
My ideas are as follows:
-->
Usually the data that will be shared from one struts action-class to an other will be stored in the session-context. There are several problems mainly in large projects with many developer by doing this:
- The data are not well typed. So problems with wrong type casts might come into being at runtime.
- Nobody takes care that the entries will be deleted.
- Many entries will be accumulate so that nobody has an overview of entries which have been saved.
- Actions have access to data that aren't designed for them.
There are some other suggestions why it might be good to have an context that is independent from the normally contexts like servlet-, session-, request- and page context:
- In struts there are no informations "where you come from". An action context can offer paths where the framework may navigate back.
- In struts there is no chance to check preconditions that maybe fulfilled to entry the action. A context may give information if an action can be executed.
- There are usually informations in every struts application that an action needs e.g. an user, roles and perhaps rights.
The context interface offers methods to load and save objects in a manner that does other contexts in the Http-Environment.The Map, that saves the attributes may not be synchronized, perhaps a context is only used in a single thread.
Requirementlist:
- Posibility to have typed and generic contextes. ActionContext may be an interface.
- Posibility to maintenance live cycle perhaps like a mechanism as TTL fields in the TCP/IP protocol ore lifeguard of objects.
- Generic Copying from data from one context to an other. In this case it has to be described which action accept which type of context
- Stack "where do you come from" for navigating back and forward like a wizzard.
... to be continued
Manfred
Vinicius Carvalho wrote:
Hi there! I was wondering of how to keep my session clean, I mean, don't overload it with a lot of objects. Sometimes I need to register some objects in the session scope for a certain group of pages in my application, after the client leaves that (could be an item of a menu for example), I'd like to destroy every session registred that I won't use in my application. I was thinking if is there any Pattern for this? I first though in using a filter to check in a associative array, to verify whenever the session objects are needed in the current path.
Any suggestions for this?
Thnx
Vinicius
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- =========================================== Dipl.-Inf. Manfred Wolff ------------------------------------------- phone neusta : +49 421 20696-27 phone : +49 421 534522 mobil : +49 178 49 18 434 eFax : +49 1212 6 626 63 965 33 ------------------------------------------- ____________________________________________________ Diese E-Mail enth�lt m�glicherweise vertrauliche und/oder rechtlich gesch�tzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrt�mlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
