Sunday, 5 July 2015

Apex 5.0 - Getting Down With Dialogs (Part 1)

A part of any modern day web application is the use of dialogs. With the release of Apex 5.0, the development team has obviously put a great deal of work into this functionality and made it an integral part of Apex. Through the use of JQuery UI, the team has given us some feature-rich components and processes to use to support our need for dialogs.

In their simplest terms, dialogs are interactive modal  popups that can be used to give additional information to the user, assist them in processing selected steps, or guide them through a wizard of nested steps. They offer the user the sense of "staying" where they are and not having to navigate around to accomplish a task. Dialogs are immediate, dramatic and captivating.

In previous versions of Apex, we had to use plug-ins or write considerable javascript to build these kind of dialogs into our applications. Now, with Apex 5.0, the full power of dialogs is rigt at our fingertips.

There are several types of dialogs available in Apex 5.0. In this first post in the series, I will discuss only one of them - the inline dialog.

Inline dialogs are really just regions on a page that function like a modal "popup" dialog. They are distinct from their more powerful cousin, the modal dialog page, in that they are simply a region and not a page. This, while it may seem obvious, is a key point. As a region on an existing page, the inline dialog does not need all of overhead involved in page rendering and processing. The region is in fact rendered as part of its containing page and therefore can be displayed very quickly. This lightweight "here I am" power of the inline dislog is also a bit of a weakness. As a region on a larger page, it lacks the validation and processing power of a separate page and is therefore not really suited to complex operations.

Before we go into the details of how to create an inline dislog, we ought to understand what in fact it will do.

 As you can see from the above image, an inline dialog looks and feels much like a modal page. When the dialog is opened, the launching page is dimmed to highlight the modal region. The dialog awaits the users interaction before continuing and the underlying parent page is "frozen". Much like a modal page, it can have buttons to invoke actions, but it is important to understand that the whole page, not just the modal region, will be submitted when the button is clicked. More about that later.

It may help if I take a moment to explain my specific use of the inline dialog here. My application tends to be very dynamic. I am always adding new functionality and need a way of highlighting the new features to users. So, what I have developed is a page messaging franework. I have a database table where I store the messages that I want to display referenced by page number. When a user launches a page in the application, a process checks to see if there is a message to be displayed to the user for that page. If the user has not viewed the message before, the inline dialog is displayed with the message and title from the database table. Once the user clicks the "Got It" button, I record that the user has viewed this message and it will not be displayed for the user again. The framework allows me to set messages for any page in my application in order to help users find and use new features.

So, how do we create the inline dialog? It is really pretty simple. Create a new region on the page and set the region template to "inline dialog."

In my case, because I need the title and content to by dynamic, I have two hidden page items that I reference for both the region title and the content.

Once you have selected the region template of "inline dialog, you can open the Template Options where there are a number of settings to further control and appearance of the region.

Once you have the region the way you want it, it is time to trigger the display of the modal region. You need to determine under what circumstances the region will be displayed. Here, I want the region to be displayed on the loading of the page if there is a message to be displayed and the user has not viewed the message before. As I mentioned earlier, I have hidden page items for the title and content of the inline dialog message. These page items only get values assigned to them if there is a message to display for that specific page and if the user has not yet viewed the message. This then gives a mechanism for displaying the dialog. If the hidden items are not null, then I want to display the dialog. So, I have an "on change" dynamic action that references the hidden page item and fires if the item is not null:

Then, as part of my dynamic action, I use a true action of "Execute Javascript Code" to open the dialog:

Notice that I pass the static id for the region to the openModal function. And that's it! The inline dialog will be displayed. Of course, your triggering action may be quite different, but you get the idea.

Let's return to my earlier point about the entire page being submitted. An inline dialog region is different from a "modal page" in that it is simply a component of the parent page. Consider my "Got It" button that is part of my dialog region. The button has the behaviour of "Submit Page." When it is clicked, because the inline dialog is part of the parent page, the entire page will be submitted with all of its items etc. Therefore, it is important that you control the processing and branching based only on the single button being clicked. There are several ways to do this, but the most common would be to use the "When button pressed" condition processes and branches.

There are some other important issues associated with the fact that the inline dialog is simply a region of the parent page:

1.  It will display very quickly as it is rendered with the parent page.
2.  Unlike a modal page, it shares its processing with the parent page.
3.  It is best suited for static content and limited user interaction.

There are lots of ways you can effectively use inline dialogs. You can use them for messages (as I hve), for alerts, confirmations or for quick popups that display additional information when the user opts to view it. They are very slick and can really contribute to a positive user experience.

Modal regions have been a part of Apex for quite a while. But now, with Apex 5 and the built-in use of JQuery UI, they are easier than ever and offer the developer a great deal of options of customization and control.

Add a comment to this blog and let me know how you are making use of inline dialogs. And watch for Part 2 in this series where I will discuss the more powerful and feature-rich modal dialog page.

Sunday, 28 June 2015

Apex 5.0 after two months

I have been using Apex 5.0 for two months now and figured it was high time I start blogging about it. So, here are some thoughts after eight weeks of exploration.

At first I found the new builder features a little difficult. There had been so much hype about the new Page Designer. I guess I was just so comfortable with the old component layout that it would have been so easy to stay with what I know. But, yes, I stuck with Pagc Designer and now can't imagine a world without it. I love that you can change component attributes in bulk and that you only have to click save once for the entire page. It is so easy to drag regions and items where you want them. So, while Page Designer might intimidate you at first - stick with it. Your productivity will soar.

I am thrilled with the new code editor. You can write code exactly as you would in any tool such as SQL Developer with all the feateres you need and can validate the code without leaving the editor. This is another huge productivity gain.

Modal regions and modal pages are very powerful and easy to implement. I must say that I am using them more than I ever had in my applications and they contribute to a great user experience. I will try and post a blog just about modal dialogs soon.

The Universal Theme and Themeroller are really inspiring and have a lot to offer. The user response has been good though many have suggested that the apps have adopted a "Microsoft" look - oh no!

There are some things that took me a while to come right with and I will blog about those in the hope of saving others time and frustration.

Most important of all, my apps in Apex 5.0 are running about 20% faster. Page and report refreshes are faster. Chart rendering Is faster and even database processing seems faster.

Now for a few complaints. There have been long-standing issues with Tabular Forms and no work has been done in this area. Some of the IR customization capability seems to have been removed. Report layouts seem somewhat less flexible but I an still exploring here.

So after all is said and done I love Apex 5 and feel renewed and excited as an Apex developer.

Wednesday, 2 January 2013

Email and Subscription IR Reports in Apex 4.2

There has been a problem for some time with regard to email and subscriptions of IR reports. Prior to Apex 4.2, the "from" address for these reports when sent by email has always be the same as the "to" address entered by the user. In other words, if the email report was being send to, it would have the from address set to

Having the "from" address the same as the "to" address, often resulted in issues on mail servers. Some mail servers have policies set that do not allow external emails to come from an internal server address. Other times, mail servers will treat these sorts of a mails as junk or span and not direct them to the inbox. Further, it just looked weird!

Now, Apex 4.2 allows you to explicitly set the "from" address either at the instance level, or at the report level itself.

Navigate to a page that has an interactive report, and view the Report Attributes. Scroll down to Advanced Attributes. Here, you can specify the "Email From Address":

You can also set the from address at the application level.  In Application Builder, edit and application and click the Edit Application Properties button. Scroll down to the Properties section, here you will find a property where you can special the application's "from emal address."

Sometimes it is just the little things that make a big difference!

Tuesday, 1 January 2013

A Response to Responsive Design in Apex 4.2

I have been following with a lot of interest the discussions regarding implementing Responsive Design using Theme 25 in Apex 4.2.  In case you are out of the loop, Responsive Design has to do with building applications that are fully functional across many different devices with various "viewport" sizes from the small screens of smartphones to the largest desktop screens.

My journey begin by reading Shakeeb Rahman's blogs on Responsive design here. I downloaded the presentation slides and worked my way through them. To me, this was exciting stuff. I was beginning to explore new approaches to web applications and it was quite cool had it all worked. I then downloaded Apex 4..2 and began to play with them 25 to see how it all fit together.

Not being convinced I had all the tools and information I needed, I purchased the book Responsive Web Design with HTML5 and CSS3 by Ben Frain that you can find here. It is a really great book and leads you through the whole implementation of a practical Responsive web application. I learned a tremendous amout about HTML5 and CSS3 and how to enhance what theme 25 already tries to accomplish. I built a couple of good test applications that worked very well on various deI vices.

Now here is where my response comes in.....

I have a large application that is used by many concurrent users. And, as you might expect, I thought "hey, why not make it responsive?"  I set about to do just that. Not as simple as you might think. The big issue for me is that the application is primarily a series of real-time reports. Many of these reports are quite large and consist of up to fourteen columns. Some of the reports include drill-downs where the data is displayed on modal pages for ease of use and navigation. These reports simply are not suited for small screens - you can't avoid scrolling and the reports are almost useless in a small format. I just didn't make sense to try and make the application work all small viewports. Here is a case where it would be far more productive to have 2 separate user interaces, one for desktop and one for mobile (fully supported in Apex 4.2). The mobile application can present streamlined reports with only critical columns while the desktop version can support the full reports.

There is, of course, a greater cost to having two separate interfaces (one for mobile and one for desktop). You need to support both versions of the application. The logic may in some places be duplicated. You may need to maintain separate CSS files and so on. But, in my case, no other approcah seems to make sense. I am open to comments from others that may suggest I am wrong. After all, I am new at Responsive Design. Please do feel free to offer you own feedback.

I also did a bit of checking on my application. In Apex, you can monitor how your application is being accessed. You can monitor what OS is used and what browser. I found, dare I say it, over seventy percent of my users are accessing my application from IE (Yikes!!!!). This despite a message on the login page advising that the application is best used with Firefox. So, why spend oodles of development time (not to mention money) trying to make the application responsive.

I am not suggesting that we ought not to learn about and use Responsive Desgin. It has a clear role in making our applications future-proof. After all, more and more users today access websites via a device other than a desktop. What I am suggesting, however, is that creating "responsive" applications is but one approach. There are instances when it will be appropriate and instances where is simply won't achieve great results.

Perhaps the key lies in planning the design from the very start. If instread of simply following an approach and layout dictated by our client, or worse, by a graphic designer, we take the position from the start that it would be ideal to have a responsive application. In other words, we approach the whole project from a responsive point of view and try to desgin and build an application that can in fact be independent of the device on which it is viewed. To do this, you need to understand some of the concepts, techniques and tools involved in creating responsive web applications. There is no doubt this is the future. In my view, it is one more tool in our toolbox and not the solution to every situation. Thankfully, Apex 4.2 gives us a number of approaches to consider and to implement.

Friday, 19 August 2011

Enabling and Disabling Classic Report Columns

Sometimes a classic report with many columns takes up too much space on the screen. There are a number of options for dealing with this issue, but one that I like is to provide the user with the ability to turn on and off individual columns or groups of columns.

I have seen several different ways of providing this functionality. For instance,  Denes Kubicek has a solution in his sample application, but it does not handle column groups and is somewhat more awkward. So, for what it is worth, I thought I would share my solution.

First, I create a series of checkbox items representing the columns (or column groups) that I want to allow the user to "turn on and off."  I put these items in a hide and show region so that they are accessible but not necessarily displayed until the user wants to change the columns.

Next, I modify the report. I set the Conditional Display attributes of each column in order to reference the related checkbox.

In some cases, I have more than one column being controlled by a single checkbox. My report has several columns that display dates. I use a single "date" checkbox to turn off and on the entire group of columns.

Next, I create a dynamic action for each of the checkbox items. The dynamic action is triggered by the "Change" event of the checkbox.

There are two true actions. The first, Execute pl/sql Code simply serves to put the value of the checkbox item into session state.

The second action simply refreshes the region containing the classic report.

 You will need to repeat the above steps to create an dynamic action that will trigger on the change of each of the checkbox items.

 The result allows the user to quickly enable or disable columns. Due to the use of the dynamic actions, the report quickly responds to the user changes. You can set defaults for the checkbox items so that some of the columns will show on page load and others will wait for the user to select the column for display.

Friday, 29 July 2011

Minimizing IR Filters On Default Report

I had a requirement for an IR report that specified that the background colour of the rows be set to specific colours based on certain data values. To accomplish this the easiest way possible and to allow the user to "turn on" and "turn off" the colours, I created a series of IR filters.

Each filter is set to define the highlight colour based upon specified data:

The result is excellent. The rows are highlighted based on the specified criteria and the user can disable specific highlights if they wish. Obviously, these filters are saved as the default report.

But, my mother taught me to keep things clean and tidy. And, when you first open the report you are faced with a list of filters that you may or may not wish to alter. It makes the report screen rather busy and I wanted to temporarily hide the filters when the page first loads. Hmmmm - dynamic actions?

Here's the solution:

1.  Using the Advanced dynamic action wizard, create a new dynamic action and set the event to Page Load.

2.  Create a true action of type Execute Javascript Code.

3.  Enter the following for the javascript code:

/* Minimize IRR filters on page load*/
if( $('#apexir_CONTROLS_IMAGE').attr("src") == '/i/minus.gif') {

And, that's it!  A result that even my mother would approve of - everything neat and tidy!

The users can still access the filters by clicking on the "plus" sign and can just as easily hide them again.

Wednesday, 27 July 2011

Expert Oracle Application Express

If you have not yet bought your copy of Expert Oracle Application Express -  what are you waiting for? I got my copy in the mail a couple of weeks ago and was thrilled to read it. I am one of those developers who tries to read everything I can on Apex to stay at the top of what I do. And, for me, this book is now a "must read" for anyoune who aspires to be an Apex professional.

This book is written by a collection of authors - most of whom you will know from the forum or from their blogs. What I liked most about the content is that there is a focus on detailed information that you won't find elsewhere. It is not a book for the beginner who knows little about Apex, but rather, is aimed at the professional developer who is keen to know more.

I have already put to use much of what I learned from the book. In particular, Dimitri Gielis's chapter on charts and Martin D'Souza's chapter on dynamic actions really helped to further my understanding on two key areas of importance in my current development. All of the other chapters were also fantastic.

So, if you want to go beyond the boundaries of the basic documentation and move into the world of advanced knowledge - this book is a great place to start. I highly recommend it.