One of the Oracle APEX characteristics that allows new users to get easily acquainted with the tool are the “Productivity Apps”. A “Productivity App” is a functional template of a web-application that Oracle provides to the APEX new, and not so new, developer users can create an application in a shorter time. They also allow users to learn how to use all different APEX functionalities and to test them. In this post we will make an overview of one of these “Productivity Apps”. We will analyse the “Sample Dialog” application.
We will now identify which are the main elements added to our workspace once we install this application.
In the DB we can see that several tables containing test data have been added, so the application is functional from the start.
Of course, we will be able to remove these tables from DB in the future, when we decided to add our own production tables. Also, at the time of uninstalling the application we will be asked if we wish to remove these tables from DB. Even thought this is not an obligation, is very advisable to do so, since we should always try to avoid to fill the DB with useless data and tables.
Also, we can see that an application have been added to our list of installed application. When accessing this new application we can see that it contains several pages, as shown bellow.
These pages have different types, depending on content and functionality:
- Home: This page is associated by default to the page number 1. We will be redirected to this page after log-in.
- Interactive Report: This page is constructed around a “report” or table. This report can be manipulated by final user of the installed application.
- Static HTML: This page just contains static HTML regions
- Report: This page contains a table that can not be manipulated by final user.
- Navigation Page: This page contains a URL list.
We also have the Form pages. These are pages created with self entity, even thought they can’t “exist” or be executed without being called from another page. Forms are normally used to request data from application users.
Data types are dynamic. That means that the application “reads” the content of the page and it adjusts page type to fit its content. We must take in account that it exist a hierarchy within types. This hierarchy decides that type it will be assigned to a page when it contains different types of regions. For example, a page containing static HTML regions and an interactive report, will prioritize the type “Interactive Report” over “Static HTML”.
This application also creates a set of elements that allows the application to give cohesion to application such us: navigation menus, authentication schemes… That we will analyse in other posts.
Even thought the use of the application may seem clear enough (show dialogs and forms examples), right now we are more interested in what exactly does the application and how it does that.
In the “Modal Dialog” page, apart from an interactive report, we can see that we can make a call of one of the previously explained forms, clicking on “Add department”.
This button will allow us to access the page “Create Department” contained in the list of pages.
Also we can see that the application also contains the page “Region Modal Dialog”. This page allows us to create forms without the need to be defined with self entity, but instead to be created within the same page it calls them.
This application allow us to experiment with the use of modal dialogs, but also creates a question that must be addressed: When should I use one instead the other? To give answer to this question we must take in account our own preferences, but still we must answer other questions before taking the decision of which one we must use.
- Do I want to create a dialog that will be only used on a single page, or it needs to be used by other pages? If the dialog is going to be used by several pages, we must create it with self entity
- How much is the complexity of the dialog I want to create? More complex dialogs usually require from a self entity meanwhile simpler dialogs can be easier handle as regions of another page.
- How much is the load of the elements of the page? Even thought this variable is difficult to quantify, is convenient not overload a page with elements, if not strictly necessary. Is not as much an efficiency issue but more a developer usability issue.
- How many pages have I created already? For the same reason as previous question, is not convenient to create too many pages, when could it be avoided.
Even thought the most relevant question is without doubt the first one, is convenient to take in account the rest of them, in order to get an application as tidy and clear as possible. Also is convenient to give an answer to these question thinking in the future evolution of the application. That is, what changes and new functionalities are expected, and how they will affect or change the use of each created dialog.