Re: Review: Fix for Issue 63

From: Ed Burns <Ed.Burns_at_Sun.COM>
Date: Fri, 05 Nov 2004 10:21:24 -0800

>>>>> On Thu, 04 Nov 2004 15:39:49 -0800, Adam Winer <> said:

AW> One immediate issue is that the onclick code you add can't
AW> just be appended to the user's, because a user might
AW> write:

AW> onclick="return runConfirmDialog();"

AW> ... where runConfirmDialog() returns true or false. This would
AW> turn into generated output like:

AW> onclick="return runConfirmDialog(); clearHiddenParams_helloForm();"

AW> ... and clearHiddenParams_helloForm() would never get invoked.

AW> Another issue added here is that commandButton now only works
AW> inside of a UIForm. While it certainly is true that commandButton
AW> can only work inside of an HTML <form>, this is adding a requirement
AW> that the only component allowed to generate HTML <form>s are UIForm
AW> components. This is, in fact, not the case - in ADF Faces, we
AW> have a non-UIForm form component.

How does this handle state management? Does pressing such a button
cause a faces form submit?

AW> You might be able to do some
AW> Javascript work to go back from the <input type="submit">
AW> (which is "this" in Javascript) to the <form> element.

commandButton must reside inside of a h:form. Every component that
implements ActionSource or EditableValueHolder must reside in side of
UIForm. The spec says that UIForm and the formTag plays a big part in
state saving. If you had an ActionSource component outside of a form,
the state management would entirely not work. Therefore, I'm going to
go to the EG to recommend that we add to the spec that every component
that implements ActionSource or EditableValueHolder must reside inside
of a UIForm. This is how people already think, and I don't see much
downside, since putting an ActionSource or EditableValueHolder component
outside of a UIForm would'nt work in the current spec.


To unsubscribe, e-mail:
For additional commands, e-mail: