Showing both APEX and ADF and giving the audience some inkling as to there similarities and their differences – what is the best way of doing that? Well, one way Dimitri, Michiel and I devised for our AMIS Query last Monday was: we (Dimitri as APEX expert and I as ADF developer) both develop an application based on the same database design. We take the same set of tables and a shared (though extremely brief) functional description as well as the same amount of time – say six hours – as a starting point. Then, during the session, we demonstrate two similar yet quite distinct applications and see how they compare.
Well, that is exactly what we did. Starting from a simple – and as it turned out somewhat flawed – database design, we both created an application that supports both the creation and management of surveys or on-line polls with different types (open and multiple choice) of questions, some basic reporting on the outcome of surveys that have been run, the creation of person-records for people responding to the surveys and finally the actual process of responding to a survey by answering the questions in that survey.
The database design we both had to work from is shown here (created in JDeveloper). The DDL script can be downloaded here: surveyDDL.txt.
In this post, I will show the two applications side by side. The screenshots for the APEX application are taken from Dimitri’s live demo, the ADF screenshots are from the application I run locally on my laptop, and that also can be downloaded at the end of this article. This article also contains an overview of the time bookkeeping, detailing how long Dimitri and I spent on our respective applications and particular features in them.
Creating new persons
After the person is created, we can get an overview of all persons in the system and choose one to edit on the same page we used for creating a new one.
For the creation of a Person, I have decided to not use the simple, plain, straightforward, easy to do form-page, but instead a Wizard. Creating the wizard is quite meaningless, given the small number of data elements to provide for a new person: it is just showing off the Wizard Capability:
This last page contains two extra pieces of functionality. One is a little AJAX style action: when the Gender is set to Female, the Year of Birth is immediately disabled (as we do not want to ask our female respondents to have to unveil their age):
Using the ADF declarative Partial Page Rendering features, this is an extremely simple piece of functionality to implement.
Also, when a birthdate is entered that is clearly incorrect, an validation error is presented:
After Finishing the wizard, the application presents the newly created Person record in a single Form page. We can inspect all we have done and make changes where necessary. Note that I implemented a deep link navigation from the end of the wizard to the Person Management form – ensuring that the correct person is queried before this page is displayed.
The Organization and Personal headers indicate what we call Regions. These are more meaningful when a record has dozens of properties and each region contains a subset of those. Regions can be stacked (with tabs to switch between them), displayed alongside each other or vertically ordered as is shown here. Changing the way the regions are presented is a declarative setting which can be performed in a manner of seconds.
The overview of all persons entered into our on-line survey system looks like this:
This page has a search area where the user can easily restrict the persons shown by entering filter criteria and pressing the Go button. Just like in the APEX application, records are paginated (showing them in batches of 10 records at a time) and can be sorted by clicking on any of the column headers. Also notice that this page has full support for editing and deleting records – that is a difference with the APEX application, though I am not sure whether APEX does not support this multi-record edit facility or Dimitri simply chose not to use it for the Persons page.
Responding to a Survey
The APEX application offers the current user a list of all surveys he has not yet taken:
The user selects the survey he or she wants to respond to and clicks on the Show Questions link. The questions are presented to the user, one question per page.
Also note how the application supports various types of questions: open (single line text/textarea) and multiple choice (dropdown, radio buttons and even checkboxes for multiple options for a single question).
At the end of the survey, an informative message is presented.
In the ADF application, the user presses the New Response button to start responding to a survey. The page displayed next allows the user to select a survey (currently, all surveys are shown, not just the surveys the user has not yet responded to; this is a limitation compared to the APEX application).
A few things to notice here:
- The field Timestamp of Re
sponse is set to the default value of today’s date
- The survey (through the title field) can be selected in two ways: either press the little search light (the List of Values icon) or enter the beginning of a title into the field, for example "AMIS". When you tab out of the field, the application will try to find all surveys whose title start with AMIS. If there is only one, that one is automatically selected and both the Title and the Description field are updated to reflect the selected survey. If there are none starting with AMIS or several, then the List of Values popup window is displayed and the user can select a survey from the list presented there.
- On the top of the page, I have added the Skin selector; this is a drop down element where the user can select one of seven different "skins". Each skin represents an appearance, a different combination of color-scheme, fonts, icons etc. used by the ADF Faces components to render HTML. Oracle provides all these skins and offers a mechanism to customize these or create completely new custom skins. As a result, not all ADF applications need to look alike.
The List of Values window looks like this:
When the user has started the Response and pressed the SAVE button, he is taken through the question & answers pages.
Note how the user does not see the progress indicator that Dimitri had included – a nice touch that should not be to hard to add in the ADF application. Instead, the user has navigation buttons and an indication of the total number of questions and the current question. The user can navigate to the previous question – not an option in the APEX application – or the next one, to the very first or the very last. Only when the user presses the Save button, will any data get saved to the database. This is another difference with the APEX application where after each answer, a record is saved to the database.
The ADF application does not have a proper Finish Survey page, like the APEX application.
Creating a New Survey and its Questions
The pages in the APEX application for creating a new survey – or maintaining an existing one – look like this:
To select the survey to maintain:
And the page for defining answers
– and possible multiple choice options:
an overview of the questions defined for a survey looks like this:
The page for creating the survey:
Creating questions is simply done by pressing the Add Row button. The table lists all questions defined so far. The question we want to edit can be opened within the table – this means that additional items will be shown for that particular question.
Now for another small piece of AJAX functionality: when we toggle the Style from Open to Multiple Choice, the page is immediately partially refreshed to display the box with answer options for the multiple choice question:
For example adding the days of the week:
An overview of all Summaries is shown like this in the ADF application. Only Surveys for which no Responses have been created can still be edited – as we do not allow surveys being changed while they are being conducted. By clicking on the title of a Survey, we can drill down to the edit page.
Summary of Survey Responses
Dimitri had made a start with the Reporting section the Survey application, but he had not gotten very far. The one report he had developed was a chart with an overview of the number of replies for all the questions in the selected survey. Note that this chart is automatically refreshed every few seconds to keep up with all surveys being responded to.
The ADF application has a little bit more functionality in terms of reporting on the Responses to Surveys. First of all, it gives a graphical overview of the number of responses to every survey:
We can select a specific Survey and drill down to the responses. In this case, we take a closer look at the Company Outing Poll.
On closer inspection it turns out I have thrown in a different style of charts – a 3D Pie Chart – only because it is so easy to do.
For numeric values, the summary also displays an average value (achieved by a CASE expression in the query for the underlying ViewObject and a dynamic rendered expression for the Average Value item).
Internationalization or National Language Support in ADF
One feature I could very easily add to the ADF application – because it is a feature of JHeadstart built on top of a standard function of JSF applications – is support for multiple languages in our application. Web application typically can be used by users with various nationalities and/or languages. The application can learn from either the browser’s locale setting or a user preference which language should be active. Boilerplate text such as prompts, titles, button labels, hint text and error messages should be displayed in the preferred language.
So far, we have seen the application in English. It is exceedingly simp
le to include a Language Switcher that allows us to change the langua
ge on the fly. Some of the boilerplate text is already available in multiple languages – a feature of JHeadstart.
However, for application specific text, we have to provide a translation ourselves, in so called resource bundles. In the latest release of JHeadstart there is an even more advanced option: we can allow users of the application to manage those resource bundles themselves. They can press the Record Page Text button, to get a list of all boilerplate text elements. After recording is complete, the button is changed to Change/Translate Page Text:
Pressing that button brings up a popup window that allows the user to actually change the text elements, for every supported language:
When we are done translating the text, we can press the OK button and return to the application. It will now have boilerplate text for Dutch, according to the translations we provided:
Dimitri and I both created detailed records of how we spent our time for developing these two applications. Below you will see those two summaries. It is interesting to note that both in APEX and in ADF/JHeadstart the main functionality is done pretty easily. Straightforward survey creation, person management, response entering and basic summary & reporting is done very rapidly – maybe even within two hours. Most of the time both Dimitri and I spent was consumed by special UI requirements – Dimitri changed the look & feel to a style similar to his company’s UI style; I spent quite some time on implementing the Rich Text Editor and some rather minor AJAX features. Functionality and look & feel outside the ordinary quickly takes up a lot of time – or at least compared to the quite impressive productivity we get for straightforward table-form presentation and edit, master-detail structure, search functionality and charting.
Dimitri’s Timesheet (a total of 6 hours and 5 minutes):
My ADF/JHeadstart time spending – a total of 5 hours and 17 minutes (and 60 lines of Java code):
The APEX application that Dimitri created can be seen in action here: http://apex.shellprompt.net/pls/apex/f?p=APEXADF .
The ADF Application can be downloaded: Survey.zip. Please copy adf-faces-impl.jar and jsf-impl.jar to the WEB-INF\lib directory before running the application. Also note that the Model project (ADF BC) expects a Connection called SurveyLocal that connects to a database schema that contains the Survey Database created from the DDL script in the Survey\Database\database directory in the zip-file.