OC4J or Oracle Containers for J2EE is a complete J2EE compliant environment that provides all the containers, APIs, and services that enable a J2EE product to run. It is actually a robust and minimal distribution of Oracle Application Server, developed entirely in Java. More about OC4J you can read here: What is OC4J? One particular use for this web server is APEX print server. APEX usually allows only two possible configurations for the report printing server: standard (we will use OC4J) and advanced which requires Oracle BI. And Oracle BI costs "just" a few thousand dollars so… OC4J it is!
Prerequisites. Install Java2SE
We will demonstrate installing OC4J on a Linux Centos 5 machine.
Creating a RSS feed for you APEX application or website is actually quite simple, using the owa_util and wpg_docload Oracle packages. A RSS feed (Real Simple Syndication) is a method of exporting your website data into XML format containing a summarized text and metadata (author and date of creation). The RSS feed is usually public and can be accessed by other sites or web services through a URI, like http://localhost:8081/apex/rss.
The method described below can also be used to create a sitemap for your site.
Step 1. Create a procedure that generates the RSS feed
The name of the procedure or whether it is stored inside a package or not, is not important. Usually, you would want the RSS feed to contain the title of your website, a short description and the posts titles with hyperlinks to the actual location of posts. The procedure should look like this (inspired from Rick Murnanes' post):
This article describes the way that a dynamic branch can be created in an Apex page based on the value of an application or a page item. This can become very useful when, in an application, the next page is not known, as it can be any of the application pages, depending on a number of factors.
For example, let's consider the case of a product modeling application in which every product has a specific page. Therefore, after choosing the product, the application will branch to a different page for each of the products.
A solution is to create multiple branches to each product specific page, based on the product condition. But the best solution is to set the value of an item to the number of the next page depending on the chosen product. And afterwards create a branch who's target is not a specified page of the application, but given by the value of the item.
By default, Oracle XE comes with Embedded PLSQL Gateway (EPG) web server and the default port for APEX is 8080. To change that to port 80, use the following steps.
Step 1. Chage the owner of tnslsnr folder
As root, execute:
$ chown root:root $ORACLE_HOME/bin/tnslsnr
Step 2. Modify LISTENER.ORA
Add this to your LISTENER.ora (located in $ORACLE_HOME\NETWORK\ADMIN):
(ADDRESS = (PROTOCOL = TCP)(HOST = hostname)(PORT = 80))
(PROTOCOL_STACK = (PRESENTATION = HTTP) (SESSION = RAW))
This article describes the solution to the non-desirable case when a select list, text field or a radio button that submits the Apex page reloads the Apex page from the beginning of the page, instead of staying in the section of the item that submitted the page.
If an application has a more complex page, that has multiple items that stretch across more than one screen, then an item, select list, text field or radio button that submits the page will reload the page from the beginning, instead of staying on the recently modified item. This can be bothering, as it might determine the user to scroll down the page to get to the item that has been modified and that submitted the page. And of course, if the page has more items like this that need to submit the page and return to the same page, then having to scroll down every time after submiting a value can become more than annoying.
When working with Apex pages that contain a lot of items, one might observe that after adding a new page item, the page that until then was working just fine is no longer functioning, no request is being processed, no button works anymore, and when an action is triggered the page is redirected to a 404 type webpage.
Although it is not recommended to have too many items in a page, because of the fact that the page might be difficult to understand and it might work slower, there are cases when this is needed, when working with consistent forms that require multiple information to be filled in.
Importing whole applications vs. importing pages and components
This article describes the import of APEX pages and shared components. This operation is relevant when deploying modifications from the development environment to the production environment.
One of the most used and simple ways of transferring modifications to the APEX application into another environment is a complete recreation of the workspace and application. The steps are not subject of this document, but the major drawbacks from this method are:
– The workspace in the destination environment is deleted, along with all associated applications, and recreated
– The applications from the workspace need to be imported again, even if we only want to deploy only one of the applications from the previously deleted workspace
– All these operations take time and make the applications unavailable during the import
So, a simpler way is to apply modifications to an application stored in a different workspace, component by component and page by page, if the total number of new/modified pages or components is not close to the total number of components and pages in the application (in this case, a full application import will be more suitable).
The main concern and the scope of this document is importing pages or shared components from a development environment to a production environment. Usually, in the production mode we have all applications installed in runtime mode and the APEX installation itself does not have an Admin section, so all operations must be done using PLSQL and SQL scripts.
By default, APEX allows you to define a page title for each of you pages. This is done in the "Edit Page" section, the "Display Attributes" tab:
One of the minuses of the APEX framework (at least until Apex 4.0) is the lack of adding checkboxes to reports, whether SQL or Interactive Reports (further called IR). Even if there is a workaround to this problem, it becomes serious when working with a large amount of data and even more serious when trying to implement checkboxes in interactive reports.
Simple checkbox creation with APEX_ITEM
Fortunately, APEX provides us with an assist package: APEX_ITEM. This package provides us with an API for creating almost every kind of objects: select lists, radio buttons, radiogroup, textareas, date pickers and checkboxes.
Let’s create a simple table:
create table CHK_TEST(
Creating a checkbox is possible using the CHECKBOX function: