Some big differences are support for server-side failover, multiple simultaneous pages, and the back button.
Security is handled by only sending a token to the client; all the real data is on the server. (There is an "all" mode that sends all state to the client, but that exposes the security issues you talk about unless you encrypt the content.) FWIW, as of JSF 1.2, server side state saving now functions much like Trinidad's client-side state saving, sending a token to the client. -- Adam On 6/7/07, Perkins, Nate-P63196 <[EMAIL PROTECTED]> wrote:
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] > > >
