Re: exemples are down

[Martin Grigorov]

Yes, this is known.

We work on the new hosting - a VM managed by Apache Infra.

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Wed, Oct 11, 2017 at 10:06 PM, Francois Meillet <
francois.meil...@gmail.com> wrote:

> Hi,
>
> https://examples8x.wicket.apache.org/app
> got 404
>
> https://examples7x.wicket.apache.org/app
> connection is not secure
>
> https://examples6x.wicket.apache.org/app
> connection is not secure
>
>
> François
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

RE: Wicket 8 GA for production

[Chris Colman]

Recently I mentioned Wicket to a product manager - and his reply indicated that 
he thought Wicket was for UI's but was actually a different programming 
language! I quickly pointed out that it's the SAME language as they've used 
forever - Java! And that's the point! You can build your domain model, business 
layer and UI - all in the same, awesome, typesafe, high performance language 
yet still make your UI rock as much as any Angular JS UI (without the 
productivity and maintenance hits that come with using JavaScript)
 
> -Original Message-
> From: Matthias Tonhäuser [mailto:scaronthe...@gmail.com]
> Sent: Thursday, 12 October 2017 5:42 AM
> To: users@wicket.apache.org
> Subject: Re: Wicket 8 GA for production
> 
> Hi,
> 
> I just started using Wicket recently and I quite like what I've seen so
> far. To me, it is superior to JSF because it let's you spend more time
> writing nice Java code instead of scratching your head whether the correct
> hmtl attribute is "render" or "reRender".
> 
> I do think Wicket has a marketing issue, too. When I asked 20 software
> developers on a local software conference, only one had heard about
> Wicket.
> And he thought, it was defunct.
> 
> Are there any introductory presentations (Englisch / German) one can use
> to
> help spread the word about Wicket?
> 
> Best
> 
> Matthias

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

exemples are down

[Francois Meillet]

Hi,

https://examples8x.wicket.apache.org/app 
got 404

https://examples7x.wicket.apache.org/app
connection is not secure

https://examples6x.wicket.apache.org/app
connection is not secure


François


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

Re: Wicket 8 GA for production

[Matthias Tonhäuser]

Hi,

I just started using Wicket recently and I quite like what I've seen so
far. To me, it is superior to JSF because it let's you spend more time
writing nice Java code instead of scratching your head whether the correct
hmtl attribute is "render" or "reRender".

I do think Wicket has a marketing issue, too. When I asked 20 software
developers on a local software conference, only one had heard about Wicket.
And he thought, it was defunct.

Are there any introductory presentations (Englisch / German) one can use to
help spread the word about Wicket?

Best

Matthias

Re: Wicket 8 GA for production

[Lon Varscsak]

I agree with this wholeheartedly…I was just having this discussion with my
boss yesterday.  I do not understand (mostly) this drive to push stateless
frameworks (client or server).  Obviously your framework needs to support
stateless as to not waste resources, but almost every application I write
is complex enough that without servers side state, I’d spend more time
trying to figure out how to store state.

It’s one of the things I loved about Apple’s WebObjects and one of the
reasons I’ve moved to Wicket over other more “popular” java frameworks.

-Lon

On Wed, Oct 11, 2017 at 3:35 AM, Andrea Del Bene 
wrote:

> Obviously I 101% agree :-). In addition to security issue I usually have to
> struggle against the "big lie" of modern front-end libs which is "if you
> follow us your application can be stateless". Non-trivial applications are
> never stateless. If you have some sort of login mechanism you application
> must handle a state somewhere! I've always seen these "modern" js
> applications suffering of performance issues because they have
> unconsciously  moved state to database and they end up over-stressing it
> because they want the application level to be "stateless". That's pure
> madness to me!

Re: back button difference 7.6.0, 7.7.0, 7.8.0 and 7.9.0?

[Rob Audenaerde]

As a follow up:

Is there a way to test the back-button (without firing up jetty and
resorting to selenium / htmlunit)?

btw: I know WicketTester has trimmed-down versions of certain components
(MockApplication(), MockPageManager etc).  Maybe there is an implementation
that keeps track of the pages so I might implement a MyWicketTester.back()?

Thanks!
-Rob

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

> Hi Rob,
>
> you're absolutely right: The issue's title should have been changed.
> I've missed the opportunity when I found the real error :(.
> Something to keep in mind for future changes!
>
> Sven
>
> Am 10. Oktober 2017 13:47:53 MESZ schrieb Rob Audenaerde <
> rob.audenae...@gmail.com>:
> >Hi Sven,
> >
> >Thanks for your reply!
> >
> >I was mistaken in believing 7.8.0 was still broken (perhaps not
> >cleaned-up
> >enough) and can confirm 7.8.0 fixes the issue.
> >
> >After reading it seems the title of the issue is slightly misleading
> >(as
> >you commented: This doesn't have anything to do with ModalWindow -
> >every
> >retrieval of previous pages from the page store fails:
> >)
> >
> >Maybe changing the title of the issue for the release notes is
> >something to
> >consider?
> >
> >Thanks,
> >-Rob
> >
> >On Tue, Oct 10, 2017 at 1:34 PM, Sven Meier  wrote:
> >
> >> That's WICKET-6387 probably.
> >>
> >> Regards
> >> Sven
> >>
> >> Am 10. Oktober 2017 12:04:33 MESZ schrieb Rob Audenaerde <
> >> rob.audenae...@gmail.com>:
> >> >Hi all,
> >> >
> >> >We upgraded some time ago from Wicket 7.6.0 to Wicket 7.7.0 and now
> >we
> >> >see
> >> >that that back-button behaves differently?
> >> >Before, pressing back would return the page with all the ajax
> >> >modifications. After it seems to return an entirely new page.
> >> >
> >> >I could not find anything in the release notes that indicates a
> >change
> >> >here.
> >> >
> >> >Am I missing something?
> >> >
> >> >btw. Wicket 7.8.0 also breaks it, but 7.9.0 seems to fix it?
> >> >
> >> >-Rob
> >>
>

RE: AjaxFormComponentUpdatingBehavior not triggering ListChoice model update in Firefox in Wicket 7.9.0

[Chris Colman]

Dang! I thought the app was doing a 

continueToOriginalDestination();

to return from the login page to the home page at "/" but it wasn't so there's 
no problem with continueToOriginalDestination().

It was actually doing a setResponse(new HomePage()); from a 
the LogonPage that had no @MountPath annotation.

So I think the issue is a non issue - should always be using 
continueToOriginalDestination() to return from a login page to the page that 
requested login.

The issue only seems to occur when browser hits the page mounted at "/" and 
then gets redirected to intercept page that has no mount path (so browser URL 
isn't changed) and then instead of returning using 
continueToOriginalDestination it does a direct setResponse(new HomePage()); to 
go the page mounted at "/".

Only in that scenario does the form action attribute end up with ..? which 
FireFox doesn't seem to handle.

So by specifying a mount path for the login page or by using (the proper 
approach) continueToOriginalDestination() to return after intercept then the 
problem does not occur.

> -Original Message-
> From: Chris Colman [mailto:chr...@stepaheadsoftware.com]
> Sent: Wednesday, 11 October 2017 9:59 PM
> To: users@wicket.apache.org
> Subject: RE: AjaxFormComponentUpdatingBehavior not triggering ListChoice
> model update in Firefox in Wicket 7.9.0
> 
> Found it
> 
> It seems FireFox does have an issue with the actions that start with ..?
> 
> The page I was going to (localhost/myapp) had a mount path at "/"
> 
> i.e.
> 
> @MountPath(value = "/", alt = "/home")
> 
> Now this mount path annotation was also in the test app that didn't
> exhibit the problem but (yes!) but the main app has a test for
> authenticated user with redirect:
> 
> // redirect to authenticate page if we don't have an authenticated user
> redirectToInterceptPage(new AuthenticatePage());
> 
> The quickstart does not check for authentication so no redirect.
> 
> The problem goes away in Firefox if I change the mountpath to anything but
> "/" eg.,
> 
> @MountPath(value = "/blah", alt = "/home")
> 
> So my theory is that an action URL generated for a form in a page mounted
> at '/' is correct (./?) if the page is accessed directly without a
> redirectToInterceptPage.
> 
> but when the action URL is generated after a "continue after intercept" to
> a page that is mounted at '/' then the action URL is generated with the
> ..? prefix instead of ./?.
> 
> While Chrome can handle ..? it appears Firefox does not but works fine
> with ./?
> 
> 
> 
> > -Original Message-
> > From: Chris Colman [mailto:chr...@stepaheadsoftware.com]
> > Sent: Wednesday, 11 October 2017 9:29 PM
> > To: users@wicket.apache.org
> > Subject: RE: AjaxFormComponentUpdatingBehavior not triggering ListChoice
> > model update in Firefox in Wicket 7.9.0
> >
> > I found an interesting difference between the quickstart that works and
> > the app that doesn't work in FF:
> >
> > The action parameter of the form is generated with a .. prefix instead
> of
> > ./
> >
> > So in the app that doesn't work:
> >
> > The form's action attribute is defined as:
> >
> > action="..?32-1.IFormSubmitListener-form"
> >
> > and in the app that does work it is defined as:
> >
> > action="./?0-1.IFormSubmitListener-form"
> >
> > The AJAX event handlers defined at the end of the page correspond to
> > whatever was generated above.
> >
> > The ..? form is generated in both Chrome and FireFox. Perhaps Firefox
> > doesn't handle this ..? as well as Chrome does.
> >
> > Is ..? a legal URL path?
> >
> > To test this theory I could force the real app to generate a ./? URL
> > instead of ..?
> >
> > Any idea how I could do that?
> >
> >
> > > -Original Message-
> > > From: Korbinian Bachl [mailto:korbinian.ba...@whiskyworld.de]
> > > Sent: Wednesday, 11 October 2017 7:12 PM
> > > To: users@wicket.apache.org
> > > Subject: Re: AjaxFormComponentUpdatingBehavior not triggering
> ListChoice
> > > model update in Firefox in Wicket 7.9.0
> > >
> > > Is there any kind of defer or async on any of these JS script
> resources?
> > > Maybe you want to publish the quickstart?
> > >
> > > - Ursprüngliche Mail -
> > > > Von: "Chris Colman" 
> > > > An: users@wicket.apache.org
> > > > Gesendet: Mittwoch, 11. Oktober 2017 10:06:23
> > > > Betreff: RE: AjaxFormComponentUpdatingBehavior not triggering
> > ListChoice
> > > model update in Firefox in Wicket 7.9.0
> > >
> > > > The cut down app that works fine in FireFox also has both jquery.js
> > and
> > > > bootstrap.js so this probably means that it's ok to have both of
> these
> > > > together.
> > > >
> > > >
> > >
> >
> ./wicket/resource/org.apache.wicket.resource.JQueryResourceReference/jquer
> > > y/jquery-1.12.4.js
> > > >
> > > >
> > >
> >
> ./wicket/resource/de.agilecoders.wicket.webjars.request.resource.WebjarsJa
> > > vaScriptResourceReference/webjars/bootstrap/3.3.7-1/js/bootstrap.js
> > > >
> > > >
> > > >> -Original 

RE: AjaxFormComponentUpdatingBehavior not triggering ListChoice model update in Firefox in Wicket 7.9.0

[Chris Colman]

Found it

It seems FireFox does have an issue with the actions that start with ..? 

The page I was going to (localhost/myapp) had a mount path at "/"

i.e.

@MountPath(value = "/", alt = "/home")

Now this mount path annotation was also in the test app that didn't exhibit the 
problem but (yes!) but the main app has a test for authenticated user with 
redirect:

// redirect to authenticate page if we don't have an authenticated user
redirectToInterceptPage(new AuthenticatePage());

The quickstart does not check for authentication so no redirect.

The problem goes away in Firefox if I change the mountpath to anything but "/" 
eg.,

@MountPath(value = "/blah", alt = "/home")

So my theory is that an action URL generated for a form in a page mounted at 
'/' is correct (./?) if the page is accessed directly without a 
redirectToInterceptPage.

but when the action URL is generated after a "continue after intercept" to a 
page that is mounted at '/' then the action URL is generated with the ..? 
prefix instead of ./?.

While Chrome can handle ..? it appears Firefox does not but works fine with ./?



> -Original Message-
> From: Chris Colman [mailto:chr...@stepaheadsoftware.com]
> Sent: Wednesday, 11 October 2017 9:29 PM
> To: users@wicket.apache.org
> Subject: RE: AjaxFormComponentUpdatingBehavior not triggering ListChoice
> model update in Firefox in Wicket 7.9.0
> 
> I found an interesting difference between the quickstart that works and
> the app that doesn't work in FF:
> 
> The action parameter of the form is generated with a .. prefix instead of
> ./
> 
> So in the app that doesn't work:
> 
> The form's action attribute is defined as:
> 
> action="..?32-1.IFormSubmitListener-form"
> 
> and in the app that does work it is defined as:
> 
> action="./?0-1.IFormSubmitListener-form"
> 
> The AJAX event handlers defined at the end of the page correspond to
> whatever was generated above.
> 
> The ..? form is generated in both Chrome and FireFox. Perhaps Firefox
> doesn't handle this ..? as well as Chrome does.
> 
> Is ..? a legal URL path?
> 
> To test this theory I could force the real app to generate a ./? URL
> instead of ..?
> 
> Any idea how I could do that?
> 
> 
> > -Original Message-
> > From: Korbinian Bachl [mailto:korbinian.ba...@whiskyworld.de]
> > Sent: Wednesday, 11 October 2017 7:12 PM
> > To: users@wicket.apache.org
> > Subject: Re: AjaxFormComponentUpdatingBehavior not triggering ListChoice
> > model update in Firefox in Wicket 7.9.0
> >
> > Is there any kind of defer or async on any of these JS script resources?
> > Maybe you want to publish the quickstart?
> >
> > - Ursprüngliche Mail -
> > > Von: "Chris Colman" 
> > > An: users@wicket.apache.org
> > > Gesendet: Mittwoch, 11. Oktober 2017 10:06:23
> > > Betreff: RE: AjaxFormComponentUpdatingBehavior not triggering
> ListChoice
> > model update in Firefox in Wicket 7.9.0
> >
> > > The cut down app that works fine in FireFox also has both jquery.js
> and
> > > bootstrap.js so this probably means that it's ok to have both of these
> > > together.
> > >
> > >
> >
> ./wicket/resource/org.apache.wicket.resource.JQueryResourceReference/jquer
> > y/jquery-1.12.4.js
> > >
> > >
> >
> ./wicket/resource/de.agilecoders.wicket.webjars.request.resource.WebjarsJa
> > vaScriptResourceReference/webjars/bootstrap/3.3.7-1/js/bootstrap.js
> > >
> > >
> > >> -Original Message-
> > >> From: Korbinian Bachl [mailto:korbinian.ba...@whiskyworld.de]
> > >> Sent: Wednesday, 11 October 2017 6:44 PM
> > >> To: users@wicket.apache.org
> > >> Subject: Re: AjaxFormComponentUpdatingBehavior not triggering
> > ListChoice
> > >> model update in Firefox in Wicket 7.9.0
> > >>
> > >> Hi Chris,
> > >>
> > >> can it be that you have 2 instances of jQuery in your page? -
> > bootstrap.js
> > >> often comes with embedded jQuery and then you would overwrite the
> > wicket
> > >> one with the bootstrap one, that will lead to problems where you dont
> > get
> > >> notfied at all. I know this from foundation / sites, where you are
> best
> > >> using a second global variable beside the one from default jQuery.
> > >>
> > >> In this part wicket is a bit of a troublemaker, you could try to
> > replace
> > >> the wicket jQuery with an empty.js resource or even pull in the
> > bootstrap
> > >> one instead (e.g.: bootstrap script file instead of wickets jquery
> only
> > >> script), so only 1 jQuery gets executed. Also the migrate you use is
> > quite
> > >> old, I would suggest 1.4.1;
> > >>
> > >> Best,
> > >>
> > >> KB
> > >>
> > >>
> > >> - Ursprüngliche Mail -
> > >> > Von: "Chris Colman" 
> > >> > An: users@wicket.apache.org
> > >> > Gesendet: Mittwoch, 11. Oktober 2017 04:39:22
> > >> > Betreff: RE: AjaxFormComponentUpdatingBehavior not triggering
> > ListChoice
> > >> model update in Firefox in Wicket 7.9.0
> > >>
> > >> > I've made some progress. I have created a cut down app 

Re: Wicket 8 GA for production

[Andrea Del Bene]

On Wed, Oct 11, 2017 at 6:58 AM, Илья Нарыжный  wrote:

> Andrea,
>
> We would be happy to help with:
> 1) Translation of any articles/slides to russian and posting that on famous
> russian IT resources. If you have any articles even right now which worst
> to be translated: please send them to me.
>
2) A long with articles about Orienteer we can after switch to Wicket 8
> write some "lesson learned" about Wicket
>

It would be great! If you have some time to spare, you can pick one of my
published article to translate it: https://dzone.com/users/
748823/bitstorm.html


3) Performance: OMG, wickets performance is unbelievable. One company tried
> to test performance of our application (which powered by Wicket): finally
> they encountered into application server connection pool size, but response
> time was almost the same (around 15% less). Test was on 350 concurrent
> users with requests every second. That was amazing:)  30-70ms per page. So,
> I deviated: we have in mind to write article just about wicket performance.
>
>
Me and Martin (and maybe someone else?) have contributed to TechEmpower
Framework Benchmarks (http://frameworkbenchmarks.readthedocs.io/en/latest/)
to improve Wicket code and performance. They have recently closed my PR (
https://github.com/TechEmpower/FrameworkBenchmarks/pull/2929) which should
bring a notable improvement.


> More ideas:
> 1) T-Shirts. Just make design and allow people to order from printing
> company. Key point here: quality of the T-shirt.
> 2) Hackathons. If it will be nearby: will be happy to participate and help
> with sponsors.
> 3) More "Try-Me" demo sites. In era of Docker you can build even gallery of
> different open source apps which use wicket and make it available
> on-demand.
>
4) More articles with comparison: Wicket vs Vaadin, Backend or
> Frontend/Wicket vs Angular JS, vs JSF, Tapestry, Spring, etc.
>
> Guys, wicket has one extremely cool feature, which nobody else have: for
> 80% of needed technical features you can use either Wicket OOB or some
> library from the ecosystem, but (!!!) if you need something from the
> remaining 20% - wicket allow to do that for you! You can go as deep as you
> want/need: need to rearrange dynamically HTML elements? - no problem! Need
> to replace your textarea by some cool IDE on JavaScript? - easy! Need to
> receive client side errors and log them on server side? -  Just a little
> bit more of code:)
>
> One more observation: modern front-end libs are repeating some parts of
> wicket architecture/concept. You can find it in Angular, Vue, React and
> etc. But all frontend libs has big disadvantage which can not be fixed:
> security. It's impossible to enforce security just be frontend lib, you
> have to go to backend for that.
>

Obviously I 101% agree :-). In addition to security issue I usually have to
struggle against the "big lie" of modern front-end libs which is "if you
follow us your application can be stateless". Non-trivial applications are
never stateless. If you have some sort of login mechanism you application
must handle a state somewhere! I've always seen these "modern" js
applications suffering of performance issues because they have
unconsciously  moved state to database and they end up over-stressing it
because they want the application level to be "stateless". That's pure
madness to me!


>
> Thanks,
> Ilia
>
> On Tue, Oct 10, 2017 at 2:56 AM, Andrea Del Bene 
> wrote:
>
> > > And guys, you are doing incredible web-framework! Thank you for that.
> I'm
> > > quite surprised  that Wicket is not widely used:) Do you have some
> > > marketing difficulties?
> > > I personally expect that Wicket 8 release will be followed by some
> > > marketing events, articles and etc. Will be glad to participate in
> > > spreading this web-framework across the World.
> >
> > Unfortunately we have no marketing department :-). At the moment there's
> no
> > "Wicket company" that can do some kind of advertising. What I will
> > certainly do for Wicket 8 is publishing an article at dzone.com. I try
> to
> > write as many Wicket-related articles as possible on this site.
> > If you have any suggestion or advice they are warmly welcome!
> >
> >
> > On Tue, Oct 10, 2017 at 11:27 AM, Martin Grigorov 
> > wrote:
> >
> > > Hi,
> > >
> > > On Mon, Oct 9, 2017 at 9:40 PM, Илья Нарыжный  wrote:
> > >
> > > > Martin, Andrea, Maxim,
> > > >
> > > > Thank you all for your answers!
> > > >
> > > > GA version will be a gift for us for sure:) Yes - we can use Java 8
> > > source
> > > > level with Wicket 7, but we have some internal dependency for
> resolving
> > > of
> > > > which we need to invest some good amount of time.
> > > > Andrea, regarding my second question. It was about compatibility by
> > > > features between wicket 7 and wicket 8. Are there something missing
> in
> > > > Wicket  which is present in Wicket 7?
> > > > Maxim, you wrote about using of 

RE: AjaxFormComponentUpdatingBehavior not triggering ListChoice model update in Firefox in Wicket 7.9.0

[Chris Colman]

I found an interesting difference between the quickstart that works and the app 
that doesn't work in FF:

The action parameter of the form is generated with a .. prefix instead of  ./

So in the app that doesn't work:

The form's action attribute is defined as:

action="..?32-1.IFormSubmitListener-form"

and in the app that does work it is defined as:

action="./?0-1.IFormSubmitListener-form"

The AJAX event handlers defined at the end of the page correspond to whatever 
was generated above.

The ..? form is generated in both Chrome and FireFox. Perhaps Firefox doesn't 
handle this ..? as well as Chrome does.

Is ..? a legal URL path?

To test this theory I could force the real app to generate a ./? URL instead of 
..? 

Any idea how I could do that?


> -Original Message-
> From: Korbinian Bachl [mailto:korbinian.ba...@whiskyworld.de]
> Sent: Wednesday, 11 October 2017 7:12 PM
> To: users@wicket.apache.org
> Subject: Re: AjaxFormComponentUpdatingBehavior not triggering ListChoice
> model update in Firefox in Wicket 7.9.0
> 
> Is there any kind of defer or async on any of these JS script resources?
> Maybe you want to publish the quickstart?
> 
> - Ursprüngliche Mail -
> > Von: "Chris Colman" 
> > An: users@wicket.apache.org
> > Gesendet: Mittwoch, 11. Oktober 2017 10:06:23
> > Betreff: RE: AjaxFormComponentUpdatingBehavior not triggering ListChoice
> model update in Firefox in Wicket 7.9.0
> 
> > The cut down app that works fine in FireFox also has both jquery.js and
> > bootstrap.js so this probably means that it's ok to have both of these
> > together.
> >
> >
> ./wicket/resource/org.apache.wicket.resource.JQueryResourceReference/jquer
> y/jquery-1.12.4.js
> >
> >
> ./wicket/resource/de.agilecoders.wicket.webjars.request.resource.WebjarsJa
> vaScriptResourceReference/webjars/bootstrap/3.3.7-1/js/bootstrap.js
> >
> >
> >> -Original Message-
> >> From: Korbinian Bachl [mailto:korbinian.ba...@whiskyworld.de]
> >> Sent: Wednesday, 11 October 2017 6:44 PM
> >> To: users@wicket.apache.org
> >> Subject: Re: AjaxFormComponentUpdatingBehavior not triggering
> ListChoice
> >> model update in Firefox in Wicket 7.9.0
> >>
> >> Hi Chris,
> >>
> >> can it be that you have 2 instances of jQuery in your page? -
> bootstrap.js
> >> often comes with embedded jQuery and then you would overwrite the
> wicket
> >> one with the bootstrap one, that will lead to problems where you dont
> get
> >> notfied at all. I know this from foundation / sites, where you are best
> >> using a second global variable beside the one from default jQuery.
> >>
> >> In this part wicket is a bit of a troublemaker, you could try to
> replace
> >> the wicket jQuery with an empty.js resource or even pull in the
> bootstrap
> >> one instead (e.g.: bootstrap script file instead of wickets jquery only
> >> script), so only 1 jQuery gets executed. Also the migrate you use is
> quite
> >> old, I would suggest 1.4.1;
> >>
> >> Best,
> >>
> >> KB
> >>
> >>
> >> - Ursprüngliche Mail -
> >> > Von: "Chris Colman" 
> >> > An: users@wicket.apache.org
> >> > Gesendet: Mittwoch, 11. Oktober 2017 04:39:22
> >> > Betreff: RE: AjaxFormComponentUpdatingBehavior not triggering
> ListChoice
> >> model update in Firefox in Wicket 7.9.0
> >>
> >> > I've made some progress. I have created a cut down app that produces
> a
> >> > similar page to the troublesome one in the large app that exhibits
> the
> >> > problem - except I can't make the cut down app exhibit the problem
> yet
> >> > ;)
> >> >
> >> > ... but I have found a suble difference between the two apps:
> >> >
> >> > It seems to be something to do with the order/inclusion of .js files
> >> > added within a HeaderResponseContainer component.
> >> >
> >> > In the working app the .js is ordered like this:
> >> > (left out unimportant tags, paths etc., for brevity)
> >> >
> >> > src="... /jquery/jquery-1.12.4.js">
> >> > src="... /wicket-event-jquery.js">
> >> > src="... /wicket-ajax-jquery.js">
> >> > 
> >> > /* >> > Wicket.Ajax.baseUrl="";
> >> > /*]]>*/
> >> > 
> >> > 
> >> > src="... /jquery-migrate-1.3.0.js">
> >> > id="bootstrap-js" src="... /
> >> > webjars/bootstrap/3.3.7-1/js/bootstrap.js">
> >> > 
> >> > /* >> >
> >> > In the app that doesn't work in FireFox the .js ordering is:
> >> >
> >> > src="... /jquery/jquery-1.12.4.js">
> >> > src="... /wicket-event-jquery.js">
> >> > src="... /js/jquery-migrate-1.3.0.js">
> >> > src="... /webjars/bootstrap/3.3.7-1/js/bootstrap.js">
> >> > src="... /prettify.js">
> >> > 
> >> > 

RE: AjaxFormComponentUpdatingBehavior not triggering ListChoice model update in Firefox in Wicket 7.9.0

[Chris Colman]

I'm trying to create a quickstart but so far it doesn't reproduce the problem 
in the main app - all day I've been pulling in aspects of the main app in an 
attempt to replicate the exact scenario.

I have now managed to get the quickstart to produce JS in the same order that 
the main app does so the ordering isn't the issue.

All the .js files in the quickstart now match the .js files in the real app - 
yet the quickstarts works fine... must be something else other than .js files 
and there ordering.

I'll keep hunting ;)

> -Original Message-
> From: Korbinian Bachl [mailto:korbinian.ba...@whiskyworld.de]
> Sent: Wednesday, 11 October 2017 7:12 PM
> To: users@wicket.apache.org
> Subject: Re: AjaxFormComponentUpdatingBehavior not triggering ListChoice
> model update in Firefox in Wicket 7.9.0
> 
> Is there any kind of defer or async on any of these JS script resources?
> Maybe you want to publish the quickstart?
> 
> - Ursprüngliche Mail -
> > Von: "Chris Colman" 
> > An: users@wicket.apache.org
> > Gesendet: Mittwoch, 11. Oktober 2017 10:06:23
> > Betreff: RE: AjaxFormComponentUpdatingBehavior not triggering ListChoice
> model update in Firefox in Wicket 7.9.0
> 
> > The cut down app that works fine in FireFox also has both jquery.js and
> > bootstrap.js so this probably means that it's ok to have both of these
> > together.
> >
> >
> ./wicket/resource/org.apache.wicket.resource.JQueryResourceReference/jquer
> y/jquery-1.12.4.js
> >
> >
> ./wicket/resource/de.agilecoders.wicket.webjars.request.resource.WebjarsJa
> vaScriptResourceReference/webjars/bootstrap/3.3.7-1/js/bootstrap.js
> >
> >
> >> -Original Message-
> >> From: Korbinian Bachl [mailto:korbinian.ba...@whiskyworld.de]
> >> Sent: Wednesday, 11 October 2017 6:44 PM
> >> To: users@wicket.apache.org
> >> Subject: Re: AjaxFormComponentUpdatingBehavior not triggering
> ListChoice
> >> model update in Firefox in Wicket 7.9.0
> >>
> >> Hi Chris,
> >>
> >> can it be that you have 2 instances of jQuery in your page? -
> bootstrap.js
> >> often comes with embedded jQuery and then you would overwrite the
> wicket
> >> one with the bootstrap one, that will lead to problems where you dont
> get
> >> notfied at all. I know this from foundation / sites, where you are best
> >> using a second global variable beside the one from default jQuery.
> >>
> >> In this part wicket is a bit of a troublemaker, you could try to
> replace
> >> the wicket jQuery with an empty.js resource or even pull in the
> bootstrap
> >> one instead (e.g.: bootstrap script file instead of wickets jquery only
> >> script), so only 1 jQuery gets executed. Also the migrate you use is
> quite
> >> old, I would suggest 1.4.1;
> >>
> >> Best,
> >>
> >> KB
> >>
> >>
> >> - Ursprüngliche Mail -
> >> > Von: "Chris Colman" 
> >> > An: users@wicket.apache.org
> >> > Gesendet: Mittwoch, 11. Oktober 2017 04:39:22
> >> > Betreff: RE: AjaxFormComponentUpdatingBehavior not triggering
> ListChoice
> >> model update in Firefox in Wicket 7.9.0
> >>
> >> > I've made some progress. I have created a cut down app that produces
> a
> >> > similar page to the troublesome one in the large app that exhibits
> the
> >> > problem - except I can't make the cut down app exhibit the problem
> yet
> >> > ;)
> >> >
> >> > ... but I have found a suble difference between the two apps:
> >> >
> >> > It seems to be something to do with the order/inclusion of .js files
> >> > added within a HeaderResponseContainer component.
> >> >
> >> > In the working app the .js is ordered like this:
> >> > (left out unimportant tags, paths etc., for brevity)
> >> >
> >> > src="... /jquery/jquery-1.12.4.js">
> >> > src="... /wicket-event-jquery.js">
> >> > src="... /wicket-ajax-jquery.js">
> >> > 
> >> > /* >> > Wicket.Ajax.baseUrl="";
> >> > /*]]>*/
> >> > 
> >> > 
> >> > src="... /jquery-migrate-1.3.0.js">
> >> > id="bootstrap-js" src="... /
> >> > webjars/bootstrap/3.3.7-1/js/bootstrap.js">
> >> > 
> >> > /* >> >
> >> > In the app that doesn't work in FireFox the .js ordering is:
> >> >
> >> > src="... /jquery/jquery-1.12.4.js">
> >> > src="... /wicket-event-jquery.js">
> >> > src="... /js/jquery-migrate-1.3.0.js">
> >> > src="... /webjars/bootstrap/3.3.7-1/js/bootstrap.js">
> >> > src="... /prettify.js">
> >> > 
> >> > 

Re: AjaxFormComponentUpdatingBehavior not triggering ListChoice model update in Firefox in Wicket 7.9.0

[Korbinian Bachl]

Is there any kind of defer or async on any of these JS script resources? 
Maybe you want to publish the quickstart?

- Ursprüngliche Mail -
> Von: "Chris Colman" 
> An: users@wicket.apache.org
> Gesendet: Mittwoch, 11. Oktober 2017 10:06:23
> Betreff: RE: AjaxFormComponentUpdatingBehavior not triggering ListChoice 
> model update in Firefox in Wicket 7.9.0

> The cut down app that works fine in FireFox also has both jquery.js and
> bootstrap.js so this probably means that it's ok to have both of these
> together.
> 
> ./wicket/resource/org.apache.wicket.resource.JQueryResourceReference/jquery/jquery-1.12.4.js
> 
> ./wicket/resource/de.agilecoders.wicket.webjars.request.resource.WebjarsJavaScriptResourceReference/webjars/bootstrap/3.3.7-1/js/bootstrap.js
> 
> 
>> -Original Message-
>> From: Korbinian Bachl [mailto:korbinian.ba...@whiskyworld.de]
>> Sent: Wednesday, 11 October 2017 6:44 PM
>> To: users@wicket.apache.org
>> Subject: Re: AjaxFormComponentUpdatingBehavior not triggering ListChoice
>> model update in Firefox in Wicket 7.9.0
>> 
>> Hi Chris,
>> 
>> can it be that you have 2 instances of jQuery in your page? - bootstrap.js
>> often comes with embedded jQuery and then you would overwrite the wicket
>> one with the bootstrap one, that will lead to problems where you dont get
>> notfied at all. I know this from foundation / sites, where you are best
>> using a second global variable beside the one from default jQuery.
>> 
>> In this part wicket is a bit of a troublemaker, you could try to replace
>> the wicket jQuery with an empty.js resource or even pull in the bootstrap
>> one instead (e.g.: bootstrap script file instead of wickets jquery only
>> script), so only 1 jQuery gets executed. Also the migrate you use is quite
>> old, I would suggest 1.4.1;
>> 
>> Best,
>> 
>> KB
>> 
>> 
>> - Ursprüngliche Mail -
>> > Von: "Chris Colman" 
>> > An: users@wicket.apache.org
>> > Gesendet: Mittwoch, 11. Oktober 2017 04:39:22
>> > Betreff: RE: AjaxFormComponentUpdatingBehavior not triggering ListChoice
>> model update in Firefox in Wicket 7.9.0
>> 
>> > I've made some progress. I have created a cut down app that produces a
>> > similar page to the troublesome one in the large app that exhibits the
>> > problem - except I can't make the cut down app exhibit the problem yet
>> > ;)
>> >
>> > ... but I have found a suble difference between the two apps:
>> >
>> > It seems to be something to do with the order/inclusion of .js files
>> > added within a HeaderResponseContainer component.
>> >
>> > In the working app the .js is ordered like this:
>> > (left out unimportant tags, paths etc., for brevity)
>> >
>> > src="... /jquery/jquery-1.12.4.js">
>> > src="... /wicket-event-jquery.js">
>> > src="... /wicket-ajax-jquery.js">
>> > 
>> > /*> > Wicket.Ajax.baseUrl="";
>> > /*]]>*/
>> > 
>> > 
>> > src="... /jquery-migrate-1.3.0.js">
>> > id="bootstrap-js" src="... /
>> > webjars/bootstrap/3.3.7-1/js/bootstrap.js">
>> > 
>> > /*> >
>> > In the app that doesn't work in FireFox the .js ordering is:
>> >
>> > src="... /jquery/jquery-1.12.4.js">
>> > src="... /wicket-event-jquery.js">
>> > src="... /js/jquery-migrate-1.3.0.js">
>> > src="... /webjars/bootstrap/3.3.7-1/js/bootstrap.js">
>> > src="... /prettify.js">
>> > 
>> > 

RE: AjaxFormComponentUpdatingBehavior not triggering ListChoice model update in Firefox in Wicket 7.9.0

[Chris Colman]

The cut down app that works fine in FireFox also has both jquery.js and 
bootstrap.js so this probably means that it's ok to have both of these together.

./wicket/resource/org.apache.wicket.resource.JQueryResourceReference/jquery/jquery-1.12.4.js

./wicket/resource/de.agilecoders.wicket.webjars.request.resource.WebjarsJavaScriptResourceReference/webjars/bootstrap/3.3.7-1/js/bootstrap.js


> -Original Message-
> From: Korbinian Bachl [mailto:korbinian.ba...@whiskyworld.de]
> Sent: Wednesday, 11 October 2017 6:44 PM
> To: users@wicket.apache.org
> Subject: Re: AjaxFormComponentUpdatingBehavior not triggering ListChoice
> model update in Firefox in Wicket 7.9.0
> 
> Hi Chris,
> 
> can it be that you have 2 instances of jQuery in your page? - bootstrap.js
> often comes with embedded jQuery and then you would overwrite the wicket
> one with the bootstrap one, that will lead to problems where you dont get
> notfied at all. I know this from foundation / sites, where you are best
> using a second global variable beside the one from default jQuery.
> 
> In this part wicket is a bit of a troublemaker, you could try to replace
> the wicket jQuery with an empty.js resource or even pull in the bootstrap
> one instead (e.g.: bootstrap script file instead of wickets jquery only
> script), so only 1 jQuery gets executed. Also the migrate you use is quite
> old, I would suggest 1.4.1;
> 
> Best,
> 
> KB
> 
> 
> - Ursprüngliche Mail -
> > Von: "Chris Colman" 
> > An: users@wicket.apache.org
> > Gesendet: Mittwoch, 11. Oktober 2017 04:39:22
> > Betreff: RE: AjaxFormComponentUpdatingBehavior not triggering ListChoice
> model update in Firefox in Wicket 7.9.0
> 
> > I've made some progress. I have created a cut down app that produces a
> > similar page to the troublesome one in the large app that exhibits the
> > problem - except I can't make the cut down app exhibit the problem yet
> > ;)
> >
> > ... but I have found a suble difference between the two apps:
> >
> > It seems to be something to do with the order/inclusion of .js files
> > added within a HeaderResponseContainer component.
> >
> > In the working app the .js is ordered like this:
> > (left out unimportant tags, paths etc., for brevity)
> >
> > src="... /jquery/jquery-1.12.4.js">
> > src="... /wicket-event-jquery.js">
> > src="... /wicket-ajax-jquery.js">
> > 
> > /* > Wicket.Ajax.baseUrl="";
> > /*]]>*/
> > 
> > 
> > src="... /jquery-migrate-1.3.0.js">
> > id="bootstrap-js" src="... /
> > webjars/bootstrap/3.3.7-1/js/bootstrap.js">
> > 
> > /* >
> > In the app that doesn't work in FireFox the .js ordering is:
> >
> > src="... /jquery/jquery-1.12.4.js">
> > src="... /wicket-event-jquery.js">
> > src="... /js/jquery-migrate-1.3.0.js">
> > src="... /webjars/bootstrap/3.3.7-1/js/bootstrap.js">
> > src="... /prettify.js">
> > 
> > 

RE: AjaxFormComponentUpdatingBehavior not triggering ListChoice model update in Firefox in Wicket 7.9.0

[Chris Colman]

Thanks Korginian - I'll check out that theory.

All the JS included are done automatically by a combo of Wicket itself and the 
Wicket-Bootstrap project which I'm using in this app.

Is there an easy way to tell which component is contributing which .js to the 
"header" (which is actually in the footer as I'm using a 
HeaderResponseContaine)?

> -Original Message-
> From: Korbinian Bachl [mailto:korbinian.ba...@whiskyworld.de]
> Sent: Wednesday, 11 October 2017 6:44 PM
> To: users@wicket.apache.org
> Subject: Re: AjaxFormComponentUpdatingBehavior not triggering ListChoice
> model update in Firefox in Wicket 7.9.0
> 
> Hi Chris,
> 
> can it be that you have 2 instances of jQuery in your page? - bootstrap.js
> often comes with embedded jQuery and then you would overwrite the wicket
> one with the bootstrap one, that will lead to problems where you dont get
> notfied at all. I know this from foundation / sites, where you are best
> using a second global variable beside the one from default jQuery.
> 
> In this part wicket is a bit of a troublemaker, you could try to replace
> the wicket jQuery with an empty.js resource or even pull in the bootstrap
> one instead (e.g.: bootstrap script file instead of wickets jquery only
> script), so only 1 jQuery gets executed. Also the migrate you use is quite
> old, I would suggest 1.4.1;
> 
> Best,
> 
> KB
> 
> 
> - Ursprüngliche Mail -
> > Von: "Chris Colman" 
> > An: users@wicket.apache.org
> > Gesendet: Mittwoch, 11. Oktober 2017 04:39:22
> > Betreff: RE: AjaxFormComponentUpdatingBehavior not triggering ListChoice
> model update in Firefox in Wicket 7.9.0
> 
> > I've made some progress. I have created a cut down app that produces a
> > similar page to the troublesome one in the large app that exhibits the
> > problem - except I can't make the cut down app exhibit the problem yet
> > ;)
> >
> > ... but I have found a suble difference between the two apps:
> >
> > It seems to be something to do with the order/inclusion of .js files
> > added within a HeaderResponseContainer component.
> >
> > In the working app the .js is ordered like this:
> > (left out unimportant tags, paths etc., for brevity)
> >
> > src="... /jquery/jquery-1.12.4.js">
> > src="... /wicket-event-jquery.js">
> > src="... /wicket-ajax-jquery.js">
> > 
> > /* > Wicket.Ajax.baseUrl="";
> > /*]]>*/
> > 
> > 
> > src="... /jquery-migrate-1.3.0.js">
> > id="bootstrap-js" src="... /
> > webjars/bootstrap/3.3.7-1/js/bootstrap.js">
> > 
> > /* >
> > In the app that doesn't work in FireFox the .js ordering is:
> >
> > src="... /jquery/jquery-1.12.4.js">
> > src="... /wicket-event-jquery.js">
> > src="... /js/jquery-migrate-1.3.0.js">
> > src="... /webjars/bootstrap/3.3.7-1/js/bootstrap.js">
> > src="... /prettify.js">
> > 
> > 

Re: AjaxFormComponentUpdatingBehavior not triggering ListChoice model update in Firefox in Wicket 7.9.0

[Korbinian Bachl]

Hi Chris,

can it be that you have 2 instances of jQuery in your page? - bootstrap.js 
often comes with embedded jQuery and then you would overwrite the wicket one 
with the bootstrap one, that will lead to problems where you dont get notfied 
at all. I know this from foundation / sites, where you are best using a second 
global variable beside the one from default jQuery.

In this part wicket is a bit of a troublemaker, you could try to replace the 
wicket jQuery with an empty.js resource or even pull in the bootstrap one 
instead (e.g.: bootstrap script file instead of wickets jquery only script), so 
only 1 jQuery gets executed. Also the migrate you use is quite old, I would 
suggest 1.4.1;

Best,

KB


- Ursprüngliche Mail -
> Von: "Chris Colman" 
> An: users@wicket.apache.org
> Gesendet: Mittwoch, 11. Oktober 2017 04:39:22
> Betreff: RE: AjaxFormComponentUpdatingBehavior not triggering ListChoice 
> model update in Firefox in Wicket 7.9.0

> I've made some progress. I have created a cut down app that produces a
> similar page to the troublesome one in the large app that exhibits the
> problem - except I can't make the cut down app exhibit the problem yet
> ;)
> 
> ... but I have found a suble difference between the two apps:
> 
> It seems to be something to do with the order/inclusion of .js files
> added within a HeaderResponseContainer component.
> 
> In the working app the .js is ordered like this:
> (left out unimportant tags, paths etc., for brevity)
> 
> src="... /jquery/jquery-1.12.4.js">
> src="... /wicket-event-jquery.js">
> src="... /wicket-ajax-jquery.js">
> 
> /* Wicket.Ajax.baseUrl="";
> /*]]>*/
> 
> 
> src="... /jquery-migrate-1.3.0.js">
> id="bootstrap-js" src="... /
> webjars/bootstrap/3.3.7-1/js/bootstrap.js">
> 
> /* 
> In the app that doesn't work in FireFox the .js ordering is:
> 
> src="... /jquery/jquery-1.12.4.js">
> src="... /wicket-event-jquery.js">
> src="... /js/jquery-migrate-1.3.0.js">
> src="... /webjars/bootstrap/3.3.7-1/js/bootstrap.js">
> src="... /prettify.js">
> 
>