Re: Wicket 8 migration / header contributions question

[Andrea Del Bene]

Hi,

I've added a note at the beginning of the migration guide listing important
changes that should be checked during migration even if you don't have
compilation problems. Feel free to improve/enrich it.

On Fri, May 25, 2018 at 11:42 AM, Sven Meier  wrote:

> Hi,
>
> it would be great if you could provide a quickstart showing the problem.
>
> Thanks
> Sven
>
>
>
> Am 25.05.2018 um 10:34 schrieb Tobias Gierke:
>
>> Hi,
>>
>>> Hi Thomas,
>>>
>>> that should work.
>>>
>>> Could you please compare your setup with the one in
>>> https://github.com/apache/wicket/tree/master/wicket-examples
>>> /src/main/java/org/apache/wicket/examples/resourcedecoration
>>>
>> My code is identical except I'm using FilteringHeaderResponse with a
>> custom "bucket" name instead of JavaScriptFilteredIntoFooterHe
>> aderResponse.
>>
>> Anyway, for the time being I solved my issue by fixing my HeaderItem
>> dependencies and just deleting my custom header decoration stuff (as it
>> turned out I was basically abusing this feature to work around my broken
>> HeaderItem dependencies :-)
>>
>> I still feel that the WICKET-6498 change somehow interacts with
>> FilteringHeaderResponse in a not-too-obvious way (our code used to work in
>> 7.10 but fails in 8.0.0).
>>
>> Cheers,
>> Tobi
>>
>>>
>>> Thanks
>>> Sven
>>>
>>> Am 24. Mai 2018 08:43:47 MESZ schrieb Tobias Gierke <
>>> tobias.gie...@code-sourcery.de>:
>>>
 Hi,

> Hi,
>
> this should be caused by WICKET-6498. This issue has changed the
> behavior for HeaderResponseDecorator. You can find how to adapt your
> code in the migration guide or in the release note of Milestone 9:
>
>
> https://wicket.apache.org/news/2018/02/17/wicket-8.0.0-M9-
 released.html

 Thanks for the quick response! I already tried this and it didn't have
 any effect :/

 My Application#init() method is doing:

 setHeaderResponseDecorator( response ->new ResourceAggregator(new
 FilteringHeaderResponse(response) ) );



 Cheers,
 Tobias

>>>
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: Wicket 8 migration / header contributions question

[Sven Meier]

Hi,

it would be great if you could provide a quickstart showing the problem.

Thanks
Sven


Am 25.05.2018 um 10:34 schrieb Tobias Gierke:

Hi,

Hi Thomas,

that should work.

Could you please compare your setup with the one in 
https://github.com/apache/wicket/tree/master/wicket-examples/src/main/java/org/apache/wicket/examples/resourcedecoration
My code is identical except I'm using FilteringHeaderResponse with a 
custom "bucket" name instead of 
JavaScriptFilteredIntoFooterHeaderResponse.


Anyway, for the time being I solved my issue by fixing my HeaderItem 
dependencies and just deleting my custom header decoration stuff (as 
it turned out I was basically abusing this feature to work around my 
broken HeaderItem dependencies :-)


I still feel that the WICKET-6498 change somehow interacts with 
FilteringHeaderResponse in a not-too-obvious way (our code used to 
work in 7.10 but fails in 8.0.0).


Cheers,
Tobi


Thanks
Sven

Am 24. Mai 2018 08:43:47 MESZ schrieb Tobias Gierke 
:

Hi,

Hi,

this should be caused by WICKET-6498. This issue has changed the
behavior for HeaderResponseDecorator. You can find how to adapt your
code in the migration guide or in the release note of Milestone 9:



https://wicket.apache.org/news/2018/02/17/wicket-8.0.0-M9-released.html

Thanks for the quick response! I already tried this and it didn't have
any effect :/

My Application#init() method is doing:

setHeaderResponseDecorator( response ->new ResourceAggregator(new
FilteringHeaderResponse(response) ) );



Cheers,
Tobias





-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket 8 migration / header contributions question

[Martin Grigorov]

Hi,

On Fri, May 25, 2018 at 11:38 AM, Tobias Gierke <
tobias.gie...@voipfuture.com> wrote:

> Hi,
>
>> Hi,
>>
>> this should be caused by WICKET-6498. This issue has changed the behavior
>> for HeaderResponseDecorator. You can find how to adapt your code in the
>> migration guide or in the release note of Milestone 9:
>>
>
> Btw, could you maybe enhance the migration guide to include a warning
> about JS event names like "onclick","onblur" etc. no longer working ?
>
> I know that Wicket 7.x used to printed lots of warnings about this but
> somehow we (and probably others as well) were too lazy to fix them when
> upgrading to 7.x and now the warnings are gone but AJAX behaviors using the
> old event names stopped working completely.
>

Those warnings were added at 6.x and since 7.0.0.
For 8.0.0-Mx (the milestones) they were errors, i.e. throwing exceptions,
and we reomved them just before 8.0.0.
Maybe you can use -M9 temporarily just to fix them in your code base ?


>
> Thanks,
> Tobias
>
>>
>> https://wicket.apache.org/news/2018/02/17/wicket-8.0.0-M9-released.html
>>
>>
>>
>>
>> On 23/05/2018 17:55, Tobias Gierke wrote:
>>
>>> Hi,
>>>
>>> I'm in the process of migrating our application from Wicket 7.10 to
>>> Wicket 8 and encountered some weirdness with regards to header
>>> contributions.
>>>
>>> Our application has a top-level WebPage that defines a
>>> HeaderResponseContainerat the very end of the page markup and all other
>>> application pages inherit from it. We have a few header items that need to
>>> be rendered in their own section at the bottom of the page so I basically
>>> took the approach outlined in http://tomaszdziurko.com/2017/
>>> 02/forcing-wicket-place-javascript-files-bottom/ and adopted it to our
>>> needs.
>>>
>>> Our Application#init() method does this:
>>>
>>> ---final IHeaderResponseDecorator
>>> headerResponseDecorator =new IHeaderResponseDecorator()
>>>{
>>>   @Override public IHeaderResponse decorate(IHeaderResponse response)
>>>   {
>>>  return new FilteringHeaderResponse(response);
>>>   }
>>>};
>>>setHeaderResponseDecorator(headerResponseDecorator);
>>> ---
>>>
>>> And from inside Behavior#renderHead() we're doing
>>>
>>> ---final OnDomReadyHeaderItem toWrap =
>>> OnDomReadyHeaderItem.forScript(script);
>>> response.render(new FilteredHeaderItem(toWrap, "our-bucket" );
>>> ---
>>>
>>> This was working fine in Wicket 7.10 but with Wicket 8 the Wicket
>>> defeault Javascript files (wicket-event-jquery,wicket-ajax-jquery etc.)
>>> are no longer being included in the page so AJAX buttons etc. fail with
>>> "TypeError: Wicket.Event is undefined" etc.
>>>
>>> Wrapping the FilteringHeaderResponse inside a ResourceAggregator like||
>>> shown in the migration guide had no effect.
>>>
>>>
>>> Thanks,
>>> Tobias
>>>
>>>
>>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
> --
> Tobias Gierke
> Software Developer
>
> Voipfuture GmbH   Wendenstr. 4   20097 Hamburg   Germany
> Phone +49 40 688 9001 64   Fax +49 40 688 9001 99   www.voipfuture.com
> Managing Directors   Jan Bastian   Eyal Ullert
> Commercial Court AG Hamburg   HRB 109896   VAT ID DE263738086
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: Wicket 8 migration / header contributions question

[Tobias Gierke]

Hi,

Hi,

this should be caused by WICKET-6498. This issue has changed the 
behavior for HeaderResponseDecorator. You can find how to adapt your 
code in the migration guide or in the release note of Milestone 9:


Btw, could you maybe enhance the migration guide to include a warning 
about JS event names like "onclick","onblur" etc. no longer working ?


I know that Wicket 7.x used to printed lots of warnings about this but 
somehow we (and probably others as well) were too lazy to fix them when 
upgrading to 7.x and now the warnings are gone but AJAX behaviors using 
the old event names stopped working completely.


Thanks,
Tobias


https://wicket.apache.org/news/2018/02/17/wicket-8.0.0-M9-released.html




On 23/05/2018 17:55, Tobias Gierke wrote:

Hi,

I'm in the process of migrating our application from Wicket 7.10 to 
Wicket 8 and encountered some weirdness with regards to header 
contributions.


Our application has a top-level WebPage that defines a 
HeaderResponseContainerat the very end of the page markup and all 
other application pages inherit from it. We have a few header items 
that need to be rendered in their own section at the bottom of the 
page so I basically took the approach outlined in 
http://tomaszdziurko.com/2017/02/forcing-wicket-place-javascript-files-bottom/ 
and adopted it to our needs.


Our Application#init() method does this:

---final IHeaderResponseDecorator 
headerResponseDecorator =new IHeaderResponseDecorator()

   {
  @Override public IHeaderResponse decorate(IHeaderResponse 
response)

  {
 return new FilteringHeaderResponse(response);
  }
   };
   setHeaderResponseDecorator(headerResponseDecorator);
---

And from inside Behavior#renderHead() we're doing

---final OnDomReadyHeaderItem toWrap 
= OnDomReadyHeaderItem.forScript(script);

response.render(new FilteredHeaderItem(toWrap, "our-bucket" );
---

This was working fine in Wicket 7.10 but with Wicket 8 the Wicket 
defeault Javascript files (wicket-event-jquery,wicket-ajax-jquery 
etc.) are no longer being included in the page so AJAX buttons etc. 
fail with "TypeError: Wicket.Event is undefined" etc.


Wrapping the FilteringHeaderResponse inside a ResourceAggregator 
like|| shown in the migration guide had no effect.



Thanks,
Tobias





-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



--
Tobias Gierke
Software Developer

Voipfuture GmbH   Wendenstr. 4   20097 Hamburg   Germany
Phone +49 40 688 9001 64   Fax +49 40 688 9001 99   www.voipfuture.com
Managing Directors   Jan Bastian   Eyal Ullert
Commercial Court AG Hamburg   HRB 109896   VAT ID DE263738086



-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket 8 migration / header contributions question

[Tobias Gierke]

Hi,

Hi Thomas,

that should work.

Could you please compare your setup with the one in 
https://github.com/apache/wicket/tree/master/wicket-examples/src/main/java/org/apache/wicket/examples/resourcedecoration
My code is identical except I'm using FilteringHeaderResponse with a 
custom "bucket" name instead of JavaScriptFilteredIntoFooterHeaderResponse.


Anyway, for the time being I solved my issue by fixing my HeaderItem 
dependencies and just deleting my custom header decoration stuff (as it 
turned out I was basically abusing this feature to work around my broken 
HeaderItem dependencies :-)


I still feel that the WICKET-6498 change somehow interacts with 
FilteringHeaderResponse in a not-too-obvious way (our code used to work 
in 7.10 but fails in 8.0.0).


Cheers,
Tobi


Thanks
Sven

Am 24. Mai 2018 08:43:47 MESZ schrieb Tobias Gierke 
:

Hi,

Hi,

this should be caused by WICKET-6498. This issue has changed the
behavior for HeaderResponseDecorator. You can find how to adapt your
code in the migration guide or in the release note of Milestone 9:



https://wicket.apache.org/news/2018/02/17/wicket-8.0.0-M9-released.html

Thanks for the quick response! I already tried this and it didn't have
any effect :/

My Application#init() method is doing:

setHeaderResponseDecorator( response ->new ResourceAggregator(new
FilteringHeaderResponse(response) ) );



Cheers,
Tobias


--
Tobias Gierke
Software Developer

Voipfuture GmbH   Wendenstr. 4   20097 Hamburg   Germany
Phone +49 40 688 9001 64   Fax +49 40 688 9001 99   www.voipfuture.com
Managing Directors   Jan Bastian   Eyal Ullert
Commercial Court AG Hamburg   HRB 109896   VAT ID DE263738086

Re: Wicket 8 migration / header contributions question

[Sven Meier]

Hi Thomas,

that should work.

Could you please compare your setup with the one in 
https://github.com/apache/wicket/tree/master/wicket-examples/src/main/java/org/apache/wicket/examples/resourcedecoration

Thanks
Sven

Am 24. Mai 2018 08:43:47 MESZ schrieb Tobias Gierke 
:
>Hi,
>> Hi,
>>
>> this should be caused by WICKET-6498. This issue has changed the 
>> behavior for HeaderResponseDecorator. You can find how to adapt your 
>> code in the migration guide or in the release note of Milestone 9:
>>
>>
>https://wicket.apache.org/news/2018/02/17/wicket-8.0.0-M9-released.html
>
>Thanks for the quick response! I already tried this and it didn't have 
>any effect :/
>
>My Application#init() method is doing:
>
>setHeaderResponseDecorator( response ->new ResourceAggregator(new
>FilteringHeaderResponse(response) ) );
>
>
>
>Cheers,
>Tobias

Re: Wicket 8 migration / header contributions question

[Tobias Gierke]

Hi,

Hi,

this should be caused by WICKET-6498. This issue has changed the 
behavior for HeaderResponseDecorator. You can find how to adapt your 
code in the migration guide or in the release note of Milestone 9:


https://wicket.apache.org/news/2018/02/17/wicket-8.0.0-M9-released.html


Thanks for the quick response! I already tried this and it didn't have 
any effect :/


My Application#init() method is doing:

setHeaderResponseDecorator( response ->new ResourceAggregator(new 
FilteringHeaderResponse(response) ) );



Cheers,
Tobias

Re: Wicket 8 migration / header contributions question

[Andrea Del Bene]

Actually i've just expanded it, but I'm considering the idea of adding 
some kind of note or section for those issues like WICKET-6498  and 
WICKET-6189 which might be tricky to deal with.



On 23/05/2018 22:36, Tobias Soloschenko wrote:

Oh just saw - you added it!

kind regards

Tobias


Am 23.05.2018 um 18:54 schrieb Andrea Del Bene :

Hi,

this should be caused by WICKET-6498. This issue has changed the behavior for 
HeaderResponseDecorator. You can find how to adapt your code in the migration 
guide or in the release note of Milestone 9:

https://wicket.apache.org/news/2018/02/17/wicket-8.0.0-M9-released.html





On 23/05/2018 17:55, Tobias Gierke wrote:
Hi,

I'm in the process of migrating our application from Wicket 7.10 to Wicket 8 
and encountered some weirdness with regards to header contributions.

Our application has a top-level WebPage that defines a 
HeaderResponseContainerat the very end of the page markup and all other 
application pages inherit from it. We have a few header items that need to be 
rendered in their own section at the bottom of the page so I basically took the 
approach outlined in 
http://tomaszdziurko.com/2017/02/forcing-wicket-place-javascript-files-bottom/ 
and adopted it to our needs.

Our Application#init() method does this:

---final IHeaderResponseDecorator 
headerResponseDecorator =new IHeaderResponseDecorator()
{
   @Override public IHeaderResponse decorate(IHeaderResponse response)
   {
  return new FilteringHeaderResponse(response);
   }
};
setHeaderResponseDecorator(headerResponseDecorator);
---

And from inside Behavior#renderHead() we're doing

---final OnDomReadyHeaderItem toWrap = 
OnDomReadyHeaderItem.forScript(script);
response.render(new FilteredHeaderItem(toWrap, "our-bucket" );
---

This was working fine in Wicket 7.10 but with Wicket 8 the Wicket defeault Javascript 
files (wicket-event-jquery,wicket-ajax-jquery etc.) are no longer being included in the 
page so AJAX buttons etc. fail with "TypeError: Wicket.Event is undefined" etc.

Wrapping the FilteringHeaderResponse inside a ResourceAggregator like|| shown 
in the migration guide had no effect.


Thanks,
Tobias




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket 8 migration / header contributions question

[Tobias Soloschenko]

Oh just saw - you added it!

kind regards

Tobias

> Am 23.05.2018 um 18:54 schrieb Andrea Del Bene :
> 
> Hi,
> 
> this should be caused by WICKET-6498. This issue has changed the behavior for 
> HeaderResponseDecorator. You can find how to adapt your code in the migration 
> guide or in the release note of Milestone 9:
> 
> https://wicket.apache.org/news/2018/02/17/wicket-8.0.0-M9-released.html
> 
> 
> 
> 
>> On 23/05/2018 17:55, Tobias Gierke wrote:
>> Hi,
>> 
>> I'm in the process of migrating our application from Wicket 7.10 to Wicket 8 
>> and encountered some weirdness with regards to header contributions.
>> 
>> Our application has a top-level WebPage that defines a 
>> HeaderResponseContainerat the very end of the page markup and all other 
>> application pages inherit from it. We have a few header items that need to 
>> be rendered in their own section at the bottom of the page so I basically 
>> took the approach outlined in 
>> http://tomaszdziurko.com/2017/02/forcing-wicket-place-javascript-files-bottom/
>>  and adopted it to our needs.
>> 
>> Our Application#init() method does this:
>> 
>> ---final IHeaderResponseDecorator 
>> headerResponseDecorator =new IHeaderResponseDecorator()
>>{
>>   @Override public IHeaderResponse decorate(IHeaderResponse response)
>>   {
>>  return new FilteringHeaderResponse(response);
>>   }
>>};
>>setHeaderResponseDecorator(headerResponseDecorator);
>> ---
>> 
>> And from inside Behavior#renderHead() we're doing
>> 
>> ---final OnDomReadyHeaderItem toWrap = 
>> OnDomReadyHeaderItem.forScript(script);
>> response.render(new FilteredHeaderItem(toWrap, "our-bucket" );
>> ---
>> 
>> This was working fine in Wicket 7.10 but with Wicket 8 the Wicket defeault 
>> Javascript files (wicket-event-jquery,wicket-ajax-jquery etc.) are no longer 
>> being included in the page so AJAX buttons etc. fail with "TypeError: 
>> Wicket.Event is undefined" etc.
>> 
>> Wrapping the FilteringHeaderResponse inside a ResourceAggregator like|| 
>> shown in the migration guide had no effect.
>> 
>> 
>> Thanks,
>> Tobias
>> 
>> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket 8 migration / header contributions question

[Tobias Soloschenko]

Hi Andrea,

is this also part of the migration document in confluence?

kind regards

Tobias

> Am 23.05.2018 um 18:54 schrieb Andrea Del Bene :
> 
> Hi,
> 
> this should be caused by WICKET-6498. This issue has changed the behavior for 
> HeaderResponseDecorator. You can find how to adapt your code in the migration 
> guide or in the release note of Milestone 9:
> 
> https://wicket.apache.org/news/2018/02/17/wicket-8.0.0-M9-released.html
> 
> 
> 
> 
>> On 23/05/2018 17:55, Tobias Gierke wrote:
>> Hi,
>> 
>> I'm in the process of migrating our application from Wicket 7.10 to Wicket 8 
>> and encountered some weirdness with regards to header contributions.
>> 
>> Our application has a top-level WebPage that defines a 
>> HeaderResponseContainerat the very end of the page markup and all other 
>> application pages inherit from it. We have a few header items that need to 
>> be rendered in their own section at the bottom of the page so I basically 
>> took the approach outlined in 
>> http://tomaszdziurko.com/2017/02/forcing-wicket-place-javascript-files-bottom/
>>  and adopted it to our needs.
>> 
>> Our Application#init() method does this:
>> 
>> ---final IHeaderResponseDecorator 
>> headerResponseDecorator =new IHeaderResponseDecorator()
>>{
>>   @Override public IHeaderResponse decorate(IHeaderResponse response)
>>   {
>>  return new FilteringHeaderResponse(response);
>>   }
>>};
>>setHeaderResponseDecorator(headerResponseDecorator);
>> ---
>> 
>> And from inside Behavior#renderHead() we're doing
>> 
>> ---final OnDomReadyHeaderItem toWrap = 
>> OnDomReadyHeaderItem.forScript(script);
>> response.render(new FilteredHeaderItem(toWrap, "our-bucket" );
>> ---
>> 
>> This was working fine in Wicket 7.10 but with Wicket 8 the Wicket defeault 
>> Javascript files (wicket-event-jquery,wicket-ajax-jquery etc.) are no longer 
>> being included in the page so AJAX buttons etc. fail with "TypeError: 
>> Wicket.Event is undefined" etc.
>> 
>> Wrapping the FilteringHeaderResponse inside a ResourceAggregator like|| 
>> shown in the migration guide had no effect.
>> 
>> 
>> Thanks,
>> Tobias
>> 
>> 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 

-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Wicket 8 migration / header contributions question

[Andrea Del Bene]

Hi,

this should be caused by WICKET-6498. This issue has changed the 
behavior for HeaderResponseDecorator. You can find how to adapt your 
code in the migration guide or in the release note of Milestone 9:


https://wicket.apache.org/news/2018/02/17/wicket-8.0.0-M9-released.html




On 23/05/2018 17:55, Tobias Gierke wrote:

Hi,

I'm in the process of migrating our application from Wicket 7.10 to 
Wicket 8 and encountered some weirdness with regards to header 
contributions.


Our application has a top-level WebPage that defines a 
HeaderResponseContainerat the very end of the page markup and all 
other application pages inherit from it. We have a few header items 
that need to be rendered in their own section at the bottom of the 
page so I basically took the approach outlined in 
http://tomaszdziurko.com/2017/02/forcing-wicket-place-javascript-files-bottom/ 
and adopted it to our needs.


Our Application#init() method does this:

---final IHeaderResponseDecorator 
headerResponseDecorator =new IHeaderResponseDecorator()

   {
  @Override public IHeaderResponse decorate(IHeaderResponse response)
  {
 return new FilteringHeaderResponse(response);
  }
   };
   setHeaderResponseDecorator(headerResponseDecorator);
---

And from inside Behavior#renderHead() we're doing

---final OnDomReadyHeaderItem toWrap = 
OnDomReadyHeaderItem.forScript(script);

response.render(new FilteredHeaderItem(toWrap, "our-bucket" );
---

This was working fine in Wicket 7.10 but with Wicket 8 the Wicket 
defeault Javascript files (wicket-event-jquery,wicket-ajax-jquery 
etc.) are no longer being included in the page so AJAX buttons etc. 
fail with "TypeError: Wicket.Event is undefined" etc.


Wrapping the FilteringHeaderResponse inside a ResourceAggregator 
like|| shown in the migration guide had no effect.



Thanks,
Tobias





-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org