[
https://issues.apache.org/jira/browse/TAPESTRY-2360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adriaan Joubert updated TAPESTRY-2360:
--------------------------------------
Description:
When having a loop with forms in zones as in
<t:loop source="...">
<t:zone t:id="zone">
<t:form t:id="f" t:zone="prop:zone.clientid">
...
</t:form>
</t:zone>
</t:loop>
The form updates the zone correctly on the first submit. The update handler
returns the form (this is simpler in my application, as the zone/form is in a
separate component) as in
@Component
private Form _f;
Object onSuccess() {
....
return _f;
}
The return value contains the markup + a script to link the form to the zone
again. At this point the form does not know what the id was of the original
zone, and returns a zone name of the form "zone:<number>". As the zone cannot
be found, the whole page is refreshed when submitting the form a second time.
To solve this from the user perspective one possibility to set the client id
used for the zone explicitly, but this may cause problems with uniqueness of
names.
Ideally the javascript will return the zone id in the AJAX request, so that it
is not necessary to track the zone id in the application. The javascript
linking the form to the zone could then use the correct zone id.
Thanks,
Adriaan
was:
When having a loop with forms in zones as in
<t:loop source="...">
<t:zone t:id="zone">
<t:form t:id="f" t:zone="prop:zone.clientid">
...
</t:form>
</t:zone>
</t:loop>
The form updates the zone correctly on the first submit. The update handler
returns the form (this is simpler in my application, as the zone/form is in a
separate component) as in
@Component
private Form _f;
Object onSuccess() {
....
return _f;
}
The return value contains the markup + a script to link the form to the zone
again. At this point the form does not know what the id was of the original
zone, and returns a zone name of the form "zone:<number>". As the zone cannot
be found, the whole page is refreshed when submitting the form a second time.
To solve this from the user perspective it must be possible to set the client
id used for the zone explicitly. Ideally (but this will still require the
ability to set the zone id explicitly as well) the javascript will return the
zone id in the request, so that it is not necessary to track the zone id in the
application.
Thanks,
Adriaan
> Forms in zones in loops have wrong zone id after update
> -------------------------------------------------------
>
> Key: TAPESTRY-2360
> URL: https://issues.apache.org/jira/browse/TAPESTRY-2360
> Project: Tapestry
> Issue Type: Bug
> Components: XHR/dhtml/Ajax
> Affects Versions: 5.0.12
> Reporter: Adriaan Joubert
>
> When having a loop with forms in zones as in
> <t:loop source="...">
> <t:zone t:id="zone">
> <t:form t:id="f" t:zone="prop:zone.clientid">
> ...
> </t:form>
> </t:zone>
> </t:loop>
> The form updates the zone correctly on the first submit. The update handler
> returns the form (this is simpler in my application, as the zone/form is in a
> separate component) as in
> @Component
> private Form _f;
> Object onSuccess() {
> ....
> return _f;
> }
> The return value contains the markup + a script to link the form to the zone
> again. At this point the form does not know what the id was of the original
> zone, and returns a zone name of the form "zone:<number>". As the zone cannot
> be found, the whole page is refreshed when submitting the form a second time.
> To solve this from the user perspective one possibility to set the client id
> used for the zone explicitly, but this may cause problems with uniqueness of
> names.
> Ideally the javascript will return the zone id in the AJAX request, so that
> it is not necessary to track the zone id in the application. The javascript
> linking the form to the zone could then use the correct zone id.
> Thanks,
> Adriaan
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
