You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by andrea del bene <an...@gmail.com> on 2015/11/17 12:05:12 UTC
Help with WICKET-6028
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.
Re: Help with WICKET-6028
Posted by andrea del bene <an...@gmail.com>.
Thank you guys! I will finalize the patch in the next days.
Andrea.
> Yep from me, too!
>
> kind regards
>
> Tobias
>
>> Am 17.11.2015 um 22:08 schrieb Martin Grigorov <mg...@apache.org>:
>>
>> I like the change!
>> It actually simplifies the component tree in case of markup inheritance.
>>
>> Good job, Andrea!
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Tue, Nov 17, 2015 at 8:30 PM, Martin Grigorov <mg...@apache.org>
>> wrote:
>>
>>> 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 <an...@gmail.com>
>>> 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.
>>>
Re: Help with WICKET-6028
Posted by Tobias Soloschenko <to...@gmail.com>.
Yep from me, too!
kind regards
Tobias
> Am 17.11.2015 um 22:08 schrieb Martin Grigorov <mg...@apache.org>:
>
> I like the change!
> It actually simplifies the component tree in case of markup inheritance.
>
> Good job, Andrea!
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Tue, Nov 17, 2015 at 8:30 PM, Martin Grigorov <mg...@apache.org>
> wrote:
>
>> 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 <an...@gmail.com>
>> 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.
>>
>>
Re: Help with WICKET-6028
Posted by Martin Grigorov <mg...@apache.org>.
I like the change!
It actually simplifies the component tree in case of markup inheritance.
Good job, Andrea!
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Tue, Nov 17, 2015 at 8:30 PM, Martin Grigorov <mg...@apache.org>
wrote:
> 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 <an...@gmail.com>
> 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.
>>
>
>
Re: Help with WICKET-6028
Posted by Martin Grigorov <mg...@apache.org>.
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 <an...@gmail.com>
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.
>