On 2/14/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > On 2/14/06, CONNER, BRENDAN (SBCSI) <[EMAIL PROTECTED]> wrote: > > > > Isn't that functionally what the MyFaces <t:saveState> component does? > > > Yes, but <t:saveState> requires that you get the page author involved. From > an architectural viewpoint, I don't think that's necessarily the right > answer (in many cases) where the state being saved and restored is server > side model state as opposed to view state.
I agree with this.. This problem isn't something I'm trying to solve in a real world project, I'm just doing my 6 monthly JSF tryout and seeing if anything has substantially changed. I'm using the 1.2 stuff from glassfish. So I'm looking at all this in a "ideal" context not pragmatic... t:saveState in jsp's I can see is pragmatic, but confusing for someone coming in fresh. I'd hate having to explain to someone why and when to use t:saveState, while trying to sell jsf as a good solution I'd tehn be explaining all the stuff it doesn't do.. Explain why servlets/jsp's using forwards do, as does struts.. And still explain why JSF is considered progress. Burn's blog was talking about the flash scope as a tag lib also, more clutter in jsps. I think the concept of processScope alla ADF is better than scoping varibles in el.. You'd want to configure the bean as being managed in a particular scope, but then this begs the question why such a scope couldn't be request? and request attributes could be cleaned when a navigation rule is set to redirect. So far I've been using a filter to clean the session when i new get request is made. Not perfect, but nothing in the JSPs. But this is also confusing as the user sees a session scoped bean, but the bean is not in the session as soon as a new request is made. Mark > > - Brendan > > > Craig > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig > > McClanahan > > Sent: Tuesday, February 14, 2006 3:26 PM > > To: Struts Users Mailing List > > Subject: Re: [shale] datatables request scope > > > > [snip] > > > > One idea I've seen discussed, but haven't seen actually implemented yet, > > would be a JSF-specific implementation of the "flash" concept in RoR, > > where > > it keeps state information around for exactly *one* more request for > > you. > > It should be easy to do this with a specialized variable resolver or > > something ... I'll think about how to do that when dialogs are heavier > > weight than you really need. Something along the lines of this in the > > second page: > > > > <h:outputText value="#{flash.savedCustomerName}"/> > > > > where "savedCustomerName" was stored away (until the next request) by > > some > > TBD mechanism. > > > > Craig > > > > --------------------------------------------------------------------- > > 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]
