At 10:48 AM 2/16/2004, you wrote:
I've been looking a lot at JSF, and the way you can handle scoping issues is to actually store your controller in the session as a bean. Memory is only an issue if you cache data beyond the method scope:
An Action updates OrderController in the session with parameters from the request. The view then provides a set of getter's based on state of the bean in the session-- OrderController.getAllShipTos() that can be accessed via JSTL. If you are worried about memory consumption, then don't cache the shipto's in the OrderController, just fetch and return. This same idea can be applied to request scope data.
-Jacob
-----Original Message----- From: Michael McGrady [mailto:[EMAIL PROTECTED] Sent: Monday, February 16, 2004 11:54 AM To: Struts Users Mailing List Subject: RE: [OT] - Request against Session
I like the way you think, cf. infra, Mike Mainguy. No wonder you have the name you have. LOL. This is, I think, helpful. I still think, however, that you NEVER need to store the data from the view in session. That, for me, is an anathema. That is like going back to the single file data storage prior to SQL for me. Something like a hidden parameter version of SQL is what I would prefer. But, I do think that your division reflects a distinction that needs to be addressed.
Michael McGrady
At 08:05 AM 2/16/2004, you wrote: >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]
--------------------------------------------------------------------- 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]
