Just to throw a little liquid (gasoline or water) on this fire... Let's say there are two ways to look at determining your current session state: #1 Is the Deterministic Automaton (for any set of inputs there is an output) #2 Is the Nondeterministic Automaton (for any set of inputs the output is unknown)
Some, if not many, applications can have the user interface abstracted as a #1. If this is the case, you can simply pass a series of tokens (the inputs) to determine which page you SHOULD be on. In these cases, passing hidden fields is an highly desirable way of doing business (lends to clustering, no dead sessions hanging around, etc...) On the other hand, other types of interfaces don't lend themselves to this way of doing business: (i.e. they are dependant on internal or unknown factors to determine what to do/display). In these cases, may or may not need a session to determine where you are/where you are going to maintain the proper flow/state of the application. ??Comments?? -----Original Message----- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Monday, February 16, 2004 10:42 AM To: Struts Users Mailing List Subject: Re: [OT] - Request against Session Ah.. I'm having a bad hibernate day instead today so I'm a bit more distracted from this debate. Truth is I'm pretty stupid, my simplistic way of looking at the world tells me that if i need to temporally store data collected from some forms that storing in the session is a way to do this. The api says. "The session persists for a specified time period, across more than one connection or page request from the user." Seems to fit the bill to me. Each form is a request and i need a structure in the web tier to store the data. Until such a time when the user is ready to complete whatever s/he is doing and thus commit everything to the model. I even concede I'm out-gunned in terms of the folk advocating such things, but I just cant see why everyone's so against sessions. I'm in crisis attempting to resolve the incongruity between my and folk's, who know better than me, views, but I just don't get it. But when did sessions become the root of all evil? What are they there for? I even like the idea of dynamically generating hidden values as an alternative or an optimization but surely session is a valid tool to use. Perhaps my understanding of data-mining is erroneous but I fail to see how storing data collected via a view (in the web tier) for a short time has anything to do with it. "Data mining is the process of discovering meaningful new correlations, patterns and trends by sifting through large amounts of data stored in repositories, using pattern recognition technologies as well as statistical and mathematical techniques." (Gartner Group). Another definition I found is "Data Mining follows an inductive strategy of analyzing data where users apply machine learning algorithms to gain non-obvious knowledge from the data." [http://www.jcp.org/en/jsr/detail?id=073] I'm not suggesting any such thing, I'm not forming any analysis on the data collected and stored in httpsession as that would be silly. Nor do i see that the proposed alternative as having anything to do with datamining. While I can see how a high traffic site need an alternative to httpsession the storing data collected from the view temporarily before its ready to be permanently stored (What i understand of what Andrew has been saying, and I think craig's recommendations). I cant see how the syllogism "all use of httpsession is bad" can be justified. Not on all fours but purring like a kitten :o) Mark On 16 Feb 2004, at 15:56, Michael McGrady wrote: > > >You [Mark Lowe] said: > >Perhaps HttpSession is a blunt instrument, and would need to be > substituted by another persistence >mechanism like say writing to a > temporary text file, but IMO this would be something that one >would > want to fix in the case that something were broken. > > Hi, Mark, > > Your reading "generating dynamic views" as somehow relating to > alternative forms of persistence is not correct. The idea is to get > AWAY from this PERSISTENCE solution and to start using view LOGIC. > > Michael > > >And you [Mark Lowe] said: > >i know its a naive position but I thought part of the scope of the > java language was in part an >attempt to abstract software development > from the hardware. > > Yes. But you are misreading completely what I said. I have no idea > how you got to here from what I said. I was doing the opposite, viz. > trying to get you to deal with an API for the logic of your views. > This has nothing remotely to do with persistent mechanisms or > hardware. I suspect we are two ships passing in the night here. > > > You [Mark Lowe] said: > >Okay agreed that generating hidden fields would be a reasonable means > of persistence. Yes I was >assuming, perhaps in error, that what was > being suggested was writing hidden fields. In fact I think >I may do > this. Also agreed that if the webforms dont have a load of in the jsp > then fine and dandy > > Generating hidden fields has nothing to do with a "means of > persistence". Rather, this is merely a way to generate hidden fields > relating to the logic of the view, e.g. if you come from one page, you > hidden fields will be one thing, but if you come from another page, > your hidden fields will be another thing. Your use of the session > object is not really a persistence mechanism, Mark. It is a shotgun > data mining technique for the view. The suggestion is to substitute a > scalpel data mining technique for the shotgun. > > We more on all fours now? > > Michael McGrady > > > > --------------------------------------------------------------------- > 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] ----------------------------------------- This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
