How to apply TriggerFragment-Mixin inside a Loop?

[Christian Riedel <ch...@gmx.net>]

Hi list,

I just ran into a problem while trying to use the TriggerFragment Mixin 
inside a Loop-component...

The loop should iterate over some list of elements and for each element 
there should be a radio button, which should make one formFragment 
visible. In the end there is one single radio-button that is also part 
of the same radio-group but not inside the loop. It should make a second 
formFragment visible while the first one should be invisible then.

The whole thing looks similar to this:

<t:radiogroup value="cardId">
<t:loop source="cards" value="c" volatile="true">
<div class="field card">
<t:radio t:id="card" value="c.id" t:mixins="triggerfragment" 
fragment="firstForm"/>
</div>
</t:loop>
<div class="field newCard">
<t:radio t:id="newCard" t:mixins="triggerfragment" fragment="secondForm" 
value="-1"/>
</div>
</t:radiogroup>

<t:formfragment t:id="firstForm"> ... </t:formfragment>
<t:formfragment t:id="secondForm"> ... </t:formfragment>


The produced Javascript does not map the clientId of the radio-buttons 
with ids 'card', 'card_1', etc. with 'firstForm' but it does map 
'newCard' with 'secondForm' as you can see here in the produced script code:


Tapestry.init({"linkTriggerToFormFragment":[["card",null],["card_0",null],["card_1",null],["card_2",null],["card_3",null],["card_4",null],["card_5",null],["card_6",null],["card_7",null],["newCard","secondForm"]],"formFragment":["firstForm","secondForm"] 
...


Then I had a look at the code of TriggerFragment and Loop and it seems 
they are not compatible. TriggerFragment defers a heartbeat command that 
would read out the formFragment's clientId as soon as the heartbeat 
ends. If you use the TriggerFragment-Mixin in a form only, the form 
calls heartbeat.end() after it rendered all its children.
The Loop-component calls heartbeat.end() each time an iteration was 
finished, which means the formFragment's clientId is being read before 
it even exists.

As far as I can tell, it isn't possible unless we patch Loop or Hearbeat 
to defer the command execution a little more or write a TriggerFragment 
patch where one can pass the clientId directly.
Is there a better existing solution for this problem?

Thanks so far ;)
Christian


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org