[
https://issues.apache.org/jira/browse/WICKET-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13087414#comment-13087414
]
Peter Ertl edited comment on WICKET-3972 at 8/19/11 12:26 AM:
--------------------------------------------------------------
@Jürgen: Thanks for the feedback :-)
I think the problem can be solved by not assigning a temporary component tag id
('_message_attr_') but a permanent one including a counter to the component
tags with 'wicket:message' attribute.
currently we have the situation that 3 component tags with 'wicket:message' are
located in the markup but only two of them get resolved on first render of
HomePage
component tag#1 (id = '_message_attr_') -- invisible since list view is empty,
so WicketMessageTagHandler#resolve() is not invoked and temporary id stays
component tag#2 (id = '_message_attr_3')
component tag#3 (id = '_message_attr_4')
-> go to SecondPage
-> go to HomePage with now visible ListView caused by page parameter
resolve now assigns a permanent id to the first component which will cause an
identifier collision
component tag#1 (id = '_message_attr_4') -> new permanent id assigned, will
refer to component that has been attached to component tag #3 recently
component tag#2 (id = '_message_attr_3') -> since the component tag has a
related component resolve will not be invoked and the old id stays
component tag#3 (id = '_message_attr_4') -> since the component tag has a
related component resolve will not be invoked and the old id stays; wicket will
again render component that has accidentally already been rendered by component
tag #1 and causes the 'component was already rendered' error
new patch included...
was (Author: pete):
@Jürgen: Thanks for the feedback :-)
I think the problem can be solved by not assigning a temporary component tag id
('_message_attr_') to the component tags with 'wicket:message' attribute
currently we have the situation that 3 component tags with 'wicket:message' are
located in the markup but only two of them get resolved on first render of
HomePage
component tag#1 (id = '_message_attr_') -- invisible since list view is empty,
so WicketMessageTagHandler#resolve() is not invoked and temporary id stays
component tag#2 (id = '_message_attr_3')
component tag#3 (id = '_message_attr_4')
-> go to SecondPage
-> go to HomePage with now visible ListView caused by page parameter
resolve now assigns a permanent id to the first component which will cause an
identifier collision
component tag#1 (id = '_message_attr_4') -> new permanent id assigned, will
refer to component that has been attached to component tag #3 recently
component tag#2 (id = '_message_attr_3') -> since the component tag has a
related component resolve will not be invoked and the old id stays
component tag#3 (id = '_message_attr_4') -> since the component tag has a
related component resolve will not be invoked and the old id stays; wicket will
again render component that has accidentally already been rendered by component
tag #1 and causes the 'component was already rendered' error
new patch included...
> wicket:message attribute results in "The component was rendered already" error
> ------------------------------------------------------------------------------
>
> Key: WICKET-3972
> URL: https://issues.apache.org/jira/browse/WICKET-3972
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
> Affects Versions: 1.5-RC5.1
> Environment: Linux Ubuntu, Tomcat 6, Java 6
> Reporter: Sergiy Barlabanov
> Assignee: Peter Ertl
> Attachments: quickstart.zip, wicket-message-index.patch
>
>
> Seems like there is a problem with generation of tag and component IDs when
> using wicket:message as an attribute for tags inside ListView.
> The quickstart webapp is attached to this ticket. There are two pages in this
> webapp: HomePage with a ListView containing tags with wicket:message
> attribute and two tags with wicket:message attribute outside the ListView. If
> a user goes to the next page (SecondPage) using the link on HomePage and then
> goes back to HomePage using the link on SecondPage, the exception mentioned
> in the subject occurs.
> Seems that the ID generation for tags and components is wrong: the
> ComponentTag-s are cached together with the corresponding Markup and then
> reused for later renderings. But the problem is, that those ComponentTag-s
> are mutable (at least in case of tags with wicket:message attribute) and
> their IDs are changed on every rendering and this produces ID conflicts when
> MarkupContainer.renderNext tries to find or create components corresponding
> to the tags.
> Interesting is, that we can reproduce this bug only in DEVELOPMENT mode. In
> DEPLOYMENT mode everything seems to work. The solution would be to make
> ComponentTags immutable and do not allow to change them, but to create copies
> (there is mutable method in ComponentTag, which is used in some cases).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
