Re: REVIEW - Issue 26 - Tightly Coupled Renderer Dependencies

From: Adam Winer <>
Date: Thu, 05 Aug 2004 13:27:35 -0700

Roger Kitain wrote:

> Hey Adam -
> Now that I've got your attention... ;-)
> If you get a chance look at issue 26 in land (faces).
> We are trying to do away with this "hard coded" dependency between
> FormRenderer/CommandLinkRenderer - (essentially-find another way
> of accomplishing the same functionality but without having to
> use FormRenderer static method calls in CommandLinkRenderer.
> I thought of at least doing something like having the CommandLinkRenderer
> stuff some hidden field info into it's parent Form component attribute -
> so the FormRenderer could use it when rendering the hidden fields.
> What do you think?

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

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

-- Adam

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