Once we identify a pattern and are certain it’s going to happen again, our code reuse mentality breaks loose. It’s only a matter of time until we end up with a shiny new tool in our code toolbox. This is especially true when we know that plugging in an existing piece of code can save us significant time and effort the next time around.
DILBERT © 1996 Scott Adams. Used By permission of UNIVERSAL UCLICK. All rights reserved.
The initial development of an ADF Standalone application is such a pattern primed for code reuse. I think anyone would agree that bootstrapping an ADF standalone application becomes a repetitive task. On the other hand agreeing that just performing the initial required setup to start the implementation of the actual project requirements can take significant time and effort might not be as clear.
Let’s go over the initial setup considerations of an ADF Standalone application at a high level to have a basic understanding of why it takes significant time and effort. Among the main goals of an ADF standalone application is to deliver an engaging user experience. There are a lot of aspects to consider when we create a user experience not only visual but also functional. To list a few:
- Consistent look and feel
- Layout design
- Effective user interfaces
- Usability
- Security
Security is an aspect that is often overlooked and underestimated. How to authenticate users with the corresponding login and logout functionality and how to authorize users to access only what they should among other things. From my experiences implementing these aspects I can vouch that it takes significant time and effort.
I must point out an additional benefit of bootstrapping your ADF standalone applications as clients themselves have asked for it. The benefit is standardization of ADF standalone application development within the organization.
The results that clients look from standardizing their ADF standalone application development within their organization are:
- Familiar user experience which leads to:
- Speeding up users’ acceptance of new applications
- User confidence
- Shared core functionality which leads to:
- Accelerating development of ADF standalone applications
- Speeding up knowledge transfers
- Easier understanding and maintenance of their code base
The following sections cover what I have found myself implementing over and over. Therefore, what I think should be part of the bootstrapping blueprint to develop ADF standalone applications.
1. User Experience:
There are different ways to achieve consistent look and feel, design layouts and create effective user interfaces. You can design and create your own layouts and styles but even when you do so, always keep in mind that code reuse still the way to go. Always try to reuse any templates and/or CSS’s that you create on your own across your pages whenever possible. Instead of designing and creating your own the other option and the one discussed here is the reuse of existing templates and or CSSs.
For this blog post and to continue the theme of code reuse I will recomend using Oracle’s Dynamic Tabs UI Shell temaplate. This UI Shell addresses ADF application user experience. Finally, wanted to point out the reasons to select the UI Shell to serve as the base for the base of the blueprints user experience:
- Designed by the Oracle user experience team
- Provides consistent look and feel
- Makes applications feel predictable
- User feels in control
- Enhances developer productivity
- Tested thoroughly
- Maintained by Oracle
- Expanded by Oracle
UI Shell’s official and very detailed documentation is a good resource to use.
Also, would like to highlight an Oracle Magazine article by Frank Nimphius and a video demo by Chris Muir with lots of insight.
2. Security:
Once you have selected or created the UI template to use the next step is to configure ADF Security on your standalone application. There is plenty of documentation on how to configure ADF Security, following its official documentation.
Also, would like to highlight an Oracle Magazine article by Frank Nimphius and a blog post by Edwin Biemond.
Finally, since this blog posts talks about reusing Oracle’s Dynamic Tabs UI Shell, the following blog explains how to configure ADF Security for it by Chris Muir.
Configuring ADF Security for the Dynamic Tabs UI Shell is straight forward. There is a gotcha to watch out for and that is, to make sure that the “blank” task flow is authorized as required. Step #5 of the previously mentioned blog post details how to authorize the “blank” task flow. The blank.xml did not show up on the jazn-data.xml Overview even after selecting “Show task flows from imported ADF libraries” as as instructed in Step #5. I had to add it manually from the Source view after finding in the server logs an error explicitly saying that the blank.xml had not being authorized.
2.1. Custom JSPX Login page
When ADF Security is configured by default it creates an .html page for the login page as seen on the left half of the screenshot below. Being an ADF developer I prefer the login page to be a .jspx page in order to leverage ADF components as seen on the right half of the screenshot below. Notice the components available from the Component Palette as expected only the .jspx page offers ADF Faces components.
Oracle’s official documentation provides a step by step how to, to create and use a .jspx page instead of the default .html page. The value added of this approach is that ADF developers can leverage their knowledge and use ADF Faces Components.
2.2. Logout functionality
After ADF Security is configured using its wizard there is no logout functionality configured out of the box. In order to implement the logout functionality backing bean will be used to terminate the session and re-direct the user to the login page.
Oracle’s official documentation on how to implement logout functionality is found here.
The 2 key things to keep in mind while implementing logout functionality are wiring up the Sign Out link in the Dynamic Tabs UI Shell to the backing bean method that performs the session termination and re-direct to login page. The following JDeveloper screenshots show how to implement these 2 keys.
3. Other Blueprint Components:
3.1 Session Timeout and Session Timeout Warning
Session timeout is configured by default in the web.xml to 35 minutes for ADF applications by JDeveloper. Usually changed to a much lower value as established by organizations policy for application running in Production environments. The session timeout is offered to the user in the form of a popup.
Offering a session timeout warning to users as their session is about to expire it’s a UI best practice. Unlike the session timeout its warning it’s not set by default to any values and sessions simply expire without any warning to the user. Similarly to the session timeout the warning is offered to the user in the form as a popup with a configurable message, both are documented here under “Configuration in web.xml” session.
3.3 Glasspane to Keep Happy Mouse Clicking Users at Bay
There are many instances where the UI will take longer time than users are willing to wait to complete a task before they re-click or click something else. Potential reasons could be a long running query, waiting for a process to complete or simply the network speed is not up to users’ expectations.
The article from ADF Code Corner by Frank Nimphius presents us an effective solution where a ‘glasspane’ it’s shown to the users with a splash screen.
Summary:
This blog has laid out a bootstrapping blueprint for the implementation of ADF standalone applications. Once you implement the blueprint you will have created a piece of code at your disposal to be reused on future projects to come. The blueprint contains the aspects I have found myself implementing over and over when starting ADF standalone projects.
From your implementation experiences you might have additional ideas for components that would make great candidates to be part of the blueprint as well. Please share which components you feel should be part of the blueprint in the comments below.
Happy coding!