Architecture - Expert Oracle Application Express - page 512

the tables, views, sequences, etc., that make up an application. Supporting objects also include a remove
script that can cleanly remove all objects that define your application.
To fully understand the APEX architecture, it is also important to understand the metadata
structures and how they are related. Simply put, an application is made up of pages. Pages are
comprised of regions, processes, dynamic actions, computations, and branches. Regions can contain
other regions, items and buttons. Applications also have authentication schemes, authorization
schemes, user interface templates, tabs, additional items and other attributes. All of this metadata is
stored in database tables. Database referential integrity and check constraints are fully leveraged to
insure the integrity of the application. For example, removing an application will remove the metadata
for that application as stored in 50 + tables.
Application Pages
Rendering a page is typically a call to the database procedure 'f' while passing an argument 'p'. Actually,
'f' is a public synonym for APEX_xxxxxx.f. The f stands for flows , which was the original name of
Application Express, and the p stands for page . The relative URL request f?p=100:1 is a request to render
page 1 of application 100. It would look something like the following:
http://myserver.mydomain.com/apex/f?p=100:1
When received by the mid tier, it will be turned into an anonymous PL/SQL block, conceptually:
begin
f(p=>'100:1');
end;
The APEX procedure 'f' will parse the colon-separated list of arguments passed to 'p' and then call
the procedure WWV FLOW.SHOW to orchestrate the rendering of the page. The application ID, 100 in our
example, is used to look up and fetch key application attributes from the metadata tables in real time for
each page (or partial page) request. To determine how to properly render a page, Application Express
will first check the authentication method defined at the application level. Pages identified as public
pages are exempted from authentication checks. If the page requires authentication, the authentication
scheme is invoked and checked.
Once the authentication is checked, the remaining page metadata can be fetched and rendered.
Authorization is managed by authorization schemes. An authorization can be applied at application
level or at a component level. An authorization is a check that either succeeds or fails. For example, an
application may wish to restrict access to a specific domain of users defined in a table. An authorization
scheme called “is valid user” could be created that simply checks to see if the current user is contained in
the table. For example:
select 1 from my valid users where user name = :app user
This named authorization scheme can be applied to an application to protect every page. It could be
applied to a specific page, or applied to a specific component on a page. Conditions are also provided for
page components. Conditions, if defined, are checked before rendering.
In our example the application and page attributes have been fetched, the application
authentication scheme has been passed, and now the generation of the page HTML can start. Each page
has an associated page template that defines the structure of the HTML page. The page template has
substitution strings—for example, #TITLE# , #REGION POSITION 01# , and #TAB CELLS# . The page's region
definitions are fetched from metadata and injected into the page template, thus building up a complete
web page. Listing 12-2 is a page template snippet that includes the #TITLE# substitution string.