7.6.1 seems to have some problems with launch pages under Firefox ("error missing string IBIMR_folder", and the variable is clearly defined as a hidden variable in the HTML source). I've opened up a case on this, but this prompts the question:

How does one display the internal vairables used in the WF API on a target FEX, so that I could see for myself what is or isn't getting passed? It seems the WebFOCUS client strips these variables out after processing, as I can't seem to access the elusive IBIMR_dir, IBIMR_folder, IBIMR_domain, ibif_ex, ibic_server, etc. from the target FEX side.

Is there any magical incantation that will cause the internal hidden variables to appear after crossing the parsers in the WF client and reporting server?

Any clues in this quest would be most appreciated. I tried search on Focal point and can't seem to stumble on the correct keywords - if this topic has already been discussed, I apologize for the redundancy.

Regards,

Dan Kenny
University of Nebraska at Omaha
Prod: WF 7.1.6 Test: WF 7.6.1 Linux BID/MRE/DataMigrator

I imagine you know that
-? &
will display all Dialogue Manager variables available in the WebFOCUS session.

To pass certain system variables, you may wish to take a look at this:

https://forums.informationbuilders.com/eve/forums/a/tpc/...961093381#2961093381

It's part of a thread about passing system parameters and may help in passing MRE parameters.

You can turn on traces on the WF server and see all of these variables and their values in the resulting file.

Thanks Francis, that's exactly what I needed.

The magical incantation for the WebFOCUS client to pass internal variables is to set in the configuration (I did it in cgivars.wfs):

IBIMR_folder(PASS)
IBIMR_user(PASS)
IBIMR_domain(PASS)

etc.

They then show up on the DM echo (-? &) and are available for use within FEXes.

Interestingly enough, explicitly passing IBIMR_folder across knocks out the bug with Firefox producing an error about IBIMR_folder not being defined. What a Bonus


Darin, thanks for the suggestion of turning traces on, but I was also interested in permanently accessing these variables on the reporting side -- for logging, for display on headers/footers in reports (IBIMR_user is most useful to know), etc.

Regards,

Dan Kenny
University of Nebraska at Omaha
Prod: WF 7.1.6 Linux BID/MRE/DataMigrator Test: WF 7.6.1 Linux BID/MRE/DataMigrator

Gotcha. We also use the IBIMR_user variable for some additional security in populating drop-down boxes. It sounded like you were just trying to troubleshott an issue, but this changes the environment to give constant access to what you need.

Dan, I can't imagine what effect using a different web browser has - after all, it's just a URL, non?

Cheers.

Francis,

You would think so. But a lot of IBI's developer tools produce messy js code that renders only on Microsoft IE. On 7.1.x, the popup calendar won't even display in Firefox.

Much of the admin toolsets (like WF Administration Console) won't run under Firefox because of things in javascript that I.E. ignores, like undeclared object variables -- but Firefox strictly enforces.

It goes back to standards-compliancy (or lack thereof if you're MS and can subtley break things for the "competition") and it has affected everything from Java VM implementations through CSS standards, Javascript standards, etc.

Don't get me wrong, I think IBI has done a GREAT JOB in weaning the WF product off of platform dependency, first with the MS Java VM for their applet environment, then with browser independence in the iWay webconsole, and further with each release, supporting both IE and Firefox. Why, even with 7.6.1 the MRE applet WORKS on Intel Macintosh OS X !

Anyway, the only thing I can speculate is that there are browser tests on the server side and different logic applied. Either that or the hidden variable IBIMR_folder is NOT what the parser is using on the server side, instead it is embedded in the binding of the submit button that is getting reconstructed through the WF client. And I couldn't begin to try to figure out what "xml id=ibirequests" and its corresponding requests tag is doing.....

It's all a mystery to me

Regards,

Dan Kenny
University of Nebraska at Omaha
Prod: WF 7.1.6 Linux BID/MRE/DataMigrator Test: WF 7.6.1 Linux BID/MRE/DataMigrator

Dan, you know about the Firefox IE Tab add-on?

https://addons.mozilla.org/en-US/firefox/addon/1419

Cheers.

Dan

I do have to agree with you over the javascript that IB produces.

For people like me, who have to create a system for ALL platforms and to be cross browser compliant, it is a major task and rules out most tools that IB produce, and increases the cost of development many fold. I can JUST get maintain to work cross browser, if I am careful, but even a simple auto prompt is out, though I can get the calendar to display cross browser now.

Platform dependency is not viable today. Our company has customers who use Macs with Safari and open source Linux with Opera and other combinations. In fact our company themselves want to move towards open source, but cannot at present.

For our customers, a Firefox add-on is not an option.

PLEASE can IB concentrate a little more on the javascript, it is not difficult really.

Francis,

I am aware of the IE Tab extension for Firefox, and have it installed. But that is only available for Windows and doesn't help for those in our customer base that don't run Windows.

Alan, I can relate to the problems you experience using the tools. For our customers, Firefox support is mandatory. We work in a higher education environment, and we can't tell our faculty and staff that they must only purchase PCs that run Windows and only run IE. As a matter of fact, for years IE was so vulnerable to security attacks, many across campus promoted Firefox out of necessity. We have standardized our campus-wide application support on two browsers, IE and Firefox, because we can't support all browsers (Safari, Opera), and Firefox works consistently across Windows, Linux and Mac, and is very good for standards-compliancy.

When we use buggy Javascript tested only for IE, this translates into a lot of support labor as our Help Desk gets reports of web pages not working and people waste time tracing it down to the application rendered under Firefox.

I agree with you, there is no reason for javascript to be so problematic with WebFOCUS.
There have been great strides made since version 5.2.x, as the iWay folks have done a great job making the Webconsole fully standards-compliant with both IE and Firefox (and that interface uses a TON of JS), so we know that it can be done with WebFOCUS and the code that Dev Studio produces.

I echo your call to Information Builders for more QA concentrated on the javascript. I just found another bug in 7.6.1 with respect to Firefox (the input type TEXT box breaks launch page submission under Firefox). This is quite frustrating, baseline functionality that worked in 7.1.6 now breaking in 7.6.1!

IBI publishes that Firefox 2.0 is supported under 7.6.1, and version 1.5 is CERTIFIED, with some very limited exceptions. We use Firefox in our development to ensure that our services are standards-compliant. I think IBI should do the same with the WF authoring tools and parsing engines. It is time to ensure the product works in a world where customers aren't a "captured audience" with respect to their PC, such as in the higher education sector.

My thoughts,

Dan Kenny
University of Nebraska at Omaha
Prod: WF 7.1.6 Linux BID/MRE/DataMigrator Test: WF 7.6.1 Linux BID/MRE/DataMigrator