Tuesday, July 05, 2016

Prevent general row based search in an APEX Interactive Report

At my current project we use Interactive Reports heavily. But in some cases the underlying queries are rather complex and a query without any filter or with just a filter on all columns doesn't perform that well (understatement...). We already implemented a solution to prevent initial loading of the data by adding an additional criterium to the query ( :P400_SEARCH = 'Y' ). The default value of this hidden item is 'N' and on Page Load the value is set to 'Y', so the next search will be executed. But as said, this is good, but not good enough...

So this morning I was looking for a solution to "force" the user to enter a query on one of the columns - either through the "search bar column list" (the magnifier on the left side of the search field) or through the Actions > Filter menu. The first attempt was to use a Dynamic Action that fires on change of the search field, but that doesn't work when the user switches existing filters on or off. So I inspected the debug output of the page and discovered an item named "APXWS_EXPR_1". This item is set when the report is refreshed and contains the value of the first column filter you apply. Subsequently you can have APXWS_EXPR_2 etc. So I added an additional restriction to the query: 

:APXWS_EXPR_1 IS NOT NULL

Thus by just adding one line to the query the user is forced to use at least one column filter - both the "contains" as any other more specific filter works. And I can even delete the previous solution that prevented running the query (actually the query is run, but returns "no data found" in no time) when the user navigates to the page.

As a side note, if you use the general filter on all columns, that value is available on the server as "APXWS_SEARCH_STRING_1" (and _2 etc.)

Tuesday, June 07, 2016

Create a Navigation Bar based on a SQL statement

Creating a Navigation Bar using static values is very straightforward. Just create a list similar to this example below - and you can easily define multiple levels.
Then, in the User Interface Attributes, set that list to be your application's "Navigation Bar List" and specify the template.
And the Navigation Bar pops up nicely in the upper right corner of the screen.
So far so good.

But what if you don't want a Static List, but get a list based on a SQL statement? Then you have to enter a statement that adheres to the this structure:
select level, labelValue label, 
       [targetValue]            target, 
       [is_current]             is_current_list_entry,
       [imageValue]             image, 
       [imageAttributeValue]    image_attribute,
       [imageAltValue]          image_alt_attribute,
       [attribute1]             attribute1,
       [attribute2]             attribute2,
       [attribute3]             attribute3,
       [attribute4]             attribute4,
       [attribute5]             attribute5,
       [attribute6]             attribute6,
       [attribute7]             attribute7,
       [attribute8]             attribute8,
       [attribute9]             attribute9,
       [attribute10]            attribute10
from ...
(the columns between the square brackets are optional ones). Adding any other column will fail. But it seems you can enter a "level", so if your query returns the rows in the correct order, you should be fine. You think.
Because doing so (and using the very same List Template) will not work when you have multiple (parent) entries with children: All parents will show the same children, the ones of the first parent. The issue is raised a few times on the Oracle Forums, but never answered (see here and here).

Because I ran into that very same issue this morning, I dived in a little deeper. The problem is in the generated HTML: all buttons (parents) will get the same ID. So that's why the same children are attached to all the parents. 
So where does it get it's ID from? That's defined in the "Navigation Bar" template. In there references to "#LIST_ITEM_ID#" and "#PARENT_LIST_ITEM_ID" are used. But those values are not returned by the query. Even worse, you can't even define columns with those names. 

So the solution is to copy that Navigation Bar Template and replace the references to #LIST_ITEM_ID# and #PARENT_LIST_ITEM_ID# with a column that is returned from the query (and of course contains the right value). So, for instance, use #A09# and #A10# instead of the #LIST_ITEM_ID# and #PARENT_LIST_ITEM_ID# and be sure to select "attribute9" and "attribute10" in your query.
This way you can define a multilevel Navigation Bar based on a SQL statement !


Tuesday, March 15, 2016

Me and the ODTUG Board

This afternoon my Twitter timeline exploded with retweets, likes and congratulations. It all started with this tweet:

So it's official now. As Sarah Zumbrum had to step down due to her (dream) move to Oracle, a position on the ODTUG board opened up. And I was asked whether I was still interested. And of course I was! So after an internal voting procedure, I received the good news last weekend - and had to keep quiet for a few days...which was quite hard!
Last November I wrote a blog post "I *almost* made it to the ODTUG Board of Directors...", but now the word between the asterisks can be omitted.
I am thrilled to serve on the board - even though it's initially only until the end of the year. I'll definitely run again for the board in October - so you'd better become a member a.s.a.p. to vote for me then (if you aren't already)!
Hope to see you all at Kscope16 or any other local event.
You can read the official statement on the ODTUG site.

Monday, February 22, 2016

Unexpected behaviour using SSO Authentication for APEX

A customer of mine switched to a Singe Sign On Authentication Scheme for their APEX application - using Oracle Access Manager, but that's irrelevant to this case.
In the application there's a function to create an - temporarily - "real" APEX user. That APEX user is used in another JavaScript application that uses ORDS and the built-in APEX authentication - thus requiring the existence of APEX users. That function ran flawlessly when the application was still on APEX Authentication. But after switching to SSO, it complained about "ADMIN" privileges .... although the usernames are identical: SSO and APEX Authentication used the same usernames.
So it must be something in the authorization / security realm, isn't it? Thus we tried a smart thing and moved that particular function to another - APEX Authenticated - application, while sharing the login credentials via a cookie. But to no avail. Some complaint.
So I contacted the APEX Development team and - as always - I got a quick reply. It wasn't a bug. It's a feature. They explained that you can only use functionality that needs APEX Admin privileges if you are authenticated against the APEX Repository. An - accidental (?) - match on usernames is not enough to grant ADMIN privileges. And that totally makes sense....
So although it was unexpected behaviour, it is the correct behaviour!

BTW. the solution is to create a separate job that runs using the right privileges.

Wednesday, February 17, 2016

Navigating through your APEX Calendar - the easy way

The renewed Calendar Region in APEX is awesome. With just one SQL statement you can provide your users with a calendar view of their data that looks very familiar to what they already know, use and love. Apart from one thing: Navigating to a specific date is cumbersome.
The shortest route is:

  • Navigate to the right month (can be any number of clicks) 
  • Switch to "Week view" 
  • Navigate to the right week (between 0 and 4 clicks) 
  • Switch to "Day view" 
  • Navigate to the right dat (between 0 and 7 clicks)

Way to many clicks!
So how hard can it be to make it easier - more user-friendly? We would like to navigate from both the Month view and the Week view directly into the Day view of a specific date. So with just one click once we have that day in sight.

Dynamic Actions to the rescue. Of course. What else...

First from the Month view to the Day view:
1. Create a Dynamic Action with the specs as shown to the left. Notice the the Event Scope should be "Dynamic" otherwise it wouldn't work after you navigate to another month. This DA will fire upon a click on the TD element that contains the day number in the Month view.
That TD element contains the actual date as a "data" attribute. So we can access it using
$(this.triggeringElement).data().date















2. The Action is a piece of JavaScript:
// Go to the date of the clicked day
$(this.triggeringElement).closest("div.fc").fullCalendar("gotoDate", $(this.triggeringElement).data().date);
// Switch the view to Day view
$(this.triggeringElement).closest("div.fc").fullCalendar("changeView", "agendaDay");
// Kill the Dialog if you have one
setTimeout( function(){ apex.navigation.dialog.cancel(true); }, 1);
That last line is only necessary when you defined a "Create Link" on your Calendar region. And there are probably better, more elegant, ways of solving that.

Second from the Week view to the Day view:
1. Again, create a Dynamic Action. But now use ".fc-agendaWeek-view th.fc-day-header" as the selector.
In the Week view, the date itself is not contained in the header, but in the TD of another table below the headers. So we have to traverse the DOM a bit to get that clicked date.

2. The JavaScript code is:
var clicked = $(this.triggeringElement);
// find the index
var i = clicked.index();
// find the corresponding day and date
var day = $(clicked).closest("div.fc-agendaWeek-view").find("div.fc-bg td.ui-widget-content").eq(i).data().date;

clicked.closest("div.fc").fullCalendar("gotoDate", day );
clicked.closest("div.fc").fullCalendar("changeView", "agendaDay");
setTimeout( function(){ apex.navigation.dialog.cancel(true); }, 1);

The result is elegant and very intuitive:
Try it yourself on : apex.oracle.com

Thanks to Marc Sewtz for helping me out finding the "fullCalendar" methods.


Monday, November 09, 2015

I *almost* made it to the ODTUG Board of Directors ...

Last month was the annual election for the Board of Directors of ODTUG. And just like the year before, I was one of the 19 (!) candidates for one of the 5 spots. 
During the campaign and election periods I received a lot of positive feedback and my hopes were high - but the competition was extremely strong. During Oracle Open World the results were announced and I was notified I hadn't made it into the top 5 - alas.
And after receiving the detailed results it appears I was "that" close ...

Also, during the election period, I got some messages saying "if I could vote, I would vote for you". Of course that kind of support is helpful, but it would be better for me and for ODTUG when those people signed up as either a Individual or Corporate member - see the ODTUG website. For just $99 you get unlimited access to a wealth of knowledge and you support your favourite user group. So that's just $8.25 per month very well spent !

Thanks to the (large number of) people who voted for me. I hope I can count on your vote again if I'm running again this fall !

Tuesday, September 22, 2015

APEX Reports : Double click to edit

Apart from the Current Record Indicator in your APEX Reports, another question often pops up at my client sites. A lot of functionality is implemented using a Report and a (Modal) Form. But to access that Form, the user has to click exactly on the small link icon in the first column of the report. So can that be changed, making it more "accessible"?

Set the Link Attributes of the column you're using for the link (or the Link definition itself) to: 
class="editlink"

On Page 0 / Global Page add a Dynamic Action that fires on "Double Click" on the jQuery Selector "tr.clickable". Note: This class was set using an After Refresh Dynamic Action, see the previous blogpost. You can also accomplish that without the Current Record Indicator, but you have to assign the class "clickable" to the TR - you can do that with just the "editlink" class as a selector.
The Dynamic Action should execute a JavaScript call:  
// Execute a click on the element that is used as anchor
apex.event.trigger( $(this.triggeringElement).find("a.editlink").children(":nth-child(1)") , "click");
This simulates a click on the anchor with the "editlink" class. And now your user can just open the Form with a double click somewhere in a row of the report.

Implementing a Current Record Indicator in your APEX Reports

Developers with an Oracle Forms background might still remember this nice feature: If you click on a row in an Oracle Form "report" then it can be highlighted - either the full row or just a small first item of the row. The main difference with the Oracle Forms "reports" and the APEX Reports is that in Forms a "report" is usually comparable to an APEX Tabular Form. But a similar feature is frequently asked for - especially at customer sites that are transforming from Forms to APEX.

With a few lines of code we can make these customers happy .... Let's get started.

First of all your query should contain one column (as "Plain Text") that describes the Primary Key - that might even be a concatenated set of columns. Now we have to tell APEX that this is the column that contains our PK. For a Standard Report just add the CSS class "rowlink" to the column (without the quotes) . For an Interactive Report we need to use the HTML Expression:
 <span class=”rowlink”>#PK-Column#</span>
Of course you have to replace "PK-Column" with the alias of the Primary Key column in your query. This column will be hidden when running the page so if you don want to see it, you have to name that column twice in your query.
That's the only thing you have to do for every report with a "Highlight Current Record" feature.

The wizardry will be implemented on Page 0 / Global Page. First of all add a hidden item P0_CURRENT_RECORD. Set these properties: Value Protected = No,  Source = Null (always).
Next, create a Dynamic Action that fires After Refresh of this JavaScript Expression:
$(".rowlink").closest("div.t-Region, div.t-IRR-region")
This expression returns the div (either Standard Report or Interactive Report) that contains a "rowlink").
And the Action is, execute this piece of JavaScript:

//Remove the alternating rows and row highlighting from the report
$('.t-Report--altRowsDefault, .t-Report--rowHighlight', this.triggeringElement).removeClass('t-Report--altRowsDefault t-Report--rowHighlight');

//Hide the rowlink column and header
var header = $(".rowlink").closest('td').hide().attr('headers');
$('#'+header).hide();

// For each "rowlink" item
$(".rowlink").each( function(i,key){
  // Define a click handler for the TR that contains a   
  $(this).closest('tr').on("click", function(){ 
    $(".highlight").removeClass("highlight");
    $(this).addClass("highlight");
    $s('P0_CURRENT_RECORD', $(key).text());
  });
  // Create a data-id attribute for each rowlink  
  $(this).attr("data-id", $(key).text())  
});

// Add a "clickable" class to the TR -- not for this feature, see next blog post
$('.rowlink').closest('tr').addClass('clickable');

if ( !( $v("P0_CURRENT_RECORD") ) ) {
  // Issue a dummmy click on the first row
  $(".rowlink:first").closest("tr").click();
}
else {
  // Issue a dummmy click on the row containing the current PK
  $(".rowlink[data-id='"+ $v("P0_CURRENT_RECORD") +"']").closest("tr").click();    
}
Finally we need some CSS to actually see the highlighting in action - showing the current record with a light blue background that even changes slightly from color when hovering over it:
.t-Report tr.clickable { 
  cursor : pointer; 
}

.a-IRR-table tr td, 
.t-Report tr td {
  background-color: transparent;
}

.a-IRR-table tr.highlight,
.t-Report tr.highlight {
  background-color : lightblue;  
}

.a-IRR-table tr.highlight:hover td,
.t-Report tr.highlight:hover td{
  background-color: lightsteelblue;  
}

This code seems to work fine in most situations. There is an issue if you use something else than the Heading : "Fixed to None" property for an Interactive Report. And there might be a challenge when your page contains multiple reports.... but consider that as homework ;-)