Re: Review: Fix for Issue 63

From: Adam Winer <>
Date: Fri, 05 Nov 2004 10:56:24 -0800

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

Yes, certainly: it's just we have Renderers for things other than
UIForm that render out a <form> HTML tag! (A while back, in the JSF
1.0 EG, I asked for a marker interface for form components like
ValueHolder, etc., but we didn't have a rationale at that time.)

> 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.

No, not yet: at the current time, it must appear inside of
a <form> in the HTML markup, but what component/renderer
causes a <form> to appear is not a requirement.

> Every component that
> implements ActionSource or EditableValueHolder must reside in side of
> UIForm.

No, again.

> The spec says that UIForm and the formTag plays a big part in
> state saving.

Stating that UIForm and <h:form> play a big part in state
saving *is not* the same thing as saying that they are the
only component/renderer/tag that may play that part.

> If you had an ActionSource component outside of a form,
> the state management would entirely not work.

An HTML <form>, yes. But HTML <form> != UIForm, and codifying
that this must be so is a mistake.

> 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. 0

See above; mandating that there be a UIForm instance in the tree
is codifying something that won't necessarily make sense in
every markup language.

-- Adam

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