Re: Resolution of url() in ContextRelativeResourceReference

Am 08.10.2015 um 08:14 schrieb Dieter Tremel: > With a JavaScriptHeaderItem the slash makes no difference, only with > CssHeaderItem. Sorry, this is wrong, same problem with js. - To unsubscribe, e-mail: users-unsubscr...@wicket

Re: Resolution of url() in ContextRelativeResourceReference

Hi, I guess the problem is that you have a context path and the person who wrote the guide didn't have it. If there is no context path then "/style.css" and "style.css" would resolve to the same - the resource that is in the root of the app. If there is context path then the absolute url that the

Re: Wicket Ajax Debug error

Hi, They are not Wicket items. Whenever you press an Ajax submit button Wicket will try to collect the data (key=value) for the form elements and send them with Ajax. It breaks for some reason in your app. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Thu, Oct

Re: Wicket Ajax Debug error

You are correct. I eventually tracked it down to a changed method in our app layer. But it threw me that the Wicket Ajax Debug reported it instead of it manifesting as a plain old javascript error in firebug. Brian On Thu, Oct 8, 2015 at 6:01 AM, Martin Grigorov-4 [via Apache Wicket] < ml-node+

Re: Wicket Ajax Debug error

Wicket Ajax Debug try/catches the exception and just logs it. If the error is not caught then this stops the processing of everything. E.g. when Wicket processes Ajax response usually there are several components which have to be re-rendered, some JavaScript to be executed, etc. If any of them fail

Re: Resolution of url() in ContextRelativeResourceReference

Now I understand. Thank You Martin. Dieter Am 08.10.2015 um 12:08 schrieb Martin Grigorov: > Hi, > > I guess the problem is that you have a context path and the person who > wrote the guide didn't have it. > If there is no context path then "/style.css" and "style.css" would resolve > to the same

3rd Party jQuery component wants jquery-2.1.1 but Wicket uses jquery-1.11.3

Hi Guys, I would like to use a nice 3rd Party jQuery component in my new Wicket 7 project. However, the 3rd Party jQuery component requires jQuery version 2.1.1 whereas Wicket 7 appears to be using jQuery version 1.11.3. Is there any way to override the jQuery version for use with that particular

Re: 3rd Party jQuery component wants jquery-2.1.1 but Wicket uses jquery-1.11.3

Hi, See app.getJavaScriptLibrarySettings().setJQueryReference() Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Thu, Oct 8, 2015 at 8:12 PM, shetc wrote: > Hi Guys, > > I would like to use a nice 3rd Party jQuery component in my new Wicket 7 > project. However,

Re: 3rd Party jQuery component wants jquery-2.1.1 but Wicket uses jquery-1.11.3

Hi Martin, I was looking at How to check whether my custom version of the backing JavaScript library (jQuery) doesn't break Wicket internals somehow ?

Re: 3rd Party jQuery component wants jquery-2.1.1 but Wicket uses jquery-1.11.3

1) You can run Wicket JS tests to verify 2) 1.x is preferred because it supports IE 8 & 9. If you know that you don't need to support old IE then use 2.x Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Thu, Oct 8, 2015 at 9:06 PM, shetc wrote: > Hi Martin, > >

Re: 3rd Party jQuery component wants jquery-2.1.1 but Wicket uses jquery-1.11.3

I used a burning cross to kill off IE 8 and 9 here at work So that is good news for me as we are only supporting IE 10 and upwards. Thanks for your generous help, once again! -- View this message in context: http://apache-wicket.

2 different context paths using one single war file

I have developed a Wicket application (MyApplication.war), to be deployed on Apache + Tomcat. It can be invoked using: http://hostname//MyApplication The application has 2 bookmarkable pages: http://hostname/MyApplication/page1 http://hostname/MyApplication/page2 I'd like to make page2 also avail