Re: event triggering inside form loop

[Ilya Obshadko <il...@gmail.com>]

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 <il...@gmail.com>
wrote:

> On Tue, May 20, 2014 at 11:09 PM, Thiago H de Paula Figueiredo <
> thiagohp@gmail.com> wrote:
>
>> On Tue, 20 May 2014 14:45:48 -0300, Ilya Obshadko <
>> ilya.obshadko@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