I agree that having a scope that is somewhere between "request" and "session" would be nice, if that's what you're suggesting. Both Struts and JSF have to deal with that Servlet limitation, it seems.
JSF is very much here and in production. - Brendan -----Original Message----- From: Mark Lowe [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 15, 2006 3:57 PM To: Struts Users Mailing List Subject: Re: [shale] datatables request scope On 2/15/06, CONNER, BRENDAN (SBCSI) <[EMAIL PROTECTED]> wrote: > Hmm. I must be coming from a different perspective. None of the > developers I've worked with in the past 18 months ever wants to go back > to Struts after having switched to JSF, so it must mean "progress" in > one form or another. > > Perhaps, though, this disconnect is because I've just started monitoring > a Struts mailing list after having dealt almost exclusively with the > MyFaces mailing list the past year or so. ;-) I can only talk from my experience, but I've been waiting for JSF to happen for ever. I don't really mind about components that make you cups of tea and stuff, just the basic tag library will do. Everytime I come back to JSF on each version, this issue has never been addressed. I know that various implementaions provide their solutions. All of which seem okay, but this request attribute business seems something the spec should address. This is no means a comment on myfaces, from what i see, if you take myfaces as a framework, like struts then it provides all the toys and more. But the JSF 1.2 spec is making it to into the JEE stuff, and its not been exactly rushed out has it (JCP should perhaps be renamed java constipated process for certain cases). Now a navigation rule has the option to specify redirect, if assume the idea is to clear the request attributes or not clear the request attributes.. But this makes no difference with datatables, there just seems something very wrong about that. Oh well I guess see what happens.. Mark > > - Brendan > > -----Original Message----- > From: Mark Lowe [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 15, 2006 3:47 AM > To: Struts Users Mailing List > Subject: Re: [shale] datatables request scope > > > 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 > > --------------------------------------------------------------------- > 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]
