I'll call this a naïve post, but what are the benefits to client-side? I've seen several times that it is 'highly recommended', but I can't say I know why. Also, we do have some security constraints, does the state-saving method matter for those kind of concerns?
Thanks for all the help so far! Nate Perkins 480-441-3667 [EMAIL PROTECTED] >This email message is for the sole use of the intended recipient(s) and may >contain GDC4S > confidential or privileged information. Any unauthorized review, use, > disclosure or distribution > is prohibited. If you are not an intended recipient, please contact the > sender by reply email and > destroy all copies of the original message. > -----Original Message----- From: Adam Winer [mailto:[EMAIL PROTECTED] Sent: Thursday, June 07, 2007 8:26 AM To: MyFaces Discussion Subject: Re: ADF Dialog causes refresh code to no longer work On 6/7/07, Perkins, Nate-P63196 <[EMAIL PROTECTED]> wrote: > Thanks Adam, > > That would be a general solution, I suppose I had thought of that but > was nervous of the overhead of traversing the entire component tree, is > that not something I should worry about? Don't worry about it. It's virtually no work compared to everything else that goes on. > We are using server-side state saving which might explain why that call > is needed for that code to work. If you're using Trinidad (or ADF Faces), I strongly recommend switching to client-side state saving. There's virtually no benefits to fully server-side state saving. -- Adam > > > Nate Perkins > 480-441-3667 > [EMAIL PROTECTED] > > >This email message is for the sole use of the intended recipient(s) and > may contain GDC4S > > confidential or privileged information. Any unauthorized review, use, > disclosure or distribution > > is prohibited. If you are not an intended recipient, please contact > the sender by reply email and > > destroy all copies of the original message. > > > > -----Original Message----- > From: Adam Winer [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 06, 2007 8:34 PM > To: MyFaces Discussion > Subject: Re: ADF Dialog causes refresh code to no longer work > > If I were going to disable and reset a large number of > components, I'd probably do so by walking the entire > UIComponent tree from the UIViewRoot, performing "instanceof > UIXEditableValue" and calling setDisabled(true) and resetValue() on > each instance. If you needed to restrict it to a subtree, you > could use one "binding" and walk down from that parent; > if you needed something more tailored, I'd consider adding > f:attribute to tag the ones that need to be reset. > > The code you've written scares me a bit - I've > no idea why the StateManager call should affect > anything, unless perhaps if you're using server-side > state saving? > > -- Adam > > > On 6/6/07, Perkins, Nate-P63196 <[EMAIL PROTECTED]> wrote: > > I have a page with a table of selectable objects. > > > > When an object is selected its inputs appear below the table (a > binding > > on 'rendered' of a panelHeader) > > > > The inputs have a save and a cancel button, cancel is > partialSubmit=true > > and immediate=true with all inputs having partialTriggers on both > > buttons. > > > > When I press Cancel, the inputs are supposed to disable and go into > > read-only mode. This took me a long time to get working properly, the > > issue being that the components would disable but the old values would > > still be there. (I wanted the values to reset) > > (I realize that this can be done by binding the input components and > > resetting, but I wanted/needed to find a general solution not a > > component-by-component solution) > > I found the following code which worked when put into my cancel action > > method: > > (I had seen code like this recommended before but without the last > > statement, this code does nothing useful unless the save to the > > StateManager is done) > > > > <code> > > FacesContext fc = FacesContext.getCurrentInstance(); > > UIViewRoot viewRoot = > > fc.getApplication().getViewHandler().createView(fc, > > fc.getViewRoot().getViewId()); > > fc.setViewRoot(viewRoot); > > fc.getApplication().getStateManager().saveSerializedView(fc); > > </code> > > > > Recently I was given a new requirement to have a popup confimation > > dialog on the cancel button. I launch an ADF dialog from the cancel > > button's action method and moved the code that used to be in the > action > > method into the returnListener. The problem is that now the above code > > no longer works. It seems to return to the main page in an > inconsistent > > state. (I click once, nothing happens, I click again and it reloads > the > > cancel dialog, I can't get out of the Edit mode.) > > > > I was able to return to a partially-working state by removing the > above > > code from the returnListener and replacing it with a partialTarget > call > > on the surrounding form, but again this only disables the components > it > > does not reset them. > > > > I am using Oracle ADF not Trinidad, but I am very interested in > > switching and am asking the MyFaces team if (a) they know of why the > > above code works in an action method but not in a returnListener, (b) > if > > this is a bug in the Oracle ADF dialog framework that has been fixed > in > > Trinidad (a compelling reason, among many, to switch), (c) is there > > another way to disable and reset the components without having to do > it > > on a component-by-component basis? > > > > Nate Perkins > > [EMAIL PROTECTED] > > >
