This nice thing about examples is that they are so clean and pretty. The real world just hands you a shovel and says "Start moving this horse crap."
I have an application in which there are a handful of parameters that are required on each page, regardless of its content, to represent the general state of things (maybe needed now, maybe down the road a bit). Such parameters include user id, preference filter, section of site, and so on. The way things are currently done to handle is baggage is to just pass it around wherever a form or link is used as a "extra params" or "hidden fields." Now, I consider myself a "Pragmatic Programmer" and I am smart enough to recognize that this smells really, really bad. It violates several principles, including DRY and non-orthogonal. I also believe I have a solution, but I want to discuss it here. My thought would be to initialize a state object and put it in either the http session or a session bean and then each page can work with this state object as a general filter when executing business logic. This way, each form and link will be just the core data needed for that particular request, without all this general information. The state object would either be initialized on an entry action or at the start of every action, depending on what is feasible at the time. Now, I haven't done this so far, because my manager (use the term loosely) told me that using http sessions will cause server affinity in a cluster. If http sessions are out, I suppose I could lean towards session beans. First I would like to challenge his point on sessions, and if that doesn't pan out, discuss if stashing this in sessionbeans is the right way to go. Dan -- Open Source Advocacy http://www.mojavelinux.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
