[ http://issues.apache.org/jira/browse/TAPESTRY-517?page=all ]
Jonas Maurus updated TAPESTRY-517:
----------------------------------
Attachment: TAPESTRY-517.clientid_fix.diff
new patch, including the work-around from my last comment.
This seems to fix the issue, but will of course not work for components that
implement any kind of loop but do not derive from AbstractComponent, or
overload renderBody(). Still as it works, I'd guess that it gives directions on
how to fix this bug properly. There are 3 possibilities:
1. add a parameter to FieldLabel to skip the prerender so the developer can
mark all FieldLabels that are rendered after their associated form fields
2. change all components that rerender (i.e. loop over) other components inside
their body so they reset their contained components identity fields on every
iteration effectively making them keep their identity while they're being
rendered
3. disallow a component instance to change its identity (effectively creating a
"one object instance is one component instance" relationship between templates
and java code) and rewrite loop handling so that components are instantiated on
the fly
I'd say 1 is not intuitive and will only push the bug further down the road, 3
is possibly the right thing to do, but changes Tapestry's performance
characteristics, memory usage and potentially breaks stuff.
So I'd go for 2. I guess the following components have to be changed: For,
Foreach, ListEdit, Table, FormTable and Tree. I'll try to work on a patch over
the next view days, but comments are very welcome at this point as I'm still
new to the codebase and might be about to break things that I know nothing
about which would make this a worthless exercise :-)
> Using a FieldLabel component after the decorated form component causes the
> FieldLabel's id attribute to be wrong
> ----------------------------------------------------------------------------------------------------------------
>
> Key: TAPESTRY-517
> URL: http://issues.apache.org/jira/browse/TAPESTRY-517
> Project: Tapestry
> Type: Bug
> Components: Framework
> Versions: 4.0
> Reporter: Jonas Maurus
> Assignee: Howard M. Lewis Ship
> Attachments: AbstractFormComponent.clientid_fix.diff,
> AbstractFormComponent.clientid_fix_2.diff,
> AbstractFormComponent.clientid_fix_3.diff,
> AbstractFormComponent.clientid_fix_4.diff,
> AbstractFormComponent.clientid_fix_cvs_HEAD_20050825_1358.diff,
> TAPESTRY-517.clientid_fix.diff
>
> Quoting from TAPESTRY-409:
> <!-- page definition -->
> <component id="bookkeeperRCB" type="Checkbox">
> <binding name="selected" value="hasBookkeeperRole" />
> </component>
>
> <component id="adminRCB" type="Checkbox">
> <binding name="selected" value="hasAdministratorRole" />
> </component>
> <!-- page template -->
> <tr>
> <td><input jwcid="bookkeeperRCB" type="checkbox" value="Y" /></td>
> <td><label jwcid="@FieldLabel" for="bookkeeper"
> field="ognl:components.bookkeeperRCB"
> displayName="message:form.roles.bookkeeper">Bookkeeper</label></td>
> </tr>
> <tr>
> <td><input jwcid="adminRCB" type="checkbox" value="Y" /></td>
> <td><label jwcid="@FieldLabel" for="admin"
> field="ognl:components.adminRCB"
> displayName="message:form.roles.administrator">Administrator</label></td>
> </tr>
> yields:
> <tr>
> <td><input type="checkbox" name="bookkeeperRCB" id="bookkeeperRCB"
> value="Y"/></td>
> <td><label for="bookkeeperRCB$0">Bookkeeper</label></td>
> </tr>
> <tr>
> <td><input type="checkbox" name="adminRCB" checked="checked" id="adminRCB"
> value="Y"/></td>
> <td><label for="adminRCB$0">Administrator</label></td>
> </tr>
> as you can see the generated fieldnames ("bookkeeperRCB$0"...) are wrong.
> This always results in a stale-link exception.
> I tracked down the bug: FieldLabel calls prerenderField() which in turn
> causes an uniqueId to be allocated in
> AbstractFormComponent.renderIdAttribute. Everything works out when the
> FieldLabel precedes the form component it decorates. If it comes after the
> form component, IRequestCycle.getUniqueId() will already have stored an id
> for the component and return a new one.
> I'm not quite sure about the mechanics described above, as I don't fully
> understand FormSupportImpl yet, perhaps someone else can shed light on this.
> However, the allocated client id wasn't cached properly in
> AbstractFormComponent.renderIdAttribute. I'll attach a patch as soon as I've
> saved this bug report.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
