dev@javaserverfaces.java.net

Re: Review: Fix for Issue 63

From: Adam Winer <adam.winer_at_oracle.com>
Date: Fri, 05 Nov 2004 11:18:44 -0800

Ed Burns wrote:
>>>>>>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.

See my other reply: I can comfortably assert that it does,
since we already do so. The issue is that <form> != UIForm;
within the scope of the components and renderers of the spec,
it does of course, but that requirement does not affect
non-spec renderers and components.

-- Adam

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net