Comments intermixed...
Adam Winer wrote:
> Roger Kitain wrote:
[...]
>
>
> (Cc'ing the main dev list)
>
> I see a few categories of potential solutions:
>
> (1) Client-side Javascript solutions
> (2) Break the dependency
> (3) Keep the dependency, but make it a public API
> (4) Dynamically add HtmlInputHidden components.
>
> 1. Client-side Javascript solutions
> -----------------------------------
> Instead of trying to create <input type="hidden"> fields
> on the server, use DHTML to dynamically create DOM nodes
> for these fields as needed. This is tricky for a bunch
> of reasons (you'd want to rely on a helper script,
> for one - who's responsible for writing this script?)
> It's worth looking down this road later for other problems,
> but for now, let's forget about it.
agree.
>
>
> 2. Break the dependency:
> ------------------------
> Instead of relying on FormRenderer to output the hidden
> fields, each CommandLink would output its hidden field
> immediately, but only after checking that the hidden
> field hadn't already been rendered by a different
> CommandLink. Problems include:
> - How do you detect that you aren't in a different
> UIForm, and that the set of rendered hidden fields
> needs to be reset?
You'd have to do something funky like check to see if there are
any other hidden fields with the same name (in the tree, or maintain
a map in the parent UIForm component)... But once you start stuffing
stuff in UIForm - you have an "implied" dependency... (I guess, even
though UIForm doesn't have to do the rendering of the hidden fields)...
>
> - Even if you solve the "I'm in a different UIForm"
> case, you still have a dependency betwen
> CommandLinkRenderer and the Basic HTML RenderKit
> concept that "UIForms are what render HTML <form>s";
> this is a questionable assumption at best.
Yep.
>
> - The moment you add a *second* component that needs
> to output hidden fields dynamically, you're back
> in the same boat with inter-renderer dependencies.
>
> 3. Keep the dependency, but make it a public API
> ------------------------------------------------
> Expose a public contract: for example, assert that
> a java.util.Set of needed names is added at a certain
> key at request scope. This works, but has its own set of
> problems:
> - We can't do so until 1.2 at the earliest, since this
> is a spec change.
> - Will this approach generalize going forward? Do we need
> a more generic solution at the component level? For
> example, future support for client-side validation may
> add dependencies between <h:inputText> and <h:form>; what
> APIs would be needed to generalize that dependency?
>
>
> 4. Dynamically add HtmlInputHidden components
> ---------------------------------------------
> CommandLinkRenderer finds the UIForm and dynamically
> creates and adds HtmlInputHidden components as needed
> to render the needed hidden fields. Getting this
> approach to work with the current JSF/JSP integration
> seems hopeless.
>
> Category #2 is the closest I can see to a tractable
> approach to solving this issue in the 1.1 timeframe,
> but my gut feeling is that it should be punted on for
> 1.1 altogether.
Technically, I don't think any of these can be done in the 1.1
timeframe, because the current specification is not even
specific enough from the CommandLinkRenderer side of things.
>
> -- Adam
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>
-roger
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net