> -----Original Message----- > From: Dan Allen [mailto:[EMAIL PROTECTED] > Sent: Monday, September 13, 2004 8:34 AM > To: Struts Users Mailing List > Subject: the real world is always dirtier > > > 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."
yucky. > > 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. That's what session attributes are for. > > 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. You're manager may be an idiot on this... depending on platform, settings etc. Most importantly, everything you put in the session must be serializable in order for the servers to pass around the session data. I would also be interested in knowing why, in your case, server affinity would be such a bad idea? If server affinity is a bad idea, why not upgrade your server to something that can handle session attibutes better in a clustered environment? I've said this before, and I'll say it again, you can demonstably prove that you do not save money through bad engineering to avoid buying more servers. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
