New WebFOCUS Feature to Ignore Your BI Users

New WebFOCUS Feature to Ignore Your BI Users

Information Builders introduces so many new WebFOCUS features with such little fanfare that it is difficult to keep up.

That being the case, I suspect that few people are aware of a new feature in the WebFOCUS HTML Composer for ignoring parameter values. It is an enhancement to a nifty feature that came out many releases back called "FOC_NONE."

This takes some historical explanations. Consider as an example building a graphical user interface for a report with an option to select data for a particular geographic region. Of course, that selection is optional, so you give your users the ability to identify "ALL" regions as well.

In the early web application development days, WebFOCUS developers would dynamically build a WHERE condition with the user-selected values and, for the "ALL" option, either skip around that with a GOTO or build a symbolic WHERE line that would be blank. However, that type of coding often meant that the WebFOCUS GUI tool was immediately confused and would no longer paint the report.

To help overcome this challenge, Information Builders added logic to WebFOCUS to ignore any lines which contained a keyword of "FOC_NONE." By setting your selection criteria to "WHERE REGION IS FOC_NONE," you could guarantee the line would just be ignored resulting in the "ALL" condition you wanted.

Again, some background information is useful. There are two types of WebFOCUS language: one procedural and the other non-procedural. The processor for reading the languages is called Dialogue Manager. As it reads the code, the procedural statements are executed immediately while the non-procedural statements are placed into a stack of memory for later execution.

So the FOC_NONE processing takes place within Dialogue Manager and the core WebFOCUS non-procedural language is totally unaware. The Dialogue Manager line containing FOC_NONE is processed (the special keyword does not cause the line to be ignored); only the non-procedural lines get ignored.

Now, fast forward to the latest WebFOCUS 7.7 release.

The new WebFOCUS HTML Composer now has an option to specify the "ALL" ignore option as either FOC_NONE or a new keyword: _FOC_NULL. These two words are deceptively similar but very different.

For one, the FOC_NONE keyword is processed by Dialogue Manager by throwing away the entire line being parsed and not putting it into the WebFOCUS stack for processing.

_FOC_NULL, on the other, is a new part of the core language syntax. Instead of ignoring lines with that keyword, Dialogue Manager will put the line into the stack and let WebFOCUS figure out what to do with it.

So what will WebFOCUS do with _FOC_NULL? If inside a WHERE statement, WebFOCUS will ignore it much like it would with the legacy FOC_NONE option.

Everywhere else, however, WebFOCUS will see the _FOC_NULL. When embedded inside headings and footings, that new keyword will just show up as a blank. Typically, this is where you want FOC_NONE and ignore the entire line.

Perhaps a more useful place for _FOC_NULL is with DEFINE calculations. Let's say that you create a temporary column with a symbolic variable. Later, you use that column in another calculation.

If the parameter value is provided, all works well.

However, if you get a FOC_NONE value in the first calculation, the entire calculation is ignored. When WebFOCUS comes to the second statement that references the first, it fails (since the first calculation was never really processed). You end up with a syntax error because WebFOCUS ignored the line with FOC_NONE (just like it is supposed to do).

If you were to pass in the _FOC_NULL keyword instead, then the first calculation would be processed but with a null value. The second calculation would then work, albeit with no real data.

Still, I have problems with this new feature. In real-life, sometimes you need FOC_NONE and sometimes _FOC_NULL behavior in the exact same program. That means coding to switch values back and back between the two keywords. Perhaps it would have been better to create an environmental setting to change the FOC_NONE behavior instead of having two different keywords.

My other concern is that the HTML Composer's default behavior is to generate the new _FOC_NULL keyword instead of the legacy FOC_NONE. I would prefer that enhancements follow a more "backward-compatible" philosophy.

Unfortunately, the HTML Composer has in the past changed behavior so that previously-built WebFOCUS applications stopped working. I have some inside scoop on how Information Builders plans to avoid this in the future and I will blog about it shortly.
Next Post Previous Post