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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
