Roger Kitain wrote:
> Hey Adam -
>
> Now that I've got your attention... ;-)
> If you get a chance look at issue 26 in java.net 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
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.
-- Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net