atom feed13 messages in net.java.dev.javaserverfaces.devRe: REVIEW - Issue 26 - Tightly Coupl...
FromSent OnAttachments
Roger KitainAug 2, 2004 5:41 am 
Craig R. McClanahanAug 2, 2004 9:46 am 
Roger KitainAug 2, 2004 11:42 am 
Craig R. McClanahanAug 2, 2004 12:05 pm 
Roger KitainAug 2, 2004 3:05 pm 
Craig R. McClanahanAug 2, 2004 3:10 pm 
Roger KitainAug 2, 2004 3:26 pm 
Craig R. McClanahanAug 2, 2004 3:57 pm 
Roger KitainAug 3, 2004 5:15 am 
Roger KitainAug 4, 2004 7:11 am 
Adam WinerAug 4, 2004 9:16 am 
Adam WinerAug 5, 2004 1:27 pm 
Roger KitainAug 6, 2004 4:08 am 
Subject:Re: REVIEW - Issue 26 - Tightly Coupled Renderer Dependencies
From:Adam Winer (adam@oracle.com)
Date:Aug 5, 2004 1:27:13 pm
List:net.java.dev.javaserverfaces.dev

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