[
https://issues.apache.org/jira/browse/WICKET-3931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071971#comment-13071971
]
Juergen Donnerstag commented on WICKET-3931:
--------------------------------------------
First I was thinking that other components are affected as well, but only
auto-components get their markup set via setMarkup(), which is why they don't
need to know how to find their markup. But than I found this:
MarkupContainer:
void detachChildren()
{
...
// We need to keep InlineEnclosures for Ajax request
handling.
// TODO this is really ugly. Feature request for 1.5:
change auto-component that
// they don't need to be removed anymore.
if (component.isAuto() && !(component instanceof
InlineEnclosure))
{
children_remove(i);
}
which makes me belief that the problem is limited to InlineEnclosure only. I
think we have two options. Either the way it's implemented in your patch
(InlineEnclosure implements getMarkup()) or InlineEnclosure gets a variable
markup which is not reset. Any variation change has no effect on
InlineEnclosure ajax upates anyway, since the markup will not be reloaded under
any circumstances.
Pseudo code: InlineEnclosure
// avoid all the extra info which come with IMF implementations
private String markup
IMF getMarkup()
{
IMF markup = super.getMarkup();
// resolver has set markup upon auto-component creation. Local markup not
yet set => remember
if (markup != null && this.markup == null)
{
this.markup = markup.toString()
}
// markup == null because of detach, but we have our local copy => use
copy to set markup
else if (markup == null && this.markup != null)
{
markup = Markup.of(this.markup)
setMarkup(markup)
}
return markup
}
> Component markup caching inconsistencies
> ----------------------------------------
>
> Key: WICKET-3931
> URL: https://issues.apache.org/jira/browse/WICKET-3931
> Project: Wicket
> Issue Type: Bug
> Components: wicket-core
> Affects Versions: 1.5-RC5.1
> Reporter: Martin Grigorov
> Assignee: Juergen Donnerstag
> Attachments: WICKET-3931.patch, variation.tgz
>
>
> In WICKET-3891 we found that Component#markup field is not being reset
> between requests. The problem is that this field is transient and it is
> null-ified only when the page is read from the second level page cache (see
> https://cwiki.apache.org/confluence/x/qIaoAQ). If the page instance is read
> from first level cache (http session) then its non-serialized version is used
> and the markup field value is still non-null.
> In WICKET-3891 this looked like a minor issue with the markup caching in
> development mode but actually this problem is valid even in production mode.
> See the attached application. When the panel's variation is changed every
> MarkupContainer inside still uses its old markup.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
