You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Carlos Vara (JIRA)" <ji...@apache.org> on 2010/01/17 18:25:54 UTC
[jira] Created: (WICKET-2683) RFE: Back button functionality on
AJAX pages
RFE: Back button functionality on AJAX pages
--------------------------------------------
Key: WICKET-2683
URL: https://issues.apache.org/jira/browse/WICKET-2683
Project: Wicket
Issue Type: New Feature
Components: wicket
Affects Versions: 1.5-M1
Reporter: Carlos Vara
I've been investigating on how to implement this functionality in Wicket. It is very closely related to this issue: https://issues.apache.org/jira/browse/WICKET-271.
Bear in mind, I'm quite new to the framework, so some of the conclusions that I have arrived to may be wrong.
The idea:
Applications where there is lots of AJAX action concentrated on a single page will benefit greatly if the back button functionality worked as "expected". A quick example: a user clicks an AJAX link which changes some panel, when pressing back, the user would expect to see the prior version of the page with the older panel. See Gmail for a nice current implementation of this.
What is needed and what I have investigated so far:
- First, for the back button to work, a URL change is needed. To avoid the browser from reloading the page, the URL change would consist of adding some info after a hash (#). This technique is explained in more detail in here: http://ajaxpatterns.org/Unique_URLs (There is some compatibility problems with explorer, which in the worst case will just mean that no history would be recorded in explorer). A good implementation of this would be a Javascript callback from the server that indicates the page that it should change the parameters after the # to the provided ones.
- Wicket needs to perform AJAX versioning. I have checked that if an addStateChange is performed inside an AJAX behaviour Wicket creates a new AJAX version of the page, so this part seems to be covered.
- An URLCodingStrategy that retrieves a page with an specific Id+Version+Ajax version needs to be coded. I have done a simple working test and this seems doable. However, I haven't found methods in Wicket's API to retrieve a page specifying its Ajax version. To complete this implementation I have had to:
*Create a new method in Session: public final Page getPage(final String pageMapName, final String componentPath, final int versionNumber, final int ajaxNumber). By now my implementation is hard-coded to work with SecondLevelCachePageMap.
*And add an extra method: public Page get(int id, int versionNumber, int ajaxNumber) in SecondLevelCachePageMap. I haven't checked with other IPageMap implementations, but it worked fine with this one. I guess that for this to be implemented the relevant methods in IPageMap and Session would need to be added.
This strategy would be used in the Page's Javascript to retrieve the needed version. It CAN'T be used by the browser directly, as that would force a page reload (and you can't encode it like <url>.id.version#ajaxVersion because the ajaxVersion part won't be sent to the server).
- An extra URLCodingStrategy for the listener interfaces. Current implementation doesn't have information about the AJAX version of the page so it can't route a request to the correct version of a component. (I haven't investigated much into this though).
- An extra Javascript layer in the page, that is able to update the relevant links of components not in the target of the AJAX behaviour to point to the current AJAX version of the page. This functionality will be used when navigating "forward".
- Also, more Javascript in the page, that when navigating "back", would be able to restore the appropriate version of the page by parsing the page's URL and performing an AJAX request to the server (using the first URLCodingStrategy).
That's so far all what I have been able to investigate into this issue. I don't know if you see this kind of functionality to fit into Wicket, but in case you do and see this implementation doable I would be willing to assist with the coding if you wanted.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2683) RFE: Back button functionality on
AJAX pages
Posted by "Martin Grigorov (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12801445#action_12801445 ]
Martin Grigorov commented on WICKET-2683:
-----------------------------------------
Check https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/jquery-parent/jquery-examples/src/main/java/org/wicketstuff/jquery/ajaxbackbutton
> RFE: Back button functionality on AJAX pages
> --------------------------------------------
>
> Key: WICKET-2683
> URL: https://issues.apache.org/jira/browse/WICKET-2683
> Project: Wicket
> Issue Type: New Feature
> Components: wicket
> Affects Versions: 1.5-M1
> Reporter: Carlos Vara
>
> I've been investigating on how to implement this functionality in Wicket. It is very closely related to this issue: https://issues.apache.org/jira/browse/WICKET-271.
> Bear in mind, I'm quite new to the framework, so some of the conclusions that I have arrived to may be wrong.
> The idea:
> Applications where there is lots of AJAX action concentrated on a single page will benefit greatly if the back button functionality worked as "expected". A quick example: a user clicks an AJAX link which changes some panel, when pressing back, the user would expect to see the prior version of the page with the older panel. See Gmail for a nice current implementation of this.
> What is needed and what I have investigated so far:
> - First, for the back button to work, a URL change is needed. To avoid the browser from reloading the page, the URL change would consist of adding some info after a hash (#). This technique is explained in more detail in here: http://ajaxpatterns.org/Unique_URLs (There is some compatibility problems with explorer, which in the worst case will just mean that no history would be recorded in explorer). A good implementation of this would be a Javascript callback from the server that indicates the page that it should change the parameters after the # to the provided ones.
> - Wicket needs to perform AJAX versioning. I have checked that if an addStateChange is performed inside an AJAX behaviour Wicket creates a new AJAX version of the page, so this part seems to be covered.
> - An URLCodingStrategy that retrieves a page with an specific Id+Version+Ajax version needs to be coded. I have done a simple working test and this seems doable. However, I haven't found methods in Wicket's API to retrieve a page specifying its Ajax version. To complete this implementation I have had to:
> *Create a new method in Session: public final Page getPage(final String pageMapName, final String componentPath, final int versionNumber, final int ajaxNumber). By now my implementation is hard-coded to work with SecondLevelCachePageMap.
> *And add an extra method: public Page get(int id, int versionNumber, int ajaxNumber) in SecondLevelCachePageMap. I haven't checked with other IPageMap implementations, but it worked fine with this one. I guess that for this to be implemented the relevant methods in IPageMap and Session would need to be added.
> This strategy would be used in the Page's Javascript to retrieve the needed version. It CAN'T be used by the browser directly, as that would force a page reload (and you can't encode it like <url>.id.version#ajaxVersion because the ajaxVersion part won't be sent to the server).
> - An extra URLCodingStrategy for the listener interfaces. Current implementation doesn't have information about the AJAX version of the page so it can't route a request to the correct version of a component. (I haven't investigated much into this though).
> - An extra Javascript layer in the page, that is able to update the relevant links of components not in the target of the AJAX behaviour to point to the current AJAX version of the page. This functionality will be used when navigating "forward".
> - Also, more Javascript in the page, that when navigating "back", would be able to restore the appropriate version of the page by parsing the page's URL and performing an AJAX request to the server (using the first URLCodingStrategy).
> That's so far all what I have been able to investigate into this issue. I don't know if you see this kind of functionality to fit into Wicket, but in case you do and see this implementation doable I would be willing to assist with the coding if you wanted.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2683) RFE: Back button functionality on
AJAX pages
Posted by "Carlos Vara (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WICKET-2683?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12801452#action_12801452 ]
Carlos Vara commented on WICKET-2683:
-------------------------------------
Hi Martin,
I didn't know of that implementation, thanks for the link. However, taking a very quick look at it, it looks like it offloads the versioning problem to jquery, so I'm guessing if it would work in this case:
1- User performs some AJAX actions in the page.
2- User presses back a few times.
3- User then clicks another AJAX link, which has most of the page in the target. AFAIK, Wicket would retrieve the latest AJAX version of the page (no way of knowing that it should target another AJAX version) so the user will receive contents according to the status of the latest AJAX version, and not the one he is seeing in the browser after pressing back.
Of course, I may be overlooking something...
> RFE: Back button functionality on AJAX pages
> --------------------------------------------
>
> Key: WICKET-2683
> URL: https://issues.apache.org/jira/browse/WICKET-2683
> Project: Wicket
> Issue Type: New Feature
> Components: wicket
> Affects Versions: 1.5-M1
> Reporter: Carlos Vara
>
> I've been investigating on how to implement this functionality in Wicket. It is very closely related to this issue: https://issues.apache.org/jira/browse/WICKET-271.
> Bear in mind, I'm quite new to the framework, so some of the conclusions that I have arrived to may be wrong.
> The idea:
> Applications where there is lots of AJAX action concentrated on a single page will benefit greatly if the back button functionality worked as "expected". A quick example: a user clicks an AJAX link which changes some panel, when pressing back, the user would expect to see the prior version of the page with the older panel. See Gmail for a nice current implementation of this.
> What is needed and what I have investigated so far:
> - First, for the back button to work, a URL change is needed. To avoid the browser from reloading the page, the URL change would consist of adding some info after a hash (#). This technique is explained in more detail in here: http://ajaxpatterns.org/Unique_URLs (There is some compatibility problems with explorer, which in the worst case will just mean that no history would be recorded in explorer). A good implementation of this would be a Javascript callback from the server that indicates the page that it should change the parameters after the # to the provided ones.
> - Wicket needs to perform AJAX versioning. I have checked that if an addStateChange is performed inside an AJAX behaviour Wicket creates a new AJAX version of the page, so this part seems to be covered.
> - An URLCodingStrategy that retrieves a page with an specific Id+Version+Ajax version needs to be coded. I have done a simple working test and this seems doable. However, I haven't found methods in Wicket's API to retrieve a page specifying its Ajax version. To complete this implementation I have had to:
> *Create a new method in Session: public final Page getPage(final String pageMapName, final String componentPath, final int versionNumber, final int ajaxNumber). By now my implementation is hard-coded to work with SecondLevelCachePageMap.
> *And add an extra method: public Page get(int id, int versionNumber, int ajaxNumber) in SecondLevelCachePageMap. I haven't checked with other IPageMap implementations, but it worked fine with this one. I guess that for this to be implemented the relevant methods in IPageMap and Session would need to be added.
> This strategy would be used in the Page's Javascript to retrieve the needed version. It CAN'T be used by the browser directly, as that would force a page reload (and you can't encode it like <url>.id.version#ajaxVersion because the ajaxVersion part won't be sent to the server).
> - An extra URLCodingStrategy for the listener interfaces. Current implementation doesn't have information about the AJAX version of the page so it can't route a request to the correct version of a component. (I haven't investigated much into this though).
> - An extra Javascript layer in the page, that is able to update the relevant links of components not in the target of the AJAX behaviour to point to the current AJAX version of the page. This functionality will be used when navigating "forward".
> - Also, more Javascript in the page, that when navigating "back", would be able to restore the appropriate version of the page by parsing the page's URL and performing an AJAX request to the server (using the first URLCodingStrategy).
> That's so far all what I have been able to investigate into this issue. I don't know if you see this kind of functionality to fit into Wicket, but in case you do and see this implementation doable I would be willing to assist with the coding if you wanted.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.