Disable Browser Navigation Buttons for ADF 12c Web Applications

Recently, we got a request that a customer wanted the browser navigation buttons disabled on his ADF 12c application. As we know, it is not possible to disable the buttons of the browser by default (unless you want to build your own private browser ;)). So we had to find another solution.

Hence ADF 12c comes with great HTML5 support, we found the solution in the javascript HTML5 history API. With it, it is possible to recreate the last entry of the browser history stack. The idea is fairly simple:

Browser pops the top stack element with the popstate event; we push the same element on top again, so that the user stays on the same page. Even the code is very short and easy to implement:

1. Create a <af:resource type="javascript"> tag on your page and add the following content:

function onPageEntry(){            

               //push the initial state first, to keep the current state named and referencable
                history.pushState(null, null, 'name-of-your-page');

               //if popstate is fired, add the push to the event queue
                window.addEventListener('popstate', function(event) {
                history.pushState(null, null, 'name-of-your-page');
                });
              }

2. create a client listener at document-on-load level, that references the javascript function:

<af:document title="PageTitle" id="d1">
   <... many more tags>
   <af:clientListener method="onPageEntry" type="load"/>
</af:document>

That's it. One might say, that this is a very crude way to "disable" the functionality, but as it is still possible to rightclick the buttons and navigate back to your older history, I think this is a nice safety-approach for ADF applications, that does not affect the browser in general.

Forms2ADF mal anders: Wie aus einer Oracle-Vision Praxis wird

Sollte der Film im letzten Post noch nicht detailliert genug beschrieben haben, wie eine Modernisierung von Forms zu ADF bei TEAM aussieht, so kann der Artikel

Forms2ADF mal anders: Wie aus einer Oracle-Vision Praxis wird

aus der aktuellen DOAG News weiterhelfen.

Dort beschreibt TEAM wie genau eine Modernisierung modellgetrieben durchgeführt werden sollte, um ein qualitativ hochwertiges und erweiterbares Ergebnis zu erzielen.

TEAM - Wir migrieren anders

So macht eine Forms-Anwendung wieder Spaß

Forms Migration Services - The clever way of Forms modernization

After several years of intensive research in cooperation with s-lab, a special interest group of the University of Paderborn supporting industrial partners in developing new technologies, TEAM proudly presents the Forms Migration Services – a process to take your Forms application to the next level using a model driven migration approach containing the TEAM Migration Assistant - a toolset for semi-automatic modernizations. Do the results justify all the effort? Yes, definitively!

In accordance with the objective to transform a Forms application into a maintainable ADF application, the project team initially followed the approach of a fully automated migration. This initial idea had to be revised, however, due to the technical differences between the two platforms Forms and ADF. A wider approach had to be taken in order to achieve appropriate/satisfactory results. Migrating a Forms application using a single blue print which transforms dialogue by dialogue and even generates a "Forms-Runtime" in ADF may represent a viable method to generate a running ADF application; however, this application would neither be maintainable nor would it offer any extension points to allow progression of the application. Thus it was obvious that a more sophisticated and abstract way of thinking was needed to solve the issues a 1:1 migration brings along.

Keeping that in mind, the project team, consisting of TEAM developers and s-lab members, developed a new approach to transforming and, at the same time, modernizing a Forms application into a “true” ADF application. A major challenge in this process was the fact that most Forms applications have been developed with a company specific Forms framework (i.e. functions and objects extending the original Oracle Forms framework). The new migration method is based on a multilevel modernization process. By using tools for source code analysis, knowledge and patterns for the specific Forms application are recognized and transformation rules can be established. These rules provide project specific patterns to the TEAM Migration Assistent which then generates the ADF application iteratively. Each iterative step is to be finished manually. After each step, our migration experts and the development team come together to discuss the lessons learned and whether or not recent development steps or code fragments can be automated in the next iteration step. This procedure ensures that the following iteration steps can be finished a lot quicker.

The Forms Migration Services offered by TEAM provide a novel integrated concept to modernize your Oracle Forms application to a "true" ADF application that is maintainable, great looking and enabled for future implementations!