Re: Review: Fix for Issue 63

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

>>>>> On Fri, 5 Nov 2004 10:21:24 -0800, Ed Burns <> said:

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.

EB> How does this handle state management? Does pressing such a button
EB> 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.

EB> Therefore, I'm going to go to the EG to recommend that we add to the
EB> spec that every component that implements ActionSource or
EB> EditableValueHolder must reside inside of a UIForm. This is how
EB> people already think, and I don't see much downside, since putting
EB> an ActionSource or EditableValueHolder component outside of a UIForm
EB> wouldn't work in the current spec.

That said, Adam, if you feel strongly about this, we can take it as a
feature request and work on it. But I do assert that the current
architecture doesn't allow for ActionSource or EditableValueHolder to
live outside the scope of a UIForm ancestor.


|  | {home: 407 294 2468, office: 408 884 9519 OR x31640}
| homepage:         |
| aim: edburns0sunw | iim:
To unsubscribe, e-mail:
For additional commands, e-mail: