APEX 5.0: Modal dialogs have never been so easy!

Like all of us, I have had the pleasure to take a look at APEX 5.0 EA1. One of the most anticipated features was build-in support for modal dialogs. In this blog we will examine this feature more closely.

An easy way to investigate this feature is by creating two simple pages: report & form using the wizard.

0Modaldialogs

Follow the wizard and base the report & form on the demo_customer table. When you come to the page where you are creating the form then you will notice the option “Page Mode”. This mode will determine the type of page you use.

1wizard

As you can see there are three modes:
-          Normal: used by normal pages
-          Modal: when this is selected your page will show as a modal dialog
-          Non – Modal:  in this mode the page will act as a normal pop-up allowing you to continue working in both windows. Note that the original window that called the pop-up can still interact with this pop – up

We select the modal mode, and continue the wizard. We have now created two pages with one being a modal dialog. So we see here that the modal dialog is a separate page, and not some region on the page that calls it. This will allow better re-usability, and easier validations. You might notice there is no code anywhere that actually calls the modal page. That is because any page that branches, links or redirects to a page with mode “Modal”, will call that page as a modal dialog automatically.

Apart from the mode difference between the two pages, APEX also created a “Close Dialog” process, and a dynamic action that fires when the cancel button is pressed on our modal page. Both of these will make sure our modal dialog is closed when the end-user presses a button.

2Close dialog

Lastly we might want our report to refresh when the dialog is closed. To do this we go to our report page and right click on our report to create a dynamic action. As event select “Dialog Closed” and region “Customers”.

3DA event4DA action

Then right click on your Dynamic action and create a Refresh action with affected item our Customers region. Now our Customers region will be refreshed when our modal dialog closes.

Time to test our page!

5Dialog

As you can see our modal dialog renders nicely.

There is one last note I would like to add, for the developers who like to write the code for their modal dialog themselves, the APEX developers have enabled us to do so. When you go to the theme for our modal page, then in the bottom you will notice these codes:

6Dialog init code

It basically means that, should you wish to, you can modify this code here, or just replace it with your own, allowing for maximum flexibility!

In conclusion I think it is safe to say that the APEX developers have done an ACE job implementing this feature, thumbs up! If you would like to try the EA and modal dialogs for yourself then you can do that here. If you want to read up on the full list of APEX EA1 features you can do that here.

Browser and Session value in APEX

For those of us who have been developing in APEX for a while will understand that the value of an item in APEX is not always what it seems. That’s right; an item has two values in APEX. The first value is the session value that we can store in the database (server side), the second value is the value the end user sees on his screen in the browser (client side). On some occasions these values are the same. On others they are not. The difference in value can lead to some confusion, especially for the new APEX developers.

Let’s start with an example so we understand the problem. This is actually based on a real use case. I changed the item names and queries to make it more universal, but the principle remains the same. The developer in question had a page with two Select lists containing the following queries:


SELECT 1 d, 1 r
FROM dual

And

SELECT 1 d, 1 r
FROM DUAL
UNION
SELECT 2 d, 2 r
FROM DUAL

The second select list (called P55_SELECT_LIST_2), also had a default value of 2.

When the user selects a different value on the select list then the second select list had to change values accordingly.

In order to achieve this the developer had created a Dynamic Action. As event he had a change Event of the P55_SELECT_LIST item. The first action was a set value containing the following query (again made simple for the example):

SELECT 1
FROM dual
WHERE  1 = :P55_SELECT_LIST

And page items to submit he had selected the item P55_SELECT_LIST, and affected items he put P55_SELECT_LIST_2

The last action he set was a refresh action of our P55_SELECT_LIST_2 item.

Our page setup now looks like this:

1pagesettup

The developer tried his application, and when he changed the first select list he saw the second select list being refreshed. Yet, instead of displaying the correct value (1), it displayed the default value.

2items

So what went wrong?

Let’s see what exactly happened to figure that out:

  1. The page was loaded. The first select list had nothing selected, the second select list had “2” selected in the browser. Both items were empty in the session3session
  2. The value of the first select list was changed by the end user
  3. This triggered the change event defined in the dynamic action
  4. The first action “Set value” was executed. The value in the browser was changed. The session value of the item P55_SELECT_LIST  was set to one, because it was set with items to submit. An AJAX request was made to set this value. The value item P55_SELECT_LIST_2 remains NULL.4session
  5. The refresh action was executed; an AJAX request was made to get new values for the select list. Since the SELECT_LIST_2 item has no value in the session, the default value is taken, which is 2!                                                                                                                          5network

The solution was simple. Just remove the refresh action. Then the value is set in the browser correctly.  This is handled by APEX with JavaScript/jQuery. The session value of the item will remain NULL until we submit the item to the database by a page submit, a dynamic action, or by changing the value in an AJAX Callback process.

AJAX in APEX

AJAX is becoming important in the world of web applications. APEX has provided us a very easy way to create an AJAX process, by using dynamic actions. Using PL/SQL Actions in Dynamic Actions to communicate with the database without submitting the page will suffice in most cases, but the downside is that the code is not very re-usable, and when you want to write a plug-in you simply don’t have access to Dynamic Actions. In this blog you will learn how to code your own AJAX process.

An AJAX process in APEX consists out of three parts

  • The JavaScript code that calls the AJAX PL/SQL Process
  • The PL/SQL Process that might or might not return a value
  • The JavaScript code that catches the return value and possibly does something with it

In APEX there are three ways to create an AJAX process from JavaScript:

  • The htmldb_get() method: undocumented but this used to be the only method available (without installing external libraries)
  • jQuery.ajax(): since jQuery was added to APEX, it has been quite common to use this method. It’s well documented on the jQuery homepage, but the downside is you need to write more code
  • apex.server: this new APEX API has been recently added (I believe at APEX 4.2). It is actually a wrapper of jQuery.ajax(), so it supports the same functionality with some additional APEX specific features. It is thoroughly documented in the APEX documentation, and this is the reason I prefer this method, and I will explain how you too can use it

The first thing we do is create a test application. In our case we have a table called “JOBS” that looks like this:

jobstable

In my jobs table I just inserted one job with a salary of 2800 of an unknown currency.

In our APEX application we have an Item of the type select list where the user can select a job, and then the minimum salary will be filled in.

Our page looks like this:

page

Next we write our JavaScript code.  This includes our change event and the apex.server.process . Double click your page name to go to the page definition, and scroll down to “Execute when page loads”.

javascript call

  • AJAX_GET_MIN_SALARY is the name of our future AJAX process.
  • X01 is the variable we pass, in this case the value of our #P17_JOB_ID item
  • Finally we declare that our expected return type is plain text. If we don’t do this, then by default the function expects a JSON string returned. Furthermore we declare in this function what we do with this return data. The return data will be delivered asynchronous, meaning we will get this data from our AJAX Callback function as soon as the AJAX Callback process is ready.

Now we can create our AJAX_GET_MIN_SALARY Ajax Callback process. Just right click on Ajax Callbacks . Click “Create” and select PL/SQL. Here we can put our PL/SQL code:

ajax_process

There are two things here that are worth mentioning:

  • TO_CHAR(apex_application.g_x01): this is how we catch the variable that is passed from our JavaScript code. We use TO_CHAR to identify that it’s a character.
  • HTP.Prn(v_min_salary): here we return the minimum salary back to our page

There, all done!  Let’s test out our application, shall we? Before you do anything it’s best to open the developer toolbar in the browser. In Chrome you can do this by pressing ctrl+shift+J.  It’s  a good practice to reload the page and to check if any JavaScript errors pop up on the console. If our JavaScript code shows no errors in the console go to the ‘Network’ tab, and select a job in the application.

items

You will now see www_flow.show appear. Click it. There are two tabs here that are vital to investigating this function for debugging, if needed. The first is the header, it shows what data is send to our AJAX Callback function.

toolbar

The second tab that’s important is our Response tab. It tells us what data is send back from the PL/SQL Process. If you remember our PL/SQL Process you will notice that we did not include an exception for when no data was found. Select “null” as job and you will get an error. If you then check out the response of the AJAX call you will see it gives our ORA error.

error

If you managed to read this far then you have gained some insights on how you can create your own AJAX function using the new APEX JavaScript API, how it works and how you can debug it should not everything go as planned.

Migrate your MS Access data to an Oracle database using the ETL Tool Talend

APEX is promoted as the perfect replacement for MS Access applications. One thing you should consider though is how you migrate your data to the Oracle database. In APEX there is a handy tool called the Data Workshop that can be used for this. You first export your Excel files from the MS Access database, and then follow the data upload wizard to import the data into identical tables. Since you are not always working with a 1-1 relationship, you will most likely have to write some PL/SQL to get all the data in the right tables.

dataworkshop

The downside is that you will need to repeat this process when you go into production. This is not a big problem if you only have one table to migrate. But if you have multiple tables and/ or your users also want new data during tests and trainings, you will spend a lot of time exporting and importing Excel files.

A recent APEX project for a client required a large data migration from MS Access Databases to the Oracle database. Because we would require fresh data on several points in the development process we decided to use the ETL Open Source Tool Talend. We got impressed of how intuitive the tool is, it only took a few days before we were familiar with the tool. Once you get the hang of it, you can write (or should I say draw) migrations of tables in no time. We needed to migrate from an MS Access database but the tool supports a wide range of databases and documents to import your data from. In total we migrated around 30-40 tables to our Oracle database.

Let’s have a closer look at one of our migration jobs.

talendmsaccessoracle

At the left we see our MS Access database. Each tAccessInput component will get data from one table. After that we join the tables in our tMap_1 component. The reason we don’t just write our joins in one component, is because this way we can really see how many rows every table returns.

On the bottom we have some Oracle Database input connections. They will join the persons of our MS Access Database with the persons in our Oracle Database based on the National registration number. After that we write our data to our Oracle Database. You may notice that we have two lines going to Excel files. This is our error logging; we use this to log the rows that did not find a match. In our first Excel for example we write persons that did not find a match in our Oracle Database.

This is just one example, in total about 20 jobs were built. During the development we also had to deal with certain calculations or convert data. For most things there was a component ready to use and if there wasn’t you could always write a Java expression in the tMap items.

I hope I convinced you of the benefits of using Talend as a migration tool for APEX projects, because we will certainly use this tool again!

Checkboxes in editable reports in APEX

We have all been there, we need to create an editable report and one of the columns contains a checkbox. So how should you handle this?

If you are using one of the recent APEX versions the easiest way is a tabular form. Just edit the column attributes of your checkbox column and at display as select “Simple Checkbox”. At the list of values definition type “Y,N”, where Y is the value the column will get when the checkbox is checked.

Tabular form checkbox

But what if you have multiple editable reports that have this requirement on one page? Then it starts to get interesting, since you can no longer use tabular forms.

With multiple editable reports we will be making our own editable report by using the API APEX_ITEM. You can read more about the APEX_ITEM API here.

We first create a report, and in our query we add our “active” column. We create two items there using the APEX_ITEM API: a checkbox and a hidden item. The parameter p_idx is the number  that apex uses to identify the items and write them in an APEX collection when the page is submitted. This has to be unique on the page. We set the value of both items to the id of the column. Why we need these will become clear later on.

SELECT APEX_ITEM.HIDDEN(p_idx =>1, p_value => id)

             ||APEX_ITEM.CHECKBOX(p_idx => 2, p_value => id , p_attributes => DECODE(active,’Y’,’checked=”checked”‘, NULL)) active

FROM MYTABLE

Next we go to report attributes, edit our active column and set display as Standard Report Column. This will allow APEX to render this properly.

Column attributes for APEX_ITEM API

Before we precede let me explain how checkboxes work. In HTML a checkbox that is not checked has no value it is considered NULL. This is something you will have noticed when you create a checkbox page item in APEX in a form. So if we loop over our APEX collection containing the checkboxes we will only loop over the checkboxes that have a value. This is no issue when you only need it to delete rows, but let me show you what happens if you try to use it to update rows. Let’s assume we have two columns, one contains our ID, and one contains our Checkbox with value Y.

APEX_ITEM.HIDDEN(p_idx => 1, p_value => id) APEX_ITEM.CHECKBOX(p_idx => 2, p_value => ‘Y’)
1 Checked
2 Not checked
3 Checked
4 Not checked

Assume we then loop over our first collection and do an update statement in our table:

FOR i in 1..APEX_APPLICATION.G_F01.COUNT LOOP

UPDATE MYTABLE SET active=NVL(APEX_APPLICATION07.G_F02(i),’N’)

WHERE id = APEX_APPLICATION.G_F01(i);

END LOOP;

Looks correct doesn’t it? Well it isn’t. When our process goes over the first row it will update correctly. When he tries to update the 2nd row he will update it wrongly to ‘Y’. And the 3rd row will give an error. That is because our 2nd APEX collection only contains two rows. It does not contain the rows that are not checked.

So now that I explained the problem let’s have a look at the solution.

DECLARE

l_yesno VARCHAR2(1);

TYPE t_checkboxes IS TABLE OF VARCHAR2(1);

l_checkboxes t_checkboxes := t_checkboxes();

BEGIN

FOR i IN 1..APEX_APPLICATION.G_F01.COUNT LOOP

FOR j IN  1..APEX_APPLICATION.G_F02.COUNT LOOP

IF APEX_APPLICATION.G_F01(i) = APEX_APPLICATION.G_F02(j) THEN

l_yesno := ‘Y’;

END IF;

END LOOP;

l_yesno := NVL(l_yesno,’N’);

l_checkboxes.EXTEND;

l_checkboxes(i) := l_yesno;

l_yesno := ‘N’;

END LOOP;

 

FORALL i IN INDICES OF APEX_APPLICATION.G_F01

UPDATE MYTABLE

SET ACTIVE = l_checkboxes(i)

WHERE id = APEX_APPLICATION.G_F01(i);

END;

We start by looping over our APEX collection containing our ID, inside that same loop we loop over the APEX collection with our checkboxes. Both contain as value our ID. If the values match, then the checkbox containing that ID has value ‘Y’. We insert this into a PL/SQL collection that we made for this purpose.

Lastly we do an update in our table, to set our new values. Notice how we only did one update statement using FORALL, and by doing so we limited our context switch to just one, and boosted our performance.

I now hope that everyone got a better idea of how they can deal with checkboxes rather easy, using only PL/SQL and APEX API’s.

OBUG CONNECT 2013: impressions from an APEX Developer

On 26 march I attended OBUG CONNECT 2013 at Kinepolis Antwerp. With around 40 sessions to pick from, picking out sessions was not an easy decision.

One session that caught the eye was the presentation about Formspider given by Yalim Gerger. While the presentation name and description did not reveal that the presentation was about Formspider, it was not hard to guess since it was given by its creator.

Yalim explained that since 2008 the landscape in the IT world changed. In 2008 developers developed for one platform, now there are many more platforms, all which require different programming skills. Yalim suggested using Formspider, a PL/SQL framework as an alternative. Formspider uses one javascript library maintained by “one” developer. This way only one developer needs to worry about security, browser compatibility and browser performance. On top of that developers only need to learn only one programming language: PL/SQL.

It must be said, Yalim made a strong case. Unfortunately we did not get the chance to see his framework in action, but it has to be said, if even a part of what he said is true, Formspider could become a strong player on the market.

Another interesting session was given by Patrick Hendrickx from Telenet. Telenet used APEX to Design some internal project management applications. He decided to go with APEX rather than buy a product or expand existing products.

He had some good arguments to do so:

-          APEX is Browser only technology

-          APEX is RAD

-          It has good and easy graph support

-          Wizard driven, so less programming skills required

-          Lastly because they already invested in Oracle, it was easy to integrate with the technology stack from Telenet

Not only did APEX fulfill the requirements, it also was a good decision from a financial perspective.

The demo Patrick showed of the different tools was also quite sexy. It is nice to see that architects are starting to see the Advantages from APEX as a development tool.

In conclusion I would have to say that, even though I could not attend all APEX sessions, it was pretty clear that APEX was strongly represented on OBUG, it shows that it is an important player on the Oracle market.

Apex Extension

About a month ago I saw a mail coming by where a colleague of mine had integrated the jQuery plug-in Codemirror into a text area for the end-user. I hadn’t seen this plug-in before, but I really liked the feel of it.

I’m sure all of us can recognize the fact that we miss tab indentation in  APEX, or that we would like to see key words, numbers and strings in color, or how about some line numbers? Perhaps line numbers that hold into account that the line number of an error in a PL/SQL APEX process is never quite the same as the place of the error. This last one is because APEX places BEGIN and END; automatically around PL/SQL processes. Convenient for the developer so he can develop faster, not so much when it comes down to debugging.

Since we can not change the APEX Application Builder, it would be nice to find another solution? And that solution exists: take a look at the following screenshots:

Image

Image

So how did I do it? A little “thinking outside the box” did the trick. While we might not want to mess with Apex directly, we can use browser Extensions and add-ons, to alter the looks, safely from a distance. So I created a small Chrome Extension that integrates CodeMirror into the APEX Text Areas.

Chrome Extensions are created with HTML5 and JS so once you have the basics of your Extension set up you can convert an Apex Text Area like this:
var vTextArea=document.getElementById(“F4000_P4312_PROCESS_SQL2″);

vMyEditor = CodeMirror.fromTextArea(vTextArea, {

mode: “text/x-plsql”,
tabMode: “indent”,
tabSize : 2,
lineNumbers: true,
firstLineNumber: 2,
lineWrapping: true
});

I wrapped this in a “$(document).ready(function(){});” to make sure it is executed after loading all plug-ins.

I hope I showed you all that you can do allot with a little imagination, and I welcome any questions or suggestions.

Joni Vandenberghe