Hi there,
I'm doing something in my code similar to what you are suggesting.
The way I do it is basically, each page that I'm navigation to, I call a method
'cleverLink' rather than 'setResponsePage'.
'cleverLink' takes in a AjaxRequestTarget. That method then determines whether
the page is swappable - if it's not it just sets the ResponsePage as normal.
For the page to be swappable (in my code) the old page and the new page have to
have the same entity, and be of the same base page class. Otherwise, things
start breaking down! If the page has the same model, then I create the newPage,
using the existing pageParameters/model, and simply access each of the main
components using getters. Then, in the existing page, I replace (titlePanel,
mainPanel, actionPanel etc.). I then clone these objects using 'WicketObjects'
utility class (so as not to effect the 'new page') and 'replace' them in the
existing old page, marking each one for update via the ajax target.
I then use a javascript 'historyPush' event to push the new URL to the browser,
with the new Page ID from the new page (via getPageId() ), and the available
pageParameters (there is a Wicket class that is good at resolving
PageParameters - I can't remember what it is, and haven't my code to look it
up). In order to get the page URLs is actually a massive pain for Wicket,
especially if you us a combination of 'X', 'X/Y', 'X/Y/Z' paths. For this I
have a utility method in my WicketApplication class to hold a map of the paths,
created when mounting, for easy lookups. I still had problems with paths, and
resorted to only one level in the end, as it was easier and less error prone.
You'll need to add some code to redirect via javascript, on back button
presses, to the relevant page - but that is something there are plenty of
articles on the net about that. It's not very efficient (as a back button press
does a redirect), but it does work.
The net result is - each page has certain elements updated, and the URL is
always correct, the back button works as does bookmarking. It's non-trivial and
very specific to mine/your code, but it does work! Mine works on the basis that
I only replace certain panels of a page (and leave some) so it has limitations
when moving from one page, to another, with a different model and or base page.
Hope that is as clear as mud!
I'm sure this is breaking *something* in Wicket's standard model, so any ideas,
improvements or pointers are welcome!
Cheers,
Col.
From: Maxim Solodovnik [solomax...@gmail.com]
Sent: 26 August 2013 01:22
To: users@wicket.apache.org
Subject: Re: wicket single page application: replacing panels with ajax and
back button support
we did it in Apache Openmeetings project
https://svn.apache.org/repos/asf/openmeetings/trunk/singlewebapp/src/main/java/org/apache/openmeetings/web/
not sure if it can be used as an example :) but it is working :)
On Sun, Aug 25, 2013 at 5:54 PM, Ilkka Seppälä iluwa...@gmail.com wrote:
Hi,
I'm guessing this is a common way to use Wicket but could not find
solution.
I want to create a single page application where navigation causes panels
to be replaced with ajax. But the immediate problem that rises is how to
make these different views bookmarkable and how to make browser's back
button work as expected (return to previous view with the previous panel).
-Ilkka
--
WBR
Maxim aka solomax
EMAIL DISCLAIMER This email message and its attachments are confidential and
may also contain copyright or privileged material. If you are not the intended
recipient, you may not forward the email or disclose or use the information
contained in it. If you have received this email message in error, please
advise the sender immediately by replying to this email and delete the message
and any associated attachments. Any views, opinions, conclusions, advice or
statements expressed in this email message are those of the individual sender
and should not be relied upon as the considered view, opinion, conclusions,
advice or statement of this company except where the sender expressly, and with
authority, states them to be the considered view, opinion, conclusions, advice
or statement of this company. Every care is taken but we recommend that you
scan any attachments for viruses.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
