Saturday, February 25, 2012

The Truth About False Actions

When Martin D'Souza was writing his chapter on Dynamic Actions for Expert Oracle Application Express, he sent me a bit of it for a technical review. I did the same with him for my chapter on Plug-ins. At the time, both of these topics were very new and I immediately learned something from a decision tree that he had created to show how Dynamic Actions work from a high level. The tree very clearly showed that false actions will only be executed if two things are true:

  1. The Dynamic Action must have a condition
  2. The condition must evaluate to false
It sounds simple enough but this important fact seems to loose itself on those that are new to Dynamic Actions. Even when this fact is understood, developers may still have trouble getting the false actions to fire because they can't think of a condition that will work for their situation. The key lies in understanding conditions and how flexible they can be.

Let's start by looking at a simple example. Let's say you want to hide/show a region based on the value of an item: 



The When portion of the Dynamic Action may look like:



Obviously the true action in this case is to show the region and the false action would be to hide the region. In this example we were able to make use of one of the declarative condition types: "equal to". Here are all of the options you have for the condition:



Most of the options are declarative, simply changing the way that the Value specified is evaluated. But there are two options which are a little different: "- No Condition -" and "JavaScript expression".

If you select "- No Condition -", guess what, NO FALSE ACTIONS! At that point only the event matters - in our current example that's the change event on the item P1_HIDE_SHOW. The Dynamic Action framework does a good job of making this point obvious by hiding the false actions when there is no condition but I wanted to make sure to remind readers of this fact here.

"JavaScript expression" is the powerhouse option. This is the option that you must learn to use! Like the declarative options, the JavaScript expression condition changes the way that Value is evaluated but it's much more flexible as you can enter any JavaScript expression you like. If you click on the label for the Value item you get the following popup:



Of the three bullets, the one you want to learn first is this.triggeringElement. Using the combination of the JavaScript expression condition type and this.triggeringElement, developers can create conditions that allow false actions to execute when they otherwise wouldn't.

Let's look at another example. Here the show/hide is based on two conditions rather than one:



At first glance it may seem impossible to do this with a Dynamic Action but with the JavaScript expression condition we can do it:



I could have simply hard coded the id for the first element but I wanted to show how one could use this.triggeringElement as it's more flexible - imagine using it in a tabular form where there are many checkboxes with "random" ids.

As you can see, Dynamic Actions are an incredible feature of APEX and with a little knowledge of HTML, CSS, and JavaScript they become even more powerful. Learn to use this feature sooner rather than later and look for the functionality and flexibility of the framework to increase with future releases of APEX. And if you remember nothing else from this post, remember that false actions only fire if there is a condition and it evaluates to false.



Saturday, February 18, 2012

Radio buttons and jQuery Mobile

APEX 4.2 is supposed to put mobile front and center in APEX. But some developers aren't waiting. If you're in that small group of folks that is pushing forward with mobile development using jQuery Mobile prior to version 4.2, you may have found an issue with radio buttons.

jQuery Mobile does a fantastic job of enhancing the look and feel of elements in the DOM so that they look and work better in mobile browsers. For various reasons, including accessibly and proper alignment of elements, jQuery Mobile expects some specific HTML. In most cases, satisfying these requirements in APEX is as simple as wrapping the label and the element with a wrapper div. Even in 4.1 this can now be done from the label.

Radio buttons, on the other hand, are a good example of where APEX will need to be enhanced even more to work properly with jQuery Mobile. For now we just have to do a little extra work. Here's the standard HTML output for a single column radio button in APEX:



The markup produces the following when rendered in a browser:


When we go into "mobile mode" the table is gone and the elements are wrapped with a div so we get the following HTML output:



Once jQuery Mobile applies it's enhancements to the markup, we get the following rendering:



It may not be noticeable at first, seeing as how it's so different from the standard rending, but the look is not quite optimal. The reason is that jQuery Mobile is expecting output more like this:



The differences, while subtle, are important. Some are easy to spot while others are not. Here's a brief list:
  1. The fieldset that jQuery Mobile is expecting has some important attributes (data-role and data-type) 
  2. APEX uses a label for the fieldset while jQuery Mobile wants a legend (inside the fieldset)
  3. The fieldset in APEX has the CSS display property set to block via apex_4_1.min.css
  4. Each label in the fieldset in APEX is followed with a br element
  5. APEX adds the tabindex attribute (causes jQuery Mobile to "focus" incorrectly)
While we can't control everything that APEX outputs, we can modify the output after it makes it to the browser and before jQuery Mobile goes to work enhancing it. Here's some jQuery code that does just that:


Since most of use are not using the Ajax based page loading that jQuery Mobile like to use be default, putting the code in the Execute when Page Loads portion of the page attributes will work fine. Once jQuery Mobile is finished enhancing the new markup the radio buttons will render as follows:


Or, if you prefer, you can remove the optional .attr('data-type', 'horizontal') line from the JavaScript to get the following rendering:


If you haven't already gotten started with mobile development in APEX, check out Marc Sewtz's blog for details and downloads that can get you up and running quickly and easily. I'm really looking forward to seeing what Marc and the rest of the team has planned for the 4.2 release!

Friday, February 10, 2012

ifttt Worked!

When I first heard about ifttt I thought it sounded really cool. For those of you that don't know, ifttt is an abbreviation for "If This Then That". The site allows you to create tasks that have triggers and actions which work across various channels like twitter and email. Check out their wtf page to learn more.

As cool as it sounded I couldn't think of a reason to use it at first. But after looking over the channels and options for each, I thought of a problem that ifttt could help me solve. People occasionally post questions about SkillBuilders plug-ins in the APEX forum. The problem is that the APEX forum doesn't have a notification system that allows one to search for strings so I may miss those posts.

I noticed that one of the channels in ifttt is for RSS feeds and the forums do provide that ability. Another channel is for email. So I set up a task that monitors the forum looking for "skillbuilders" in the in post and sends me an email when it finds a new one. I did this around a month ago and yesterday I got my first notification - awesome! I'm looking forward to figuring out new ways to use this great technology and I hope you can too.