My hunch is that much of this hellishness is connected
to how components cache clientIds when iterating through
the table.
UIComponentBase (at least in the RI) has a weird rule
where it'll cache the clientId until someone calls setId(),
so UIData and UIXIterator/UIXTable have to hack by
calling component.setId(component.getId()) to force the
client ID to be recomputed.
Meanwhile, UIXComponentBase doesn't cache client IDs
at all, but consistently recomputes them. (This hasn't
shown up as a performance hit when I've profiled, but
might someday).
I suspect that what's happened here is one component
or another failing to discard its cached clientId - perhaps
ui:repeat in this case?
-- Adam
On 6/20/07, Renzo Tomaselli <[EMAIL PROTECTED]> wrote:
This seems working well ! Indeed the problem - whatever it was - was
located into the ui:repeat id. This component is a NamingContainer, and
its id should depend on current row key - when used in a table - but
this does not occur, the id is fixed and bound to the very first row.
Exactly as it did for h:commandLink.
Ok, I learned about tr:iterator today, never met before. Now commandLink
id are generated properly.
This game is complex enough concerning ui:repeat vs. c:forEach, I didn't
miss a further iterator :'( .
The overall table layout is conditioned by a few rules:
- tr:table accepts just tr:columns components, so I *must* use c:forEach
(which is not a component) for providing dynamic columns. My only
chance, but it works well.
- columns can be either text, icons or toolbars. Choice is driven by
c:if. Toolbar composition is dynamic as well. I cannot use c:forEach
again since this tag is evaluated at compile-time, while rows are
provided at rendering-time. So ui:repeat was again the only choice left
around.
Anyway it works, many thanks.
-- Renzo
Adam Winer wrote:
> Wow, ui:repeat in c:forEach in tr:table. You are a glutton
> for punishment!
>
> What happens in that example if you swap in tr:iterator
> for ui:repeat?
>
> -- Adam
>
>
> On 6/20/07, Renzo Tomaselli <[EMAIL PROTECTED]> wrote:
>> Using tr:commandLink in the previous example seems ok, since proper row
>> keys are used. Don't know why h:commandLink does not work.
>> However my original example is a bit more complex as a command cell
>> contains a toolbar, and column set is iterated over by Facelets
>> c:forEach:
>>
>> <tr:table id="result" var="row" ...
>> <c:forEach var="column" items="#{bean.columnHeaders}"
>> varStatus="iteration">
>> <tr:column>
>> .....
>> <h:panelGrid>
>> <ui:repeat var="spot"
>> value="#{cx:getToolbar(row, iteration.index)}">
>> <tr:commandLink immediate="true"
>> action="#{spot.execute}" disabled="#{spot.disabled}">
>> <h:graphicImage
>> value="#{spot.icon}" style="border: 0px" title="#{spot.tooltip}"/>
>> </tr:commandLink>
>> </ui:repeat>
>> </h:panelGrid>
>>
>> This does not work. CommandLink id of the first row is repeated for all
>> rows, while ui:repeat is ok in the sense that it appends an index to
>> every id.
>> Btw, I was wrong in my previous msg: a progressive id should appear just
>> because it's the way I generate row keys as returned by getRowKey.
>> It's just that the first row key is repeated.
>> I feel I will spend a debugging evening ...
>>
>> -- Renzo
>>
>> Adam Winer wrote:
>> > Question: does this happen if you use tr:commandLink?
>> > h:commandLink certainly should work, just trying to
>> > reduce the set of possibilities.
>> >
>> > -- Adam
>> >
>> >
>> >
>> > On 6/20/07, Renzo Tomaselli <[EMAIL PROTECTED]> wrote:
>> >> Hi, while using a command link in a tr:table cell, the action method
>> >> gets multiple events upon icon click, actually as many events as
>> >> rendered rows.
>> >> Coding is something like:
>> >>
>> >> <tr:table id="result" var="row" ...
>> >> <tr:column>
>> >> <h:commandLink immediate="true"
>> >> action="#{row.execute}">
>> >> <h:graphicImage
>> >> value="#{sessionBean.map['trash']}" style="border: 0px"/>
>> >> </h:commandLink>
>> >>
>> >> From rendered page, I noticed that all links are rendered as:
>> >>
>> >> <a class="OraLink" href="#"
>> >>
>>
onclick="submitForm('browser',0,{source:'splitty:tabby:result:d6:0:_id159'});return
>>
>> >>
>> >> false;">
>> >> <img style="border: 0px none ;"
>> >> src="/AxxBrowser/skins/skin1/images/trash.gif"/>
>> >> </a>
>> >>
>> >> while (I guess) it should be 0:_id159, 1:_id159, 2:_id159 ...
>> >> I guess from debugging that event generation occurs once per row
>> since
>> >> component id is repeating, thus event source matches multiple times
>> >> (from CommandLinkRenderer.java).
>> >>
>> >> -- Renzo
>> >>
>> >>
>> >
>> >
>>
>
>
