You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Ilya Obshadko <il...@gmail.com> on 2014/05/20 15:05:11 UTC

event triggering inside form loop

I've encountered a problem with event triggering inside AjaxFormLoop.

Suppose the following scenario.

- external component

<t:form>
  <t:ajaxformloop>
    <t:mycomponent/>
  </t:ajaxformloop>
</t:form>

- internal component (MyComponent)

<t:formfragment>
   <t:submit t:id="submitControl" value=".."/>
   ...
</t:formfragment>

- in the code of MyComponent:

void onSelectedFromSubmitControl () {

}

Regardless of which submit is clicked, the event is triggered only on the
last component in the loop. I know that p:defer parameter is supposed to
handle this, but adding p:defer="false" doesn't help. Any ideas how to
handle this?


-- 
Ilya Obshadko

Re: event triggering inside form loop

Posted by 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

Re: event triggering inside form loop

Posted by Ilya Obshadko <il...@gmail.com>.
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 <il...@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

Re: event triggering inside form loop

Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Tue, 20 May 2014 14:45:48 -0300, Ilya Obshadko  
<il...@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?

> 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?

> 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.

> 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.

-- 
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br

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


Re: event triggering inside form loop

Posted by Dmitry Gusev <dm...@gmail.com>.
Hi,

I haven't used AjaxFormLoop, but with simple loop inside a form I use
SubmitNotifier, like this:

<t:form>

  <t:loop source="items" value="item">

    <t:submitnotifier t:id="main">

      <a t:type="linksubmit">Submit</a>

    </t:submitnotifier>

  </t:loop>

</t:form>


Then in your code declare:


public void onAfterSubmitFromMain() {

  //  work with current item here

}


Haven't tried with submit in nested component though, but I can imagine
AfterSubmit won't be triggered in nested component because of event
bubbling -- it bubbles up, not down. But I might be wrong here.


On Tue, May 20, 2014 at 9:45 PM, Ilya Obshadko <il...@gmail.com>wrote:

> On Tue, May 20, 2014 at 7:55 PM, Thiago H de Paula Figueiredo <
> thiagohp@gmail.com> wrote:
>
>  Well, that makes sense (as well as explains why providing variable
> >> instance in submit context doesn't help). Event is handled by an
> instance
> >> of the
> >> component with state corresponding to the last iteration of the loop.
> >>
> >
> > The point here is that you just cannot rely on a loop variable after
> > rendering or in event (including form submission) requests. So, in this
> > case, you need to pass it to the context of the Submit component so you
> can
> > set it again. Something like this, supposing the loop variable is an
> entity:
> >
> > <t:submit t:id="submitControl" value=".." t:context="loopVariable.id"/>
> >
> > void onSelectedFromSubmitControl(Long id) {
> >         loopVariable = findById(id); // retrive the original object from
> > the id
> >         ...
> > }
> >
> > Is this what you tried? If not, could you at least provide an overview of
> > that? Otherwise, I cannot help you further.
>
>
> 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;
> 2) then, I tried to pass this instance as t:submit context, getting the
> same results
> 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
>
> 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.
>
> In fact, when t:submit is being used inside a loop and IS NOT ENCLOSED BY
> OTHER COMPONENT, this scheme works. For example, in the same application I
> have constructs like:
>
> <t:ajaxformloop>
>   <t:submit t:id="someId" p:context="loopContext"/>
> </t:ajaxformloop>
>
> That works as expected (and just like you described it should work).
>
> But, if we replace it with
>
> <t:ajaxformloop>
>   <t:mycomponent/>
> </t:ajaxformloop>
>
> and t:submit is placed INSIDE t:mycomponent, we have a problem I've just
> described. I'm not sure if it's indeed a Tapestry bug or it's just not
> intended to work this way.
>
> --
> Ilya Obshadko
>



-- 
Dmitry Gusev

AnjLab Team
http://anjlab.com

Re: event triggering inside form loop

Posted by Ilya Obshadko <il...@gmail.com>.
On Tue, May 20, 2014 at 7:55 PM, Thiago H de Paula Figueiredo <
thiagohp@gmail.com> wrote:

 Well, that makes sense (as well as explains why providing variable
>> instance in submit context doesn't help). Event is handled by an instance
>> of the
>> component with state corresponding to the last iteration of the loop.
>>
>
> The point here is that you just cannot rely on a loop variable after
> rendering or in event (including form submission) requests. So, in this
> case, you need to pass it to the context of the Submit component so you can
> set it again. Something like this, supposing the loop variable is an entity:
>
> <t:submit t:id="submitControl" value=".." t:context="loopVariable.id"/>
>
> void onSelectedFromSubmitControl(Long id) {
>         loopVariable = findById(id); // retrive the original object from
> the id
>         ...
> }
>
> Is this what you tried? If not, could you at least provide an overview of
> that? Otherwise, I cannot help you further.


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;
2) then, I tried to pass this instance as t:submit context, getting the
same results
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

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.

In fact, when t:submit is being used inside a loop and IS NOT ENCLOSED BY
OTHER COMPONENT, this scheme works. For example, in the same application I
have constructs like:

<t:ajaxformloop>
  <t:submit t:id="someId" p:context="loopContext"/>
</t:ajaxformloop>

That works as expected (and just like you described it should work).

But, if we replace it with

<t:ajaxformloop>
  <t:mycomponent/>
</t:ajaxformloop>

and t:submit is placed INSIDE t:mycomponent, we have a problem I've just
described. I'm not sure if it's indeed a Tapestry bug or it's just not
intended to work this way.

-- 
Ilya Obshadko

Re: event triggering inside form loop

Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Tue, 20 May 2014 10:56:13 -0300, Ilya Obshadko  
<il...@gmail.com> wrote:

> It's too complex. The layout I provided in the first post resembles the
> basic idea: we have a component wrapped by the loop, and submit control  
> in each component.

I asked the template because your attempt may have gotten something wrong,  
and without it all we can do here is guess.

> Well, that makes sense (as well as explains why providing variable  
> instance in submit context doesn't help). Event is handled by an  
> instance of the
> component with state corresponding to the last iteration of the loop.

The point here is that you just cannot rely on a loop variable after  
rendering or in event (including form submission) requests. So, in this  
case, you need to pass it to the context of the Submit component so you  
can set it again. Something like this, supposing the loop variable is an  
entity:

<t:submit t:id="submitControl" value=".." t:context="loopVariable.id"/>

void onSelectedFromSubmitControl(Long id) {
	loopVariable = findById(id); // retrive the original object from the id
	...
}

Is this what you tried? If not, could you at least provide an overview of  
that? Otherwise, I cannot help you further.

-- 
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br

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


Re: event triggering inside form loop

Posted by Ilya Obshadko <il...@gmail.com>.
On Tue, May 20, 2014 at 5:35 PM, Thiago H de Paula Figueiredo <
thiagohp@gmail.com> wrote:

> On Tue, 20 May 2014 10:26:22 -0300, Ilya Obshadko <il...@gmail.com>
> wrote:
>
>  Already tried this. Context provided to onSelected handler contains value
>> from the last iteration as well, so obviously that doesn't help.
>>
>
> Please post the template of this attempt.


It's too complex. The layout I provided in the first post resembles the
basic idea: we have a component wrapped by the loop, and submit control in
each component.


> I'm not persisting loop variable in a way you mean it. I'll try to
>
>> formulate the problem different: if submit element was triggered inside a
>> component enclosed by a loop, is it supposed to be handled by the SAME
>> component that contained this submit element?
>>
>
> Yep, but because a *single* instance of your component is rendered
> multiple times. Many people have the wrong impression that when a component
> is placed inside a Loop, one instance of the component will be created for
> each rendering. This is not true.


Well, that makes sense (as well as explains why providing variable instance
in submit context doesn't help). Event is handled by an instance of the
component with state corresponding to the last iteration of the loop.

I don't have an idea how to solve this.

-- 
Ilya Obshadko

Re: event triggering inside form loop

Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Tue, 20 May 2014 10:26:22 -0300, Ilya Obshadko  
<il...@gmail.com> wrote:

> Already tried this. Context provided to onSelected handler contains value
> from the last iteration as well, so obviously that doesn't help.

Please post the template of this attempt.

> I'm not persisting loop variable in a way you mean it. I'll try to
> formulate the problem different: if submit element was triggered inside a
> component enclosed by a loop, is it supposed to be handled by the SAME
> component that contained this submit element?

Yep, but because a *single* instance of your component is rendered  
multiple times. Many people have the wrong impression that when a  
component is placed inside a Loop, one instance of the component will be  
created for each rendering. This is not true.

-- 
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br

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


Re: event triggering inside form loop

Posted by Ilya Obshadko <il...@gmail.com>.
Already tried this. Context provided to onSelected handler contains value
from the last iteration as well, so obviously that doesn't help.

I'm not persisting loop variable in a way you mean it. I'll try to
formulate the problem different: if submit element was triggered inside a
component enclosed by a loop, is it supposed to be handled by the SAME
component that contained this submit element?



On Tue, May 20, 2014 at 5:14 PM, Thiago H de Paula Figueiredo <
thiagohp@gmail.com> wrote:

> On Tue, 20 May 2014 10:05:11 -0300, Ilya Obshadko <il...@gmail.com>
> wrote:
>
>  Regardless of which submit is clicked, the event is triggered only on the
>> last component in the loop. I know that p:defer parameter is supposed to
>> handle this, but adding p:defer="false" doesn't help. Any ideas how to
>> handle this?
>>
>
> Try using the context parameter of the Submit component so you can pass
> some value so your event handler method knows which object to work on.
> Remember: the event is a different request from the one that renders HTML,
> so everything which isn't persisted (and you should avoid this) is lost.
> Using the context parameter is storing the information in an URL inside the
> generated HTML. You're probably persisting the loop variable, otherwise
> you'd just get an NPE when accessing it.
>
> The defer parameter doesn't do what you think it does and wouldn't fix the
> cause of your issue, which is not providing the context for your Submit
> component.
>
> --
> Thiago H. de Paula Figueiredo
> Tapestry, Java and Hibernate consultant and developer
> http://machina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>


-- 
Ilya Obshadko

Re: event triggering inside form loop

Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Tue, 20 May 2014 10:05:11 -0300, Ilya Obshadko  
<il...@gmail.com> wrote:

> Regardless of which submit is clicked, the event is triggered only on the
> last component in the loop. I know that p:defer parameter is supposed to
> handle this, but adding p:defer="false" doesn't help. Any ideas how to
> handle this?

Try using the context parameter of the Submit component so you can pass  
some value so your event handler method knows which object to work on.  
Remember: the event is a different request from the one that renders HTML,  
so everything which isn't persisted (and you should avoid this) is lost.  
Using the context parameter is storing the information in an URL inside  
the generated HTML. You're probably persisting the loop variable,  
otherwise you'd just get an NPE when accessing it.

The defer parameter doesn't do what you think it does and wouldn't fix the  
cause of your issue, which is not providing the context for your Submit  
component.

-- 
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br

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


Re: event triggering inside form loop

Posted by Geoff Callender <ge...@gmail.com>.
Very good.

On 22 May 2014, at 3:00 pm, Ilya Obshadko <il...@gmail.com> wrote:

> On Wed, May 21, 2014 at 5:51 AM, Geoff Callender <
> geoff.callender.jumpstart@gmail.com> wrote:
> 
> I'm confused about the aim here. There's one form, yet there's one submit
>> per row. If you make changes to rows 1, 2, and 3, then click submit on row
>> 2, what do you expect to happen in the DB and client-side? Should rows 1
>> and 3 be persisted to the DB? Should rows 1 and 3 be reset, or perhaps
>> refreshed, client-side?
>> 
> 
> Well, not exactly. Form is a "wizard" style and I'm iterating over
> session-persisted collection.
> Each collection item is represented by set of form fields. Suppose you
> would like to 'reset' a specific collection item to its default state.
> I was trying to achieve that using t:submit element inside a component
> which represents a 'view' of collection item.
> 
> When the above method didn't work, I just moved my logic to client-side,
> resetting fields using JS and then submitting the form.
> That gave me the result I needed.
> 
> 
>> Might it be better to use Loop instead of AjaxFormLoop and do one AJAX
>> Form per row?
>> 
>> 
>> http://jumpstart.doublenegative.com.au/jumpstart/examples/ajax/formsinaloop
>> 
>> Geoff
>> 
>> On 20 May 2014, at 11:05 pm, Ilya Obshadko <il...@gmail.com>
>> wrote:
>> 
>>> I've encountered a problem with event triggering inside AjaxFormLoop.
>>> 
>>> Suppose the following scenario.
>>> 
>>> - external component
>>> 
>>> <t:form>
>>> <t:ajaxformloop>
>>>   <t:mycomponent/>
>>> </t:ajaxformloop>
>>> </t:form>
>>> 
>>> - internal component (MyComponent)
>>> 
>>> <t:formfragment>
>>>  <t:submit t:id="submitControl" value=".."/>
>>>  ...
>>> </t:formfragment>
>>> 
>>> - in the code of MyComponent:
>>> 
>>> void onSelectedFromSubmitControl () {
>>> 
>>> }
>>> 
>>> Regardless of which submit is clicked, the event is triggered only on the
>>> last component in the loop. I know that p:defer parameter is supposed to
>>> handle this, but adding p:defer="false" doesn't help. Any ideas how to
>>> handle this?
>>> 
>>> 
>>> --
>>> Ilya Obshadko
>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>> 
>> 
> 
> 
> -- 
> Ilya Obshadko


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


Re: event triggering inside form loop

Posted by Ilya Obshadko <il...@gmail.com>.
On Wed, May 21, 2014 at 5:51 AM, Geoff Callender <
geoff.callender.jumpstart@gmail.com> wrote:

I'm confused about the aim here. There's one form, yet there's one submit
> per row. If you make changes to rows 1, 2, and 3, then click submit on row
> 2, what do you expect to happen in the DB and client-side? Should rows 1
> and 3 be persisted to the DB? Should rows 1 and 3 be reset, or perhaps
> refreshed, client-side?
>

Well, not exactly. Form is a "wizard" style and I'm iterating over
session-persisted collection.
Each collection item is represented by set of form fields. Suppose you
would like to 'reset' a specific collection item to its default state.
I was trying to achieve that using t:submit element inside a component
which represents a 'view' of collection item.

When the above method didn't work, I just moved my logic to client-side,
resetting fields using JS and then submitting the form.
That gave me the result I needed.


> Might it be better to use Loop instead of AjaxFormLoop and do one AJAX
> Form per row?
>
>
> http://jumpstart.doublenegative.com.au/jumpstart/examples/ajax/formsinaloop
>
> Geoff
>
> On 20 May 2014, at 11:05 pm, Ilya Obshadko <il...@gmail.com>
> wrote:
>
> > I've encountered a problem with event triggering inside AjaxFormLoop.
> >
> > Suppose the following scenario.
> >
> > - external component
> >
> > <t:form>
> >  <t:ajaxformloop>
> >    <t:mycomponent/>
> >  </t:ajaxformloop>
> > </t:form>
> >
> > - internal component (MyComponent)
> >
> > <t:formfragment>
> >   <t:submit t:id="submitControl" value=".."/>
> >   ...
> > </t:formfragment>
> >
> > - in the code of MyComponent:
> >
> > void onSelectedFromSubmitControl () {
> >
> > }
> >
> > Regardless of which submit is clicked, the event is triggered only on the
> > last component in the loop. I know that p:defer parameter is supposed to
> > handle this, but adding p:defer="false" doesn't help. Any ideas how to
> > handle this?
> >
> >
> > --
> > Ilya Obshadko
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>


-- 
Ilya Obshadko

Re: event triggering inside form loop

Posted by Geoff Callender <ge...@gmail.com>.
I'm confused about the aim here. There's one form, yet there's one submit per row. If you make changes to rows 1, 2, and 3, then click submit on row 2, what do you expect to happen in the DB and client-side? Should rows 1 and 3 be persisted to the DB? Should rows 1 and 3 be reset, or perhaps refreshed, client-side?

Might it be better to use Loop instead of AjaxFormLoop and do one AJAX Form per row?

	http://jumpstart.doublenegative.com.au/jumpstart/examples/ajax/formsinaloop

Geoff

On 20 May 2014, at 11:05 pm, Ilya Obshadko <il...@gmail.com> wrote:

> I've encountered a problem with event triggering inside AjaxFormLoop.
> 
> Suppose the following scenario.
> 
> - external component
> 
> <t:form>
>  <t:ajaxformloop>
>    <t:mycomponent/>
>  </t:ajaxformloop>
> </t:form>
> 
> - internal component (MyComponent)
> 
> <t:formfragment>
>   <t:submit t:id="submitControl" value=".."/>
>   ...
> </t:formfragment>
> 
> - in the code of MyComponent:
> 
> void onSelectedFromSubmitControl () {
> 
> }
> 
> Regardless of which submit is clicked, the event is triggered only on the
> last component in the loop. I know that p:defer parameter is supposed to
> handle this, but adding p:defer="false" doesn't help. Any ideas how to
> handle this?
> 
> 
> -- 
> Ilya Obshadko


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