Re: wicket8 : wickets js/ jquery integration

[Martin Grigorov]

On Oct 7, 2017 23:23, "Sven Meier"  wrote:

Hi Korbinian,

using the "defer" attribute on script tags in the head section seems to be
best practice now:


The problem is that the ondomready scripts depend on jquery and wicket-xyz
ones and there is no way to defer them.


https://www.shivering-isles.com/the-science-of-loading-javascript/

Wicket supports the attribute since https://issues.apache.org/jira
/browse/WICKET-5715

Have fun
Sven



Am 07.10.2017 um 19:49 schrieb Korbinian Bachl:

> Hi,
>
> currently wicket renders all its jQuery and Ajax stuff right into the
> head, and I wonder why.
>   Current best practice seems to defer all javascript till the end of the
> page just right before the closing  tag to let the browser meanwhile
> get the DOM and do some work and not get blocked by loading resources. So
> wouldnt it maybe with wicket 8 be a good time to change this?
>
> e.g. Do
>
> 
> all the stuff
>
> 
> 
> ajax stuff...
> 
> 
>
> by default? and since mostly today jQuery is already on the page maybe
> even allow to apply a null at the 
> getJavaScriptLibrarySettings().setJQueryReference(null);
> to not have a wicket reference on it at all? Many webapps nowadays tend to
> only have 1 app.js that includes everything as its often build by tools
> like webpack.
>
> Would this be a good or bad idea?
>
> Best,
>
> Korbinian
>
> PS: in wicket 8 jquery 2.x is interchangable with jquery 3.x, am I right?
>
>

Re: wicket8 : wickets js/ jquery integration

[Sven Meier]

Hi Korbinian,

using the "defer" attribute on script tags in the head section seems to 
be best practice now:


https://www.shivering-isles.com/the-science-of-loading-javascript/

Wicket supports the attribute since 
https://issues.apache.org/jira/browse/WICKET-5715


Have fun
Sven


Am 07.10.2017 um 19:49 schrieb Korbinian Bachl:

Hi,

currently wicket renders all its jQuery and Ajax stuff right into the head, and 
I wonder why.
  
Current best practice seems to defer all javascript till the end of the page just right before the closing  tag to let the browser meanwhile get the DOM and do some work and not get blocked by loading resources. So wouldnt it maybe with wicket 8 be a good time to change this?


e.g. Do


all the stuff



ajax stuff...



by default? and since mostly today jQuery is already on the page maybe even 
allow to apply a null at the 
getJavaScriptLibrarySettings().setJQueryReference(null); to not have a wicket 
reference on it at all? Many webapps nowadays tend to only have 1 app.js that 
includes everything as its often build by tools like webpack.

Would this be a good or bad idea?

Best,

Korbinian

PS: in wicket 8 jquery 2.x is interchangable with jquery 3.x, am I right?

wicket8 : wickets js/ jquery integration

[Korbinian Bachl]

Hi,

currently wicket renders all its jQuery and Ajax stuff right into the head, and 
I wonder why.
 
Current best practice seems to defer all javascript till the end of the page 
just right before the closing  tag to let the browser meanwhile get the 
DOM and do some work and not get blocked by loading resources. So wouldnt it 
maybe with wicket 8 be a good time to change this?

e.g. Do 


all the stuff



ajax stuff...



by default? and since mostly today jQuery is already on the page maybe even 
allow to apply a null at the 
getJavaScriptLibrarySettings().setJQueryReference(null); to not have a wicket 
reference on it at all? Many webapps nowadays tend to only have 1 app.js that 
includes everything as its often build by tools like webpack.

Would this be a good or bad idea?

Best,

Korbinian

PS: in wicket 8 jquery 2.x is interchangable with jquery 3.x, am I right?

Re: WICKET-6105 and WicketStuff

[Sven Meier]

That's a plan!

Sven


Am 07.10.2017 um 18:16 schrieb Andrea Del Bene:

Sure we should! But I'd like not to break the build when we will merge
(hopefully soon) WICKET-6105. After we have merged it we will have all the
time to migrate the code to the new extensions module.

On Oct 7, 2017 5:32 PM, "Maxim Solodovnik"  wrote:


This make sense :)
I'll try to find some time and check some of these modules

On Sat, Oct 7, 2017 at 10:10 PM, Sven Meier  wrote:

Hi,

IMHO we should set a good example by migrating these modules to use the

new

classes in wicket-extensions.
We don't want to provide support for wicket-datetime forever, do we?

Regards
Sven



Am 07.10.2017 um 16:02 schrieb Andrea Del Bene:

Hi,

WicketStuff is currently depending on Wicket 'wicket-datetime' for three
subprojects:

- wicket-scala

- inmethod-grid

- wicketstuff-portlet-examples

I think we should replace it with the corresponding module we have
migrated to WicketStuff.

What do you think?




--
WBR
Maxim aka solomax

Re: WICKET-6105 and WicketStuff

[Andrea Del Bene]

Sure we should! But I'd like not to break the build when we will merge
(hopefully soon) WICKET-6105. After we have merged it we will have all the
time to migrate the code to the new extensions module.

On Oct 7, 2017 5:32 PM, "Maxim Solodovnik"  wrote:

> This make sense :)
> I'll try to find some time and check some of these modules
>
> On Sat, Oct 7, 2017 at 10:10 PM, Sven Meier  wrote:
> > Hi,
> >
> > IMHO we should set a good example by migrating these modules to use the
> new
> > classes in wicket-extensions.
> > We don't want to provide support for wicket-datetime forever, do we?
> >
> > Regards
> > Sven
> >
> >
> >
> > Am 07.10.2017 um 16:02 schrieb Andrea Del Bene:
> >>
> >> Hi,
> >>
> >> WicketStuff is currently depending on Wicket 'wicket-datetime' for three
> >> subprojects:
> >>
> >> - wicket-scala
> >>
> >> - inmethod-grid
> >>
> >> - wicketstuff-portlet-examples
> >>
> >> I think we should replace it with the corresponding module we have
> >> migrated to WicketStuff.
> >>
> >> What do you think?
> >>
> >
>
>
>
> --
> WBR
> Maxim aka solomax
>

Re: WICKET-6105 and WicketStuff

[Maxim Solodovnik]

This make sense :)
I'll try to find some time and check some of these modules

On Sat, Oct 7, 2017 at 10:10 PM, Sven Meier  wrote:
> Hi,
>
> IMHO we should set a good example by migrating these modules to use the new
> classes in wicket-extensions.
> We don't want to provide support for wicket-datetime forever, do we?
>
> Regards
> Sven
>
>
>
> Am 07.10.2017 um 16:02 schrieb Andrea Del Bene:
>>
>> Hi,
>>
>> WicketStuff is currently depending on Wicket 'wicket-datetime' for three
>> subprojects:
>>
>> - wicket-scala
>>
>> - inmethod-grid
>>
>> - wicketstuff-portlet-examples
>>
>> I think we should replace it with the corresponding module we have
>> migrated to WicketStuff.
>>
>> What do you think?
>>
>



-- 
WBR
Maxim aka solomax

Re: WICKET-6105 and WicketStuff

[Maxim Solodovnik]

+1
Thanks for checking!

On Sat, Oct 7, 2017 at 9:02 PM, Andrea Del Bene  wrote:
> Hi,
>
> WicketStuff is currently depending on Wicket 'wicket-datetime' for three
> subprojects:
>
> - wicket-scala
>
> - inmethod-grid
>
> - wicketstuff-portlet-examples
>
> I think we should replace it with the corresponding module we have migrated
> to WicketStuff.
>
> What do you think?
>



-- 
WBR
Maxim aka solomax

WICKET-6105 and WicketStuff

[Andrea Del Bene]

Hi,

WicketStuff is currently depending on Wicket 'wicket-datetime' for three 
subprojects:


- wicket-scala

- inmethod-grid

- wicketstuff-portlet-examples

I think we should replace it with the corresponding module we have 
migrated to WicketStuff.


What do you think?

[ANNOUNCE] WicketStuff 6.28.0 Released

[Maxim Solodovnik]

Joachim Rohde (1):
  Merge pull request #571 from jheek/feature/remove-double-markers

Jonathan Heek (2):
  don't add js code twice
  fix indentation

Konstantinos Karavitis (1):
  Merge pull request #591 from kkaravitis/wicket-6.x

Martin Tzvetanov Grigorov (4):
  Build against Wicket 6.27.0-SNAPSHOT
  [select2] Use JSONStringer (OpenJson) instead of JSONWriter (JSON2)
  [gmap3] Fix test assertion
  [jquery] Fix compilation by adding an import for o.a.w.Application

Maxim Solodovnik (4):
  More work on Issue #583: 6.x browserid module is removed
  JSONWriter is replaced with JSONStringer
  Tests are fixed
  Releasing 6.28.0

Sven Meier (1):
  issue #569 getObject's return might be a type variable

Vit Rozkovec (1):
  Use framework's JQuery reference (#598)

chrisly42 (1):
  Fix for Issue #570: InMethod-Grid: AbstractPageableView does not
allow resetting of total count (#576)

kkaravitis (1):
  fix for #588 issue: When invoking setResponsePage during an ajax
resource request the portlet doesn't redirect correctly

The WicketStuff team

Re: RedirectToUrlException seems to be broken in FF

[Maxim Solodovnik]

Here is the quick start: https://github.com/solomax/ajax-download

On Sat, Oct 7, 2017 at 12:40 PM, Maxim Solodovnik  wrote:
> Thanks for the clarifications Martin,
>
> According to [1] 'Ajax-Location' is being set instead of 'Location'
> (due to redirect happens on ajax button click)
> This works as expected in Chrome but fails in FF :(((
>
> Will continue debugging and will try to create quickstart
>
>
> [1] 
> https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/protocol/http/servlet/ServletWebResponse.java#L273
>
> On Fri, Oct 6, 2017 at 9:59 PM, Martin Grigorov  wrote:
>> Maybe I was not clear enough.
>> HttpServletResponse#sendRedirect() is supposed to set the Location header,
>> i.e. Tomcat/Jetty.
>>
>> The other status codes do it manually because #sendRedirect() would
>> override the status code.
>>
>> IMO you should ask at Tomcat forums why the Location is not being set.
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Fri, Oct 6, 2017 at 4:10 PM, Maxim Solodovnik 
>> wrote:
>>
>>> This code:
>>> https://github.com/apache/wicket/blob/master/wicket-
>>> request/src/main/java/org/apache/wicket/request/http/handler/
>>> RedirectRequestHandler.java
>>>
>>> Has special handling of moved temporary
>>>
>>> WBR, Maxim
>>> (from mobile, sorry for the typos)
>>>
>>> On Oct 6, 2017 20:05, "Maxim Solodovnik"  wrote:
>>>
>>> > The status is being set correctly, Location is not being set :(
>>> >
>>> > WBR, Maxim
>>> > (from mobile, sorry for the typos)
>>> >
>>> > On Oct 6, 2017 20:04, "Martin Grigorov"  wrote:
>>> >
>>> >> Hi,
>>> >>
>>> >> Isn't this something that the web container should do for us ?
>>> >>
>>> >> javax.servlet.http.HttpServletResponse#sendRedirect() sets the status
>>> to
>>> >> 302, that's the reason why the others do it "manually".
>>> >>
>>> >> Martin Grigorov
>>> >> Wicket Training and Consulting
>>> >> https://twitter.com/mtgrigorov
>>> >>
>>> >> On Fri, Oct 6, 2017 at 2:18 PM, Maxim Solodovnik 
>>> >> wrote:
>>> >>
>>> >> > Hello All,
>>> >> >
>>> >> > Recently I found RedirectToUrlException is not working in FF (works in
>>> >> > Chrome)
>>> >> > Redirect URL is being displayed for microsecond, then page is just
>>> >> > being refreshed
>>> >> >
>>> >> > What I found during debugging:
>>> >> > In case code is SC_MOVED_TEMPORARILY Location header is not set.
>>> >> >
>>> >> > FF site [1] clearly states Location should be set
>>> >> >
>>> >> > Tested on master branch.
>>> >> >
>>> >> > Should I prepare PR or this is done on purpose?
>>> >> >
>>> >> > [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/302
>>> >> >
>>> >> > --
>>> >> > WBR
>>> >> > Maxim aka solomax
>>> >> >
>>> >>
>>> >
>>>
>
>
>
> --
> WBR
> Maxim aka solomax



-- 
WBR
Maxim aka solomax