As Gary mentioned, you can use the MyFaces <t:saveState> component to carry bean values from one request to another. I'm new to Shale, but I saw something about a Dialog framework. Is that also supposed to address this issue?
- Brendan -----Original Message----- From: Gary VanMatre [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 14, 2006 10:00 AM To: Struts Users Mailing List Subject: Re: [shale] datatables request scope >From: Mark Lowe <[EMAIL PROTECTED]> > > Hello > > I've a general question on shale. > > Despite the jsf spec being churned out for a significant amount of > time, there seems to be no tidy means of maintaining request > attributes between requests to the server.. If i have a datatable and > want to add a row, indeed a can but i need to scope the backing bean > to session. > > I've found a few work arounds for this none of which I like. All the > advocates of jsf tell us its the future so on and so forth seem to > avoid the issue by just using session scope without a second thought. > Oracle have processScope which does the same sort of thing, but this > means you have to use one jsf implemenation to do this. > > Now struts (action, classic, original, vanilla, old trusty, whatever) > deals with this, as does adding request attributes in servlets and > then forwarding using the request dispatcher.. But JSF has no > provision for this, does shale have a solution to this? There are a number a ways that you can add a request parameter. If your navigation rule is not a redirect, they will be visible from the target page. context.getExternalContext().getRequestMap().put("someParam", "someValue") ValueBinding vb = context.getApplication().createValueBinding("#{requestScope.someParam}") ; vb.setValue(context, "someValue"); >I tried with > action listeners and such like, but never been quite able to pull it > off. The only work around involves session scoping and then cleaning > as soon as a new get request is made.. > > I've also seen something about a flash scope, that uses a tag lib, but > it smelled funny. > > I'm I being stupid (not the first time) ? Or its there still no tidy > way of dealing with this problem? > JSF still works with the same request/response architecture that other web frameworks use so state management has the same challenges. If you don't want to maintain state server side for fields that are display only, you need to save some key that you can use to retrive the state server side. Or, you can use the inputHidden component to save state as hidden attributes within the from. The commandLink component makes this an better option because it invokes a post verses a get. Another thing you might look at is the tomahawk "saveState" component (http://myfaces.apache.org/tomahawk/uiSaveState.html). It will cache a object in the component tree so that if you are using JSF client side state saving, the state of the object will be serialized as a hidden input field. You might also take a look at Seam (http://www.jboss.com/products/seam). > Mark > Gary > --------------------------------------------------------------------- > 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]
