Reconsidering it: probably the best solution would be to enable all components right before submission; as Heath has pointed out.
Still - in the current state of affairs: if the component was disabled on the jsf-side, and no value is posted back for this component, we should probably not assume that the value has changed to be empty. regards, Martin On Sun, 23 Jan 2005 10:55:38 +0100, Martin Marinschek <[EMAIL PROTECTED]> wrote: > Interesting comment! > > yes, if you do exactly that, the browser will not post the changed > value; and MyFaces will of course not be able to use it. > > What a tricky problem... > > Well, there will be some more work necessary to resolve this ;) > > regards, > > Martin > > On Sat, 22 Jan 2005 17:17:05 -0600, Heath Borders > <[EMAIL PROTECTED]> wrote: > > I think this might just be a MyFaces addition. > > > > The problem is that if client-side javascript is used, the control > > could be enabled, changed, and then re-disabled, and JSF would have no > > idea. > > Of course, the only way to detect this sort of thing is either with > > hidden inputs, or some client-side javascript to enable all controls > > before submission. > > > > On Sat, 22 Jan 2005 14:06:27 -0500, Sean Schofield > > <[EMAIL PROTECTED]> wrote: > > > > yes, there is a section in the code which checks that if a component > > > > is disabled, the value will not be reset... it is in the decodexx > > > > method in the RendererUtils or HtmlRendererUtils; don't ask me which > > > > one of these two, though ;) > > > > > > Is that because the spec requires it or is that a MyFaces addition? > > > If its because of the spec, then add it to the list of nice little > > > improvements in JSF over Struts. :-) > > > > > > > Martin > > > > > > sean > > > > > > > > > -- > > -Heath Borders-Wing > > [EMAIL PROTECTED] > > >
