[
https://issues.apache.org/jira/browse/WICKET-3972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13087549#comment-13087549
]
Juergen Donnerstag commented on WICKET-3972:
--------------------------------------------
Unfortunately it doesn't work. I wish it would, since it's simple than what we
need to do today. There are several issues with this approach:
- which counter do you want to use? A new handler is created with every markup.
The Page is not available. May be the Session, but you don't want to create it
for stateless apps. The App / MarkupFactory?
- You couldn't even use a counter per Handler if the Handler wouldn't get
re-created, or use the resource stream or whatever, since the number scheme
would only work if you can guarantee that the markup/Component is always used
with the same Page only. But of course Components can be added to as many
different Pages/Containers as you like. And every Page has a different sequence
in which it loads its components. You inevitably will have clashes, except you
choose an application scoped counter. But that is inpracticable, since it will
overrun for large or busy apps, or apps which are in prod for a long time.
- Because of transparent containers you cannot assume the much smuch smaller
scope of a container for possible clashes, but to be safe, the complete page.
Did you try if the quickstart provided by Sergiy works if you remove
tag.setId(xx) from WicketMessageTagHandler.resolver()? The invocation of
tag.setId(xxx) should really not be there.
I think the convention is fine. The issue is that we don't enforce it in the
code.
> 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
