[ http://issues.apache.org/jira/browse/TAPESTRY-517?page=comments#action_12322770 ]
Jonas Maurus commented on TAPESTRY-517: --------------------------------------- I have now looked through all components that implement any kind of loop. They all call renderBody() repeatedly to render their own body multiple times. I also think that a component that loops over its body should not have to manage its childrens identities, the framework should take care of that. So fixing it the way I did in the last patch might be the way to go after all, but the JavaDoc documentation of renderBody() would have to be changed to reflect that fact, so if someone overwrites renderBody() in his component he'd know what to do. Another possibility that I didn't get to in my last comment (http://issues.apache.org/jira/browse/TAPESTRY-517#action_12320697) is to change the prerender code in such a way that it doesn't allocate a real ID while rendering the component (not changing IdAllocator's state). Essentially, the prerender code would operate on a cloned version of IdAllocator, not changing the real IdAllocator's state. During the real rendering cycle, the markup writer would check for prerendered code with the then allocated Id returned by the real IdAllocator and if it was rendered before, just write out the cached HTML. Managing the prerenderMap would move out of FormSupportImpl. This would also possibly be the first step to make any component prerenderable and therefore Tapestry pages "precompilable" if the markup writer implementation would cache prerendered content on disc. But that's possibly far in the future and I haven't thought this through, just experimented with a private Tapestry build. For 4.0 I recommend my patch unless I've broken something that I don't know about. > 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]
