I have a really weird bug and getting a look at the parameters that are passed would be worth its weight in gold. But, somebody else created it in the Version 8 Composer tool so its code is impenetrable. I can't switch it to run the report in GET mode, in fact there isn't even a form to work with. Can't read the source code in the tool either.

Here's the question -- is there any way I can get this screen to issue its request via a method=GET so that I can see the focexec call in the url instead of the useless "http://mvgbibiwf1/ibi_apps/WFServlet.ibfs"?

Version 8 is cutting my productivity in half.

This message has been edited. Last edited by: <Emily McAllister>,

I would suggest that you use the browsers developer tools.

In my opinion, Chromes is very good.

The way the I do it is:

Press F12
Select Network tab
Go back to your page
Do the action
Look at the calls made.

These are usually in Doc or XHR

You can click on the call and see the parameters passed.

You can still get to the source code for an html composer generated page, you just have to go into the portal screen in your browser, the one with the tree structure on the right side. Find your html file, you can right click and click 'Edit' and the source code will come up.

If you are passing variables to a fex, you could also try '-TYPE' them out in there to see what comes up. You could also alert your variables and controls too to see what they contain when you submit them using javascript too.

The advantage of a GET form submission is that you can make changes directly on the url to test boundaries, and as importantly, make doggone sure your browser isn't caching by adding a random value to the end of the line.

I had a very strange situation yesterday way format EXL2K wasn't functioning properly but all other formats were. Not the kind of thing you usually see from WebFOCUS. My concern was that it wasn't sending the same submission string. I wanted to break to problem into two clean pieces -- the interface, and the report. Can't do that if you can't examine the submission.

I'll admit that I'm dragged kicking and screaming into the Composer tools. I'm a guy that rolls my own because I can make the materials super clean, super simple. But on this project I have to work with what's there, and the Composer tool is so doggone opaque. If somebody knows a way to kick the composer tool into "method=GET" mode after the fact I'd sure like to hear it.

Meanwhile, thanks Waz. I'll give that a shot. If it lets me see the calls that may be sufficient for this particular case.

The problem is that you need to first get the HTML controls into a form. In Dev Studio 8.0.08 and below, you can choose to use a form, though I cannot say if the form is used in the conventional manner. After creating the HTML page, you could change the form method to POST via text editor.

I don't know if this is possible in App Studio.

(I could definitely be wrong, but I don't think you can take an existing HTML page, add a form, drag the controls into the form and expect the form submit to be used).

I can set a standard on the project as "thou shalt use forms" and that will help going forward. I do see a form widget in the App Studio application, but if there's a Dev Studio that's more deluxe I can't think of a reason to not have a couple of copies. Is V8's version of Dev Studio a more capable version of App Studio?

It's difficult to test and verify something that you can't understand, so I prefer lean and clean. I realize the world doesn't roll that way anymore, but for some applications it's critical.

WebFOCUS is almost Jekyl and Hyde on this at the moment -- their model for FOCUS code, interpretive and very human-readable is the epitome of lean and clean. It's great to work in, super-easy to IV&V. Their model for the front-end interface is a thirty foot vat of chocolate pudding. If it works that's great, and let's hope that's the case, 'cause there ain't no debugging. Often I replace it with two dozen lines of html code (literally -- most interfaces require very little code) that work every bit as well and can be adjusted in minutes.

quote:

(I could definitely be wrong, but I don't think you can take an existing HTML page, add a form, drag the controls into the form and expect the form submit to be used).

You can but I will say it is hit or miss, especially if you want some type of validation onSubmit. More times than not, I wind up just deleting what's on the page and recreating it in the form.

'Deleting and Recreating is the GUI Way' must be tattooed on somebody's whatsit.

At a guess, when your report outputs to Excel, the HTML page that initially processed the fex results gets removed as soon as the contents are handed over to Excel, leaving you with nothing to look at for debugging. That used to be different (albeit ugly).

What I usually do in such cases is to change the report format to HTML, so that I can look in the generated source for errors, debug prints, etc.

It's likely that the problem you're seeing is Internet Explorer recognizing the URL and fetching it from cache. That particular browser is so retarded WRT caching that it wouldn't surprise me if it caches that it cached something. No browser should cache the results of a POST request.

It can be worked around though. For example, you could add a parameter to the report for a random number, and have that added to the launch-page form as a hidden field populated with a random number in the standard IBI onInitialUpdate() function.

quote:

Originally posted by Francis Mariani:
'Deleting and Recreating is the GUI Way' must be tattooed on somebody's whatsit.

This is going to be part of my signature now...

quote:

It can be worked around though. For example, you could add a parameter to the report for a random number, and have that added to the launch-page form as a hidden field populated with a random number in the standard IBI onInitialUpdate() function.

math.random(), one of my favorite js functions!

A couple things you can do also, is create your own ajax call using jquery. Then you can define in the javascript whether to use a post or get. I'm about to go to 8.1.05, and I have a feeling that when I build my pages, I might be moving more towards that approach. Also, you can always put the following at the top of your fex to capture the variables being passed

-? &
-EXIT 

If the only reason you want to use get, instead of post is for debugging, that might work for you. Thats what I generally do to find out whats being passed. That and -SET &ECHO='ALL';

That's more or less what I do when I write my own. It's just an easy request where I can attach whatever variables I want (including a random number to kill caching) and I can complete visibility to what I send, and how it is received. Sometimes those two don't match, which is why I like to have that level of control.

Its funny how so many want the call to be GET, yet I would like all the calls to be POST. I think its the design of out portals that is doing it.

We have a lot of calls that are too long for a GET.

If the call gets over about 2000 chars, then its probably not going to work.

Agreed, but if you use a Form tag you can switch between GET and POST super-easy. That's great for debugging. Besides, the JavaScript for creating a submission cookie is super easy, and you have a couple of megabytes worth of room at that point.

True.

But to get back to your original question.

quote:

is there any way I can get this screen to issue its request via a method=GET so that I can see the focexec call in the url instead of the useless "http://mvgbibiwf1/ibi_apps/WFServlet.ibfs"?

With Developer tools, you can combine the call (http://mvgbibiwf1/ibi_apps/WFServlet.ibfs) with the parms and effectively use a GET.

As mentioned earlier, when you click on the call, in the right pane in the headers tab go to Form Data and click view source, copy and add to the call above with a ? between them.

If the page was created in Dev Studio then open it in composer.

Select the form, right click and choose Properties.

Make sure the Properties panes is showing formX

(where X is usually 1 but can be any digit) and the about half way down the Properties list you will see:

Method Post.

Click on Post and you can change to Get

You can so the same in App Studio but the list of Properties is slightly different. The Method Property is under the "Miscellaneous" section.

Cheers

Stu

WebFOCUS 8.2.03 (8.2.06 in testing)

quote:

Originally posted by Waz:

As mentioned earlier, when you click on the call, in the right pane in the headers tab go to Form Data and click view source, copy and add to the call above with a ? between them.

I don't know what "when you click on the call" means in that sentence. Is this in App Studio or in Chrome like you mentioned earlier? I don't have a Headers tab in either one.

Yes its in Chrome developer tools.





Example