Ed Burns wrote:
>>>>>>On Thu, 04 Nov 2004 15:39:49 -0800, Adam Winer <adam.winer_at_oracle.com> 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: dev-unsubscribe_at_javaserverfaces.dev.java.net
For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net