>>>>> On Fri, 5 Nov 2004 10:21:24 -0800, Ed Burns <ed.burns_at_sun.com> 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.
Ed
--
| ed.burns_at_sun.com | {home: 407 294 2468, office: 408 884 9519 OR x31640}
| homepage: | http://javaweb.sfbay.sun.com/~edburns/
| aim: edburns0sunw | iim: ed.burns_at_sun.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net