Dan Labrecque wrote:
> Dan Labrecque wrote:
>> Venkatesh Babu wrote:
>>> Hi Janir,
>>>
>>> I am actually seeing this problem with other complex components
>>> too.. I tried the add-remove component inside the
>>> table for example inside the table. Only the last row of the table
>>> showed the add/remove/add-all/remove-all buttons
>>> for the add remove component. The rest of the add remove components
>>> did not show them.
>>>
>>> For the calendar, the "calendarMonth" component and for the
>>> add-remove the "add/remove/add-all/remove-all" buttons
>>> are actually included as facets for their "parent" components. So,
>>> when the calendar/add remove is being rendered
>>> for the multiple table columns, the facets are getting cached for
>>> subsequent rendering of the calendar/add remove components.
>>>
>>> The calendar component uses the "calendarMonth" component in the
>>> "datePicker" facet for rendering the imagehyperlink.
>>> For the first time when the calendar is rendered, the "datePicker"
>>> facet is null and a new calendarMonth component is created.
>>> But, when a calendar is being rendered subsequently and a check for
>>> null facet for "datePicker" facet is being done,
>>> the check returns false and the previously used calendarMonth
>>> component for the "datePicker" facet is being used.
>>>
>>> The same thing is happening for add-remove. The buttons which exist
>>> as facets for the add-remove continue to exist for subsequent
>>> rendering for add-remove and hence only one set of buttons get
>>> rendered for the whole column set of add remove component.
>>>
>>> I suspect the TableColumn component is not clearing the component's
>>> values properly while rendering it.
>>
>> I don't believe TableColumn was ever responsible for "clearing
>> component's values". Although, there was a rendering method that was
>> recently removed from RenderingUtilities -- I believe this cleared
>> component ids each time a component was rendered.
>
> Venky, the following RenderingUtilities code may be responsible for
> this issue -- it was removed for the 4.1 release. Apparently, the
> caching issue was not fixed in JSF 1.2 after all. Try adding this code
> back in and see if Calendar renders.
>
> public static void renderComponent(UIComponent component,
> FacesContext context) throws IOException {
> if (!component.isRendered()) {
> return;
> }
>
> // this is a workaround a jsf bug in tables where it caches the
> // client id. We are forcing the caching not to happen.
> // this could be a potential source of performance issues if
> // it turns out the jsf folks really wanted this
>
> String id = component.getId();
> if (id != null) {
> component.setId(id);
> }
> ...
>
> Dan
>
I noticed this message and am curious about the issue. Do you have a CR
or Issue number?
Looking voer the code, I do see we reset the ID of the component to
clear the client ID cache in
UIData.restoreDecendentState().