You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Korbinian Bachl <ko...@whiskyworld.de> on 2016/10/03 11:50:53 UTC
WICKET-6088 / breaking of custom markup manipulation
Hello,
I've just done some debugging work for Ingo Renner. His project is somehow similar to the brix cms and the way of manipulating the components within the markup stream resolution. This worked in 6.x and 7.0-7.2, but was broken in 7.3+ with commit:
https://github.com/apache/wicket/commit/309fb0801a91d1c8be078767243ace384729f7f0
as the dequeueAutoComponents not longer was part of the process; A manual execution of it alone in e.g.: onInitialize also won't work as only the first rendering works, the following wont refresh the markup (since some parts get cached contrary to previuous behavior).
While I understand that its important to enhance wicket as a framework, I really dont understand why this has to be done in a subversion. Why not in e.g.: wicket 8? This way any upgrade from wicket 7.2 to 7.3 just may break existing apps.
Best,
Korbinian
------------------
example from Ingo that breaks by just moving from 7.2 to 7.3:
@Override
public IResourceStream getMarkupResourceStream(MarkupContainer container , Class<?> containerClass ) {
// This simulates loading the template from external source
InputStream src = HomePage. class .getResourceAsStream( "HomePageSrc.html" );
String srcStr = "" ;
try {
srcStr = Streams. readString ( src );
// now replacing my special markup "tag" with a real html tag
srcStr = srcStr .replace( "${tile}" , "<div wicket:id=\"tile\"></div>" );
// and adding the component to the page
HomePage. this .add( new Label( "tile" , Model. of ( "Content of dynamic component aka tile." )));
} catch (IOException e ) {
// TODO Auto-generated catch block
e .printStackTrace();
}
StringResourceStream stringResourceStream = new StringResourceStream( srcStr , "text/html" );
return stringResourceStream ;
}
Re: WICKET-6088 / breaking of custom markup manipulation
Posted by Korbinian Bachl <ko...@whiskyworld.de>.
Hi Martin,
did a report: https://issues.apache.org/jira/browse/WICKET-6251
Best,
Korbinian
----- Ursprüngliche Mail -----
> Von: "Martin Grigorov" <mg...@apache.org>
> An: dev@wicket.apache.org
> Gesendet: Montag, 3. Oktober 2016 14:27:15
> Betreff: Re: WICKET-6088 / breaking of custom markup manipulation
> Hi Korbinian,
>
> Ingo has already reported this issue few months ago:
> http://markmail.org/message/d4w4ffwcdbaehltv
>
> The "component queueing" stuff broke (and still breaks) a lot of
> functionality in Wicket 7.x.
> Kudos to Andrea Del Bene for his efforts trying to fix all corner cases!
>
> You could file a ticket at JIRA and hope that Andrea will find a fix for it.
>
> IMO the component queueing was a mistake and should be removed in a future
> version of Wicket.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Mon, Oct 3, 2016 at 1:50 PM, Korbinian Bachl <
> korbinian.bachl@whiskyworld.de> wrote:
>
>> Hello,
>>
>> I've just done some debugging work for Ingo Renner. His project is somehow
>> similar to the brix cms and the way of manipulating the components within
>> the markup stream resolution. This worked in 6.x and 7.0-7.2, but was
>> broken in 7.3+ with commit:
>>
>> https://github.com/apache/wicket/commit/309fb0801a91d1c8be078767243ace
>> 384729f7f0
>>
>> as the dequeueAutoComponents not longer was part of the process; A manual
>> execution of it alone in e.g.: onInitialize also won't work as only the
>> first rendering works, the following wont refresh the markup (since some
>> parts get cached contrary to previuous behavior).
>>
>> While I understand that its important to enhance wicket as a framework, I
>> really dont understand why this has to be done in a subversion. Why not in
>> e.g.: wicket 8? This way any upgrade from wicket 7.2 to 7.3 just may break
>> existing apps.
>>
>> Best,
>>
>> Korbinian
>>
>> ------------------
>>
>> example from Ingo that breaks by just moving from 7.2 to 7.3:
>>
>>
>>
>>
>>
>>
>>
>>
>> @Override
>>
>> public IResourceStream getMarkupResourceStream(MarkupContainer container
>> , Class containerClass ) {
>>
>>
>>
>> // This simulates loading the template from external source
>>
>> InputStream src = HomePage. class .getResourceAsStream( "HomePageSrc.html"
>> );
>>
>> String srcStr = "" ;
>>
>> try {
>>
>> srcStr = Streams. readString ( src );
>>
>>
>>
>> // now replacing my special markup "tag" with a real html tag
>>
>> srcStr = srcStr .replace( "${tile}" , "wicket:id=\"tile\">" );
>>
>>
>>
>> // and adding the component to the page
>>
>> HomePage. this .add( new Label( "tile" , Model. of ( "Content of dynamic
>> component aka tile." )));
>>
>>
>>
>> } catch (IOException e ) {
>>
>> // TODO Auto-generated catch block
>>
>> e .printStackTrace();
>>
>> }
>>
>> StringResourceStream stringResourceStream = new StringResourceStream(
>> srcStr , "text/html" );
>>
>> return stringResourceStream ;
>>
>> }
Re: WICKET-6088 / breaking of custom markup manipulation
Posted by Martin Grigorov <mg...@apache.org>.
Hi Korbinian,
Ingo has already reported this issue few months ago:
http://markmail.org/message/d4w4ffwcdbaehltv
The "component queueing" stuff broke (and still breaks) a lot of
functionality in Wicket 7.x.
Kudos to Andrea Del Bene for his efforts trying to fix all corner cases!
You could file a ticket at JIRA and hope that Andrea will find a fix for it.
IMO the component queueing was a mistake and should be removed in a future
version of Wicket.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Mon, Oct 3, 2016 at 1:50 PM, Korbinian Bachl <
korbinian.bachl@whiskyworld.de> wrote:
> Hello,
>
> I've just done some debugging work for Ingo Renner. His project is somehow
> similar to the brix cms and the way of manipulating the components within
> the markup stream resolution. This worked in 6.x and 7.0-7.2, but was
> broken in 7.3+ with commit:
>
> https://github.com/apache/wicket/commit/309fb0801a91d1c8be078767243ace
> 384729f7f0
>
> as the dequeueAutoComponents not longer was part of the process; A manual
> execution of it alone in e.g.: onInitialize also won't work as only the
> first rendering works, the following wont refresh the markup (since some
> parts get cached contrary to previuous behavior).
>
> While I understand that its important to enhance wicket as a framework, I
> really dont understand why this has to be done in a subversion. Why not in
> e.g.: wicket 8? This way any upgrade from wicket 7.2 to 7.3 just may break
> existing apps.
>
> Best,
>
> Korbinian
>
> ------------------
>
> example from Ingo that breaks by just moving from 7.2 to 7.3:
>
>
>
>
>
>
>
>
> @Override
>
> public IResourceStream getMarkupResourceStream(MarkupContainer container
> , Class<?> containerClass ) {
>
>
>
> // This simulates loading the template from external source
>
> InputStream src = HomePage. class .getResourceAsStream( "HomePageSrc.html"
> );
>
> String srcStr = "" ;
>
> try {
>
> srcStr = Streams. readString ( src );
>
>
>
> // now replacing my special markup "tag" with a real html tag
>
> srcStr = srcStr .replace( "${tile}" , "<div wicket:id=\"tile\"></div>" );
>
>
>
> // and adding the component to the page
>
> HomePage. this .add( new Label( "tile" , Model. of ( "Content of dynamic
> component aka tile." )));
>
>
>
> } catch (IOException e ) {
>
> // TODO Auto-generated catch block
>
> e .printStackTrace();
>
> }
>
> StringResourceStream stringResourceStream = new StringResourceStream(
> srcStr , "text/html" );
>
> return stringResourceStream ;
>
> }
>