The start of the patch doesn't look promising ;-)
--- a/wicket-core/src/main/java/org/apache/wicket/Application.java
+++ b/wicket-core/src/main/java/org/apache/wicket/Application.java
@@ -813,7 +813,7 @@
PageSettings pageSettings = getPageSettings();
// Install default component resolvers
- pageSettings.addComponentResolver(new
MarkupInheritanceResolver());
+ //pageSettings.addComponentResolver(new
MarkupInheritanceResolver());
pageSettings.addComponentResolver(new HtmlHeaderResolver());
I'll take a look soon.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Tue, Nov 17, 2015 at 12:05 PM, andrea del bene <[email protected]>
wrote:
> Hi everybody,
>
> lately I had quite a time trying to fix WICKET-6028. In short, the
> problem is the following. When we have markup inheritance two components
> (two TransparentWebMarkupContainer) are associated to tags <wicket:child/>
> and <wicket:extend>. Since they are MarkupContainers, these two components
> perform auto-components dequeueing when they are initialized. However their
> corresponding tags are skipped during dequeuing process (see
> MarkupContainer#canDequeueTag) leading to the problem of this issue.
> I've tried different approaches to find a solution (allowing tag
> dequeuing, changing TransparentWebMarkupContainer queuing logic, etc...)
> but I always ended up breaking some (markup) parsing rule of the framework.
> The only approach that seems to work is to treat tags <wicket:child/> and
> <wicket:extend> as raw tags, without associating any component to them.
> I've attached this fix to the issue.
>
> Let me know if you have better ideas or any other kind of insight about
> this problem (or if you absolutely dislike my proposed fix :-) ).
>
> Andrea.
>
