Browser Back Button Support in ADF Application.

[Rakesh Kumar]

Hi All,

  We are developing a custom application for a Client of ours and we have developed the entire application using bounded taskflows and jsff page fragments. Now the customer is asking to support the Browser back button functionality and we are having some tough time convincing that this is not the correct way of navigating in ADF application, but he is not getting convinced.

  Want all your help in how to convince this to customer? Any Documentation which says, that the browser back button is not advisable in ADF application should be a good start, if it is from Oracle that would be great.

 

Thanks in Advance,
Rakesh.

[Sten Vesterli]

I've been there, know the feeling :-(

In order for the Back button to work, you need to build your whole application based on pages instead of page fragments. This is against the Oracle User Experience Patterns and Guidelines, which recommends the use of the UI Shell (based on page fragments). See http://www.oracle.com/webfolder/ux/applications/fusiongps/toptenux.htm

I use the home banking applications we have here in Denmark as examples of Rich Internet Applications. If you click the Back button in these applications, you are simply thrown out of the application with a security error. This has helped me convince customers that this is actually a common way for modern web applications to work.

Best regards

Sten Vesterli

[Hyangelo]

When I was still developing using ADF, I had a hard time being convinced myself. Why would it be "best practice" to break a basic browser functionality? And it isn't just the back button either. The UI Shell pattern also tends to break bookmarking and the refresh button. IMO, this is a design flaw of ADF and this is what I tell anyone who asks why their back button does not work on their ADF Web application unlike most other web pages.

On Tuesday, February 18, 2014 8:25:53 PM UTC-8, rakesh.adf wrote:

[John Flack]

To my way of thinking, this is not a flaw of ADF, but a flaw of the UI Shell pattern, which is why I don’t use it.  The real problem is that in HTTP there is no way for browsers to inform the server that the back button has been pressed.  Therefore, web applications must infer that the button was pressed.  ADF 11g (and I assume 12c) does a pretty good job of this and responding appropriately, as long as you are actually displaying a different page.

 

The trouble is that ADF does a lot with partial page refresh, so the page hasn’t really changed.  In UI Shell, and several other common UI patterns, most of the “pages” are actually  regions showing page fragments within the same page.  So the Back button goes back to the previous actual page, not the previously displayed fragment.  Not ADF’s fault – HTTP doesn’t TELL ADF that the user wanted to switch pages, so ADF doesn’t get a chance to respond properly.

 

To some extent, a change to the ADF rendering framework so that the server doesn’t need to get involved could help.  Or it could be that SPDY – Google’s open source replacement for HTTP, or something similar will be the solution.

[Brian Huff]

Seconded... you run into issues with the BACK button on ANY web application that uses AJAX. Now, ADF makes it very easy to use AJAX for everything, which of course is a double-edged sword.

Other frameworks do have "plugins" that force a re-sending of state data when the BACK button is pushed:

https://github.com/browserstate/history.js/

But these only work with HTML5, and a handful of frameworks (jQuery, MooTools, Prototype). It might be a good starting point for a History plugin to ADF to force the BACK button to work properly... but that's a whole project in itself.

--
--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
 
All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).
 
---
You received this message because you are subscribed to the Google Groups "ADF Enterprise Methodology Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adf-methodolo...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Brian 'Bex' Huff
Chief Software Architect
Bezzotech - THE Premier Oracle WebCenter Solution Provider
Email: b...@bezzotech.com
Mobile: +1.612.227.6057
Twitter: @bex

  

Designing a Content Management or Enterprise 2.0 strategy? This may help:
 http://bezzotech.com/library.html

[Blake Sullivan]

I assume that you wanted a history entry only when the main section of the UIShell changed.

-- Blake Sullivan

<image001.png>   <image002.png>

Designing a Content Management or Enterprise 2.0 strategy? This may help:
 http://bezzotech.com/library.html

[Paco van der Linden]

Actually, nothing in the browser prevents an AJAX application from supporting the back and forward button. I guess most of you are familiar with Gmail. Gmail has near perfect support for the back button and it is a prototypical AJAX application. In modern browsers you can even do it with beautiful URLs (without the #-sign): http://html5demos.com/history.

More recent frameworks fully support it, both client-side and server-side frameworks, and I am really happy they do. We have been building desktop-like applications in the web browser, completely breaking some of the basic principles of the web (including back-button support and bookmarkable URLs). That is a shame.

The UI Shell pattern is not designed for back-button support, but it could work, why not... if only ADF had support for it. ADF is not designed with this in mind and I am afraid that is something that is not easily fixed (if at all possible).

I believe that modern frameworks show it is very well possible and even desirable, so perhaps in a future version? :-)

[blake.sullivan]

Your design flaw, my enhancement request :)

We looked into this a few years ago and came up with a  proposal that looked something like this:

1) Add Java api to AfdFacesContext to mark this response as history generating

2) Generate new state tokens for history-generating responses

3) Add behavior tag for marking actions as history generating

4) Add region attribute to make navigating between fragments history generating

5) Look at whether controller transitions should have additional metadata marking the transition as history generating

Other times were made higher priority, so this was never implemented.

-- Blake Sullivan

[filip.h...@gmail.com]

Hi,

I would go for the simple explanation: do you have a website or an application?

A website is a bunch of webpages that are linked together.

An application is a bunch of pages that are integrated with each other.  It is not simply going from one page to another one.  

I now that this will not be enough, but instead of looking at what is not working, emphasise on the topics that work very well due to this behaviour. 

I like frameworks who are clear on what their purpose is.  The purpose of ADF is building applications, not websites.

Other frameworks are more in the building websites area, then in the building application area.

The question is perhaps: is the browser the best tool to present an application like ADF?  But this is a totally different discussion :-)

HTH

Filip Huysmans