There's another interesting case (probably related to this problem). I'll
keep it very simple.
1) component1
...
<t:ajaxformloop>
<t:component2/>
</t:ajaxformloop>
...
2) component2
...
<t:component3/>
...
void onMyEventFromComponent3 () {
// do something
}
3) component3
...
<t:submit t:id="submit" defer="false"/>
...
void onSelectedFromSubmit () {
componentResources.triggerEvent ( "myevent", null, null );
}
Expected: triggering submit triggers onMyEventFromComponent3 in parent.
Actual: onMyEventFromComponent3 is indeed triggered, but it happens with a
state related to the last iteration of the loop.
So probably there's something wrong with event propagation from child to
parent inside a loop? Any other ideas?
On Thu, May 22, 2014 at 9:07 AM, Ilya Obshadko <ilya.obsha...@gmail.com>
wrote:
> On Tue, May 20, 2014 at 11:09 PM, Thiago H de Paula Figueiredo <
> thiag...@gmail.com> wrote:
>
>> On Tue, 20 May 2014 14:45:48 -0300, Ilya Obshadko <
>> ilya.obsha...@gmail.com> wrote:
>>
>> Yes, this is it. I have a component which is looped over.
>>>
>>> class MyComponent {
>>> @Parameter
>>> private MyObject obj; // assigned inside a loop
>>>
>>> void onSelectedFromSubmitControl ( ... ) {
>>> }
>>> }
>>>
>>> 1) initially I tried to simply use MyObject instance passed as a
>>> parameter
>>> inside AjaxFormLoop;
>>>
>>
>> This won't work if you don't pass it as the context of Submit. Submit
>> passes to the event handler the context it receives, without any guessing.
>>
>> 2) then, I tried to pass this instance as context., getting the
>>> same results
>>>
>>
>> This will only work if you contribute a ValueEncoder for MyObject.
>>
>>
>> 3) finally, I tried to use obj.id as a context parameter instead -
>>> again,
>>> onSelectedFromSubmitControl was being called with context parameter
>>> belonging to the last iteration of the outside loop
>>>
>>
>> Outside loop? So there's nested loops?
>
>
> There's only one loop. By 'outside' I meant 'enclosing'.
>
> At this point I gave up and solved the problem otherwise, without having to
>>
>>> rely on t:submit context.
>>>
>>> I guess I understand your point, but t:submit does not encode context
>>> inside submission URL (unlike t:actionlink or t:eventlink). Probably
>>> that's
>>> the reason why my initial approach didn't work.
>>>
>>
>> If you're correct, and I haven't done any testing to know if you do, then
>> it's a bug. Have you tried, in a separate page, something similar but
>> simple enough to reproduce the problem?
>
>
> No, I didn't.
>
> In fact, when t:submit is being used inside a loop and IS NOT ENCLOSED BY
>>> OTHER COMPONENT, this scheme works.
>>>
>>
>> It shouldn't make any difference (not being enclosed by other component).
>> It may indicate an error in your part. It may be a bug in Submit. Looking
>> at the source (5.1, unfortunately I'm working on projects still using that
>> version), it seems to be a problem in Submit, but I won't be sure until I
>> run or see an example.
>
>
> The code I'm working on is not open source. I could create some private
> gists, if that works for you. Let me know.
>
>
>>
>> For example, in the same application I have constructs like:
>>>
>>> <t:ajaxformloop>
>>> <t:submit t:id="someId" p:context="loopContext"/>
>>> </t:ajaxformloop>
>>>
>>
>> I'm not sure the p: prefix is actually valid here. t: is the one usually
>> used for non-block parameters, while p: is used for block ones.
>
>
> Never had any problem with p: prefix actually.
>
>
> --
> Ilya Obshadko
>
>
--
Ilya Obshadko
