Re: Single Page Applications (SPA), Wicket and the history ajax back issue
Hi Martin, many thanks for this - I will have a look (just got back from a trip hence delay!) On Sun, Jul 17, 2016 at 9:05 AM, Martin Grigorov wrote: > Hi, > > You might be also interested in Wicketstuff UrlFragment project ( > > https://github.com/wicketstuff/core/blob/723bf245a7a9619c670fa493d541fcd9feae92bd/urlfragment-parent/README.md > ) > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Sat, Jul 16, 2016 at 10:31 PM, Martin Grigorov > wrote: > > > Hi, > > > > Here is a small demo application: > > https://github.com/martin-g/blogs/tree/master/ajax-history > > It uses HTML5 History API directly, so it won't work on old Internet > > Explorers! > > If you need to support old IE, good luck finding a decent JS library. > > AFAIK https://github.com/browserstate/history.js is one of the best out > > there, but looking at the number of open issues and PRs I wouldn't use it > > in my applications. > > > > The demo application shows how to support Ajax history for "Ajax menu" > use > > case from the earlier mails in this thread. In the past I have used > > something similar for Ajax pagination functionality. > > The menu items show how to change the url's path, query string and/or > > fragment > > The impl just triggers the respective JS event on the respective Ajax > > component for the history event. The rest is normal Wicket Ajax request. > As > > noted in the previous mail by clicking the browser's back button you will > > not ask Wicket to load an old version of the page! From Wicket point of > > view the navigation in the page always goes forward! > > > > This implementation is not in Wicket itself because I am sure it is not > > generic enough for everyone's use cases (and because History API is not > > available in old IEs!). > > if you need help with a use case that doesn't work with this impl then > > please create a demo application and I'll try to help! > > If one day the implementation is generic enough it may land in Wicket! > > > > Have fun! > > > > Martin Grigorov > > Wicket Training and Consulting > > https://twitter.com/mtgrigorov > > > > On Wed, Jul 13, 2016 at 10:55 AM, Wayne W > > wrote: > > > >> Hi, > >> > >> On Thu, Jul 7, 2016 at 11:28 PM, Martin Grigorov < > >> martin.grigo...@gmail.com> > >> wrote: > >> > >> > Hi, > >> > > >> > It seems you use Wicket for several years now and you have no idea how > >> to > >> > use it! > >> > > >> > >> > >> Yes perhaps Martin, I do try but there's a lot too it. > >> > >> > >> > > >> > I have done this for a client of mine 4 years ago. > >> > And I have explained how to do it few times in the mailing lists. > >> > You could use HTML5 History API to manipulate the browser url on each > >> Ajax > >> > call. If you need to support old browsers (why?! almost no one does > >> these > >> > days) then you should use some JS library that falls back to using the > >> > location fragment/hash. > >> > The support of "back/forward" buttons is just registering an > >> > AjaxEventBehavior that listens for "popState"/"hashchange" event. > >> > > >> > > >> I did some extensive searching and only found a couple of threads about > >> this: > >> > >> > >> > http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-td4660502.html > >> > >> > >> The main issue seems that the page map is not updated (just overriden) > for > >> ajax requests from my reading before. I came to the conclusion trying to > >> get wicket to support the back button would be difficult and somewhat > >> hacky. It seems we'd end up with unknown behaviour and issues possibly > >> occurring and therefore too much of a risk. Hence this thread. > >> > >> > >> > >> > > >> > I will try to find time to write a blog article with a demo app at > >> > wicketinaction.com soon. > >> > > >> > > >> > >> That would be great. > >> > >> > >> > >> > >> > > >> > > >> > > > > >
Re: Single Page Applications (SPA), Wicket and the history ajax back issue
Hi, You might be also interested in Wicketstuff UrlFragment project ( https://github.com/wicketstuff/core/blob/723bf245a7a9619c670fa493d541fcd9feae92bd/urlfragment-parent/README.md ) Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Sat, Jul 16, 2016 at 10:31 PM, Martin Grigorov wrote: > Hi, > > Here is a small demo application: > https://github.com/martin-g/blogs/tree/master/ajax-history > It uses HTML5 History API directly, so it won't work on old Internet > Explorers! > If you need to support old IE, good luck finding a decent JS library. > AFAIK https://github.com/browserstate/history.js is one of the best out > there, but looking at the number of open issues and PRs I wouldn't use it > in my applications. > > The demo application shows how to support Ajax history for "Ajax menu" use > case from the earlier mails in this thread. In the past I have used > something similar for Ajax pagination functionality. > The menu items show how to change the url's path, query string and/or > fragment > The impl just triggers the respective JS event on the respective Ajax > component for the history event. The rest is normal Wicket Ajax request. As > noted in the previous mail by clicking the browser's back button you will > not ask Wicket to load an old version of the page! From Wicket point of > view the navigation in the page always goes forward! > > This implementation is not in Wicket itself because I am sure it is not > generic enough for everyone's use cases (and because History API is not > available in old IEs!). > if you need help with a use case that doesn't work with this impl then > please create a demo application and I'll try to help! > If one day the implementation is generic enough it may land in Wicket! > > Have fun! > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Wed, Jul 13, 2016 at 10:55 AM, Wayne W > wrote: > >> Hi, >> >> On Thu, Jul 7, 2016 at 11:28 PM, Martin Grigorov < >> martin.grigo...@gmail.com> >> wrote: >> >> > Hi, >> > >> > It seems you use Wicket for several years now and you have no idea how >> to >> > use it! >> > >> >> >> Yes perhaps Martin, I do try but there's a lot too it. >> >> >> > >> > I have done this for a client of mine 4 years ago. >> > And I have explained how to do it few times in the mailing lists. >> > You could use HTML5 History API to manipulate the browser url on each >> Ajax >> > call. If you need to support old browsers (why?! almost no one does >> these >> > days) then you should use some JS library that falls back to using the >> > location fragment/hash. >> > The support of "back/forward" buttons is just registering an >> > AjaxEventBehavior that listens for "popState"/"hashchange" event. >> > >> > >> I did some extensive searching and only found a couple of threads about >> this: >> >> >> http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-td4660502.html >> >> >> The main issue seems that the page map is not updated (just overriden) for >> ajax requests from my reading before. I came to the conclusion trying to >> get wicket to support the back button would be difficult and somewhat >> hacky. It seems we'd end up with unknown behaviour and issues possibly >> occurring and therefore too much of a risk. Hence this thread. >> >> >> >> > >> > I will try to find time to write a blog article with a demo app at >> > wicketinaction.com soon. >> > >> > >> >> That would be great. >> >> >> >> >> > >> > >> > >
Re: Single Page Applications (SPA), Wicket and the history ajax back issue
Hi, Here is a small demo application: https://github.com/martin-g/blogs/tree/master/ajax-history It uses HTML5 History API directly, so it won't work on old Internet Explorers! If you need to support old IE, good luck finding a decent JS library. AFAIK https://github.com/browserstate/history.js is one of the best out there, but looking at the number of open issues and PRs I wouldn't use it in my applications. The demo application shows how to support Ajax history for "Ajax menu" use case from the earlier mails in this thread. In the past I have used something similar for Ajax pagination functionality. The menu items show how to change the url's path, query string and/or fragment The impl just triggers the respective JS event on the respective Ajax component for the history event. The rest is normal Wicket Ajax request. As noted in the previous mail by clicking the browser's back button you will not ask Wicket to load an old version of the page! From Wicket point of view the navigation in the page always goes forward! This implementation is not in Wicket itself because I am sure it is not generic enough for everyone's use cases (and because History API is not available in old IEs!). if you need help with a use case that doesn't work with this impl then please create a demo application and I'll try to help! If one day the implementation is generic enough it may land in Wicket! Have fun! Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Wed, Jul 13, 2016 at 10:55 AM, Wayne W wrote: > Hi, > > On Thu, Jul 7, 2016 at 11:28 PM, Martin Grigorov < > martin.grigo...@gmail.com> > wrote: > > > Hi, > > > > It seems you use Wicket for several years now and you have no idea how to > > use it! > > > > > Yes perhaps Martin, I do try but there's a lot too it. > > > > > > I have done this for a client of mine 4 years ago. > > And I have explained how to do it few times in the mailing lists. > > You could use HTML5 History API to manipulate the browser url on each > Ajax > > call. If you need to support old browsers (why?! almost no one does these > > days) then you should use some JS library that falls back to using the > > location fragment/hash. > > The support of "back/forward" buttons is just registering an > > AjaxEventBehavior that listens for "popState"/"hashchange" event. > > > > > I did some extensive searching and only found a couple of threads about > this: > > > http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-td4660502.html > > > The main issue seems that the page map is not updated (just overriden) for > ajax requests from my reading before. I came to the conclusion trying to > get wicket to support the back button would be difficult and somewhat > hacky. It seems we'd end up with unknown behaviour and issues possibly > occurring and therefore too much of a risk. Hence this thread. > > > > > > > I will try to find time to write a blog article with a demo app at > > wicketinaction.com soon. > > > > > > That would be great. > > > > > > > > >
Re: Single Page Applications (SPA), Wicket and the history ajax back issue
Hi, On Thu, Jul 7, 2016 at 11:28 PM, Martin Grigorov wrote: > Hi, > > It seems you use Wicket for several years now and you have no idea how to > use it! > Yes perhaps Martin, I do try but there's a lot too it. > > I have done this for a client of mine 4 years ago. > And I have explained how to do it few times in the mailing lists. > You could use HTML5 History API to manipulate the browser url on each Ajax > call. If you need to support old browsers (why?! almost no one does these > days) then you should use some JS library that falls back to using the > location fragment/hash. > The support of "back/forward" buttons is just registering an > AjaxEventBehavior that listens for "popState"/"hashchange" event. > > I did some extensive searching and only found a couple of threads about this: http://apache-wicket.1842946.n4.nabble.com/Wicket7-History-API-support-for-navigable-AJAX-pages-components-td4660502.html The main issue seems that the page map is not updated (just overriden) for ajax requests from my reading before. I came to the conclusion trying to get wicket to support the back button would be difficult and somewhat hacky. It seems we'd end up with unknown behaviour and issues possibly occurring and therefore too much of a risk. Hence this thread. > > I will try to find time to write a blog article with a demo app at > wicketinaction.com soon. > > That would be great. > >
Re: Single Page Applications (SPA), Wicket and the history ajax back issue
> So you don't use Ajax because of missing back button support? > We have a feature request for that, but it didn't spark much interest: > > https://issues.apache.org/jira/browse/WICKET-5290 Yes in a lot of cases unfortunately. It confuses a lot of non tech users who are used to using the navigation back button - we did some user testing and a fair number of people still use it, from from a UX perspective its not great dropping it. I did't see that request unfortunately > > > Have fun > Sven > > > > On 07.07.2016 14:13, Wayne W wrote: > >> Hi Sven, >> >> of course: Ok so this is simplified somewhat: lets say we have 4 main tab >> areas of the application: Contacts, Files, Calendar, Tasks. When a user >> navigates from one area to the next we need to currently do a whole page >> refresh, where in fact all we really need to do is refresh a sub panel via >> ajax. This already is more 'old school' as I put it in the fact the user >> experiences the whole page refreshing rather than say a loading/spinner in >> the main panel. We want to make the web pp fell more 'app like' rather >> than >> a succession of web pages. Another example is say we are in the "File" tab >> and we want to drill down through some folders, at the moment we need to >> refresh the page if we want to support the back button rather than load >> via >> ajax. >> >> It just gives a much less slick experience as the page reloads visually, >> and there is more data sent over the wire - slower page loads. But >> ultimately it about the users impression of the app and feeling like an >> app >> rather than a bunch of pages. >> >> >> On Thu, Jul 7, 2016 at 1:01 PM, Sven Meier wrote: >> >> Hi, >>> >>> it would be interesting to hear what limitations you're fighting against. >>> As a server-side rendered framework Wicket surely isn't the new kid on >>> the >>> block, but I can't think of anything forcing your application to be 'old >>> school'. >>> >>> Can you be more specific? >>> >>> Sven >>> >>> >>> >>> Am 7. Juli 2016, 13:23, um 13:23, Wayne W >>> schrieb: >>> Hi, we're been using wicket for some time now and we have a very established application used by many clients. It is however feeling some what dated, due to the fact the we have to constantly reload pages to access different functionality/areas if the app. We use ajax fairly heavily within each functional area. The problem is we are starting to 'feel' old school and we're loosing out to the competition that are based on the lasted SPA type JS frameworks talking to APIs. They just feel more slick and more responsive. Doing some research it seems thats it not possible to transform our current wicket app into this form, mainly due to the issues around wicket ajax state storage and history URL support in older browsers. Is this something the Wicket is never going to to attempt to support? I cannot find anything around this subject. Having a huge investment in our Wicket based application, its going to be very very painful to move away from which we must do if we cannot keep up with the competition due to framework limitations. many thanks >>> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
RE: Single Page Applications (SPA), Wicket and the history ajax back issue
Hi. Even I am struggling with similar issues. A demo app would definitely go a long way in sorting this out. Regards, Anup -Original Message- From: Martin Grigorov [mailto:martin.grigo...@gmail.com] Sent: 08 July 2016 03:59 To: users@wicket.apache.org Subject: Re: Single Page Applications (SPA), Wicket and the history ajax back issue Hi, It seems you use Wicket for several years now and you have no idea how to use it! On Jul 7, 2016 3:13 PM, "Wayne W" wrote: > > Hi Sven, > > of course: Ok so this is simplified somewhat: lets say we have 4 main > tab areas of the application: Contacts, Files, Calendar, Tasks. When a > user navigates from one area to the next we need to currently do a > whole page refresh, where in fact all we really need to do is refresh > a sub panel via This is a no-brainer with Wicket Ajax. > ajax. This already is more 'old school' as I put it in the fact the > user experiences the whole page refreshing rather than say a > loading/spinner in the main panel. We want to make the web pp fell > more 'app like' rather than > a succession of web pages. Another example is say we are in the "File" > tab and we want to drill down through some folders, at the moment we > need to refresh the page if we want to support the back button rather > than load via > ajax. I have done this for a client of mine 4 years ago. And I have explained how to do it few times in the mailing lists. You could use HTML5 History API to manipulate the browser url on each Ajax call. If you need to support old browsers (why?! almost no one does these days) then you should use some JS library that falls back to using the location fragment/hash. The support of "back/forward" buttons is just registering an AjaxEventBehavior that listens for "popState"/"hashchange" event. > > It just gives a much less slick experience as the page reloads > visually, and there is more data sent over the wire - slower page > loads. But ultimately it about the users impression of the app and > feeling like an app > rather than a bunch of pages. I will try to find time to write a blog article with a demo app at wicketinaction.com soon. > > > On Thu, Jul 7, 2016 at 1:01 PM, Sven Meier wrote: > > > Hi, > > > > it would be interesting to hear what limitations you're fighting against. > > As a server-side rendered framework Wicket surely isn't the new kid > > on the > > block, but I can't think of anything forcing your application to be > > 'old school'. > > > > Can you be more specific? > > > > Sven > > > > > > > > Am 7. Juli 2016, 13:23, um 13:23, Wayne W > > > > schrieb: > > >Hi, > > > > > >we're been using wicket for some time now and we have a very > > >established application used by many clients. It is however feeling > > >some what dated, due to the fact the we have to constantly reload > > >pages to access different functionality/areas if the app. We use > > >ajax fairly heavily within each functional area. > > > > > >The problem is we are starting to 'feel' old school and we're > > >loosing out to the competition that are based on the lasted SPA > > >type JS frameworks talking to APIs. They just feel more slick and > > >more responsive. > > > > > >Doing some research it seems thats it not possible to transform our > > >current wicket app into this form, mainly due to the issues around > > >wicket ajax state storage and history URL support in older > > >browsers. > > > > > >Is this something the Wicket is never going to to attempt to > > >support? I cannot find anything around this subject. > > > > > >Having a huge investment in our Wicket based application, its going > > >to be very very painful to move away from which we must do if we > > >cannot keep up with the competition due to framework limitations. > > > > > >many thanks > > --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Single Page Applications (SPA), Wicket and the history ajax back issue
Hi, It seems you use Wicket for several years now and you have no idea how to use it! On Jul 7, 2016 3:13 PM, "Wayne W" wrote: > > Hi Sven, > > of course: Ok so this is simplified somewhat: lets say we have 4 main tab > areas of the application: Contacts, Files, Calendar, Tasks. When a user > navigates from one area to the next we need to currently do a whole page > refresh, where in fact all we really need to do is refresh a sub panel via This is a no-brainer with Wicket Ajax. > ajax. This already is more 'old school' as I put it in the fact the user > experiences the whole page refreshing rather than say a loading/spinner in > the main panel. We want to make the web pp fell more 'app like' rather than > a succession of web pages. Another example is say we are in the "File" tab > and we want to drill down through some folders, at the moment we need to > refresh the page if we want to support the back button rather than load via > ajax. I have done this for a client of mine 4 years ago. And I have explained how to do it few times in the mailing lists. You could use HTML5 History API to manipulate the browser url on each Ajax call. If you need to support old browsers (why?! almost no one does these days) then you should use some JS library that falls back to using the location fragment/hash. The support of "back/forward" buttons is just registering an AjaxEventBehavior that listens for "popState"/"hashchange" event. > > It just gives a much less slick experience as the page reloads visually, > and there is more data sent over the wire - slower page loads. But > ultimately it about the users impression of the app and feeling like an app > rather than a bunch of pages. I will try to find time to write a blog article with a demo app at wicketinaction.com soon. > > > On Thu, Jul 7, 2016 at 1:01 PM, Sven Meier wrote: > > > Hi, > > > > it would be interesting to hear what limitations you're fighting against. > > As a server-side rendered framework Wicket surely isn't the new kid on the > > block, but I can't think of anything forcing your application to be 'old > > school'. > > > > Can you be more specific? > > > > Sven > > > > > > > > Am 7. Juli 2016, 13:23, um 13:23, Wayne W > > schrieb: > > >Hi, > > > > > >we're been using wicket for some time now and we have a very > > >established > > >application used by many clients. It is however feeling some what > > >dated, > > >due to the fact the we have to constantly reload pages to access > > >different > > >functionality/areas if the app. We use ajax fairly heavily within each > > >functional area. > > > > > >The problem is we are starting to 'feel' old school and we're loosing > > >out > > >to the competition that are based on the lasted SPA type JS frameworks > > >talking to APIs. They just feel more slick and more responsive. > > > > > >Doing some research it seems thats it not possible to transform our > > >current > > >wicket app into this form, mainly due to the issues around wicket ajax > > >state storage and history URL support in older browsers. > > > > > >Is this something the Wicket is never going to to attempt to support? I > > >cannot find anything around this subject. > > > > > >Having a huge investment in our Wicket based application, its going to > > >be > > >very very painful to move away from which we must do if we cannot keep > > >up > > >with the competition due to framework limitations. > > > > > >many thanks > >
Re: Single Page Applications (SPA), Wicket and the history ajax back issue
Hi, > navigates from one area to the next we need to currently do a whole page refresh > drill down through some folders, at the moment we need to refresh the page both are common cases for Wicket's Ajax updates. > if we want to support the back button rather than load via ajax So you don't use Ajax because of missing back button support? We have a feature request for that, but it didn't spark much interest: https://issues.apache.org/jira/browse/WICKET-5290 Have fun Sven On 07.07.2016 14:13, Wayne W wrote: Hi Sven, of course: Ok so this is simplified somewhat: lets say we have 4 main tab areas of the application: Contacts, Files, Calendar, Tasks. When a user navigates from one area to the next we need to currently do a whole page refresh, where in fact all we really need to do is refresh a sub panel via ajax. This already is more 'old school' as I put it in the fact the user experiences the whole page refreshing rather than say a loading/spinner in the main panel. We want to make the web pp fell more 'app like' rather than a succession of web pages. Another example is say we are in the "File" tab and we want to drill down through some folders, at the moment we need to refresh the page if we want to support the back button rather than load via ajax. It just gives a much less slick experience as the page reloads visually, and there is more data sent over the wire - slower page loads. But ultimately it about the users impression of the app and feeling like an app rather than a bunch of pages. On Thu, Jul 7, 2016 at 1:01 PM, Sven Meier wrote: Hi, it would be interesting to hear what limitations you're fighting against. As a server-side rendered framework Wicket surely isn't the new kid on the block, but I can't think of anything forcing your application to be 'old school'. Can you be more specific? Sven Am 7. Juli 2016, 13:23, um 13:23, Wayne W schrieb: Hi, we're been using wicket for some time now and we have a very established application used by many clients. It is however feeling some what dated, due to the fact the we have to constantly reload pages to access different functionality/areas if the app. We use ajax fairly heavily within each functional area. The problem is we are starting to 'feel' old school and we're loosing out to the competition that are based on the lasted SPA type JS frameworks talking to APIs. They just feel more slick and more responsive. Doing some research it seems thats it not possible to transform our current wicket app into this form, mainly due to the issues around wicket ajax state storage and history URL support in older browsers. Is this something the Wicket is never going to to attempt to support? I cannot find anything around this subject. Having a huge investment in our Wicket based application, its going to be very very painful to move away from which we must do if we cannot keep up with the competition due to framework limitations. many thanks - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Single Page Applications (SPA), Wicket and the history ajax back issue
Hi Sven, of course: Ok so this is simplified somewhat: lets say we have 4 main tab areas of the application: Contacts, Files, Calendar, Tasks. When a user navigates from one area to the next we need to currently do a whole page refresh, where in fact all we really need to do is refresh a sub panel via ajax. This already is more 'old school' as I put it in the fact the user experiences the whole page refreshing rather than say a loading/spinner in the main panel. We want to make the web pp fell more 'app like' rather than a succession of web pages. Another example is say we are in the "File" tab and we want to drill down through some folders, at the moment we need to refresh the page if we want to support the back button rather than load via ajax. It just gives a much less slick experience as the page reloads visually, and there is more data sent over the wire - slower page loads. But ultimately it about the users impression of the app and feeling like an app rather than a bunch of pages. On Thu, Jul 7, 2016 at 1:01 PM, Sven Meier wrote: > Hi, > > it would be interesting to hear what limitations you're fighting against. > As a server-side rendered framework Wicket surely isn't the new kid on the > block, but I can't think of anything forcing your application to be 'old > school'. > > Can you be more specific? > > Sven > > > > Am 7. Juli 2016, 13:23, um 13:23, Wayne W > schrieb: > >Hi, > > > >we're been using wicket for some time now and we have a very > >established > >application used by many clients. It is however feeling some what > >dated, > >due to the fact the we have to constantly reload pages to access > >different > >functionality/areas if the app. We use ajax fairly heavily within each > >functional area. > > > >The problem is we are starting to 'feel' old school and we're loosing > >out > >to the competition that are based on the lasted SPA type JS frameworks > >talking to APIs. They just feel more slick and more responsive. > > > >Doing some research it seems thats it not possible to transform our > >current > >wicket app into this form, mainly due to the issues around wicket ajax > >state storage and history URL support in older browsers. > > > >Is this something the Wicket is never going to to attempt to support? I > >cannot find anything around this subject. > > > >Having a huge investment in our Wicket based application, its going to > >be > >very very painful to move away from which we must do if we cannot keep > >up > >with the competition due to framework limitations. > > > >many thanks >
Re: Single Page Applications (SPA), Wicket and the history ajax back issue
Hi, it would be interesting to hear what limitations you're fighting against. As a server-side rendered framework Wicket surely isn't the new kid on the block, but I can't think of anything forcing your application to be 'old school'. Can you be more specific? Sven Am 7. Juli 2016, 13:23, um 13:23, Wayne W schrieb: >Hi, > >we're been using wicket for some time now and we have a very >established >application used by many clients. It is however feeling some what >dated, >due to the fact the we have to constantly reload pages to access >different >functionality/areas if the app. We use ajax fairly heavily within each >functional area. > >The problem is we are starting to 'feel' old school and we're loosing >out >to the competition that are based on the lasted SPA type JS frameworks >talking to APIs. They just feel more slick and more responsive. > >Doing some research it seems thats it not possible to transform our >current >wicket app into this form, mainly due to the issues around wicket ajax >state storage and history URL support in older browsers. > >Is this something the Wicket is never going to to attempt to support? I >cannot find anything around this subject. > >Having a huge investment in our Wicket based application, its going to >be >very very painful to move away from which we must do if we cannot keep >up >with the competition due to framework limitations. > >many thanks
