Could IBI Developers get Back Button to work with Drill in PDF and Excel

John,

The reason that the back button "does not work" in PDF and Excel outputs is down to the fact that the output is redirected (see redirection settings on your server) and as a result the back button - which issues a javascript go.back() - only backs up to the point at which the redirection took place.

If you click on the down arrow next to the back button you will see the history for that browser window and you can select the second item in the list to take you back to where you want to go.

T

In FOCUS since 1986	WebFOCUS Server 8.2.01M, thru 8.2.07 on Windows Svr 2008 R2
	WebFOCUS App Studio 8.2.06 standalone on Windows 10

Posts: 5694 | Location: United Kingdom | Registered: April 08, 2004

Ignored post by Tony A posted

Alan B

Virtuoso

posted

John,

It is not a browser issue, or directly an HTML issue.

When a request for a report is made, you will see a URL something like:
http://server/ibi_apps/WFServlet?......

If it is an HTML request, then a page is returned directly, if PDF/EXCEL the page is 'refreshed' with the URL to retrieve the PDF/EXCEL file, that's the URL with the GETBINARY in it. That is 2 URLs since the original call, not 1.

The only way to control this would be via the server, but a general feeling is that this might be problematic. If the same URL is requested via the Back button, the server could pass control back one level, but what happens if the refresh button is pressed, it can get very complicated, though someone in IB may have the skill to do this effectively.

WebFOCUS is not unique here, many programs/sites suffer the same and it is a general usability issue.

Alan.
WF 7.705/8.007

Posts: 1451 | Location: Portugal | Registered: February 07, 2007

Ignored post by Alan B posted

GamP

Virtuoso

posted

Haven't realy tried this, but what would happen if you specified pdf and/or excel downloads not to be redirected?
You can control that through your mime types file (the mime.wfs) in the webfocus client environemnt. I think it is even accessible through the client console.
Remember to restart tomcat when you're done modifying the mime wfs file directly.

GamP

- Using AS 8.2.01 on Windows 10 - IE11.
	in Focus since 1988

Posts: 1961 | Location: Netherlands | Registered: September 25, 2007

Ignored post by GamP posted

Virtuoso

posted

For the record, WF does issue a location.replace(url). Theoretically, this should replace the current history contents of the browser session so that when you click the back button you then get the 2 pages ago. This does work properly when the URL is a HTML file. The actual problem here is that the location.replace() does not work as documented when using IE and the returning document has a content type other than HTML.

If you do GamP's idea and change the mime settings, then the back button will work, but then drill downs will become an issue.

I think the real problem lies with IE here, and not IB. I cannot find any Javascript documentation that says the location.replace(url) will only work with HTML files.

I haven't tried Firefox or any other browser to see if this problem happens with them as well.

"There is no limit to what you can achieve ... if you don’t care who gets the credit." Roger Abbott

Posts: 1102 | Location: Toronto, Ontario | Registered: May 26, 2004

Ignored post by dhagen posted

Virtuoso

posted

quote:
I haven't tried Firefox or any other browser to see if this problem happens with them as well.

I just ran a test with a Firefox PDF Plug-in, and it worked as documented. In other words, the back button brought me back to the starting screen before the PDF file was displayed.

So, I believe this is an IE issue, and not a WebFOCUS issue. Maybe we should all open a thread on an IE developer forum and ask MS to properly support the location.replace() method.

"There is no limit to what you can achieve ... if you don’t care who gets the credit." Roger Abbott

Posts: 1102 | Location: Toronto, Ontario | Registered: May 26, 2004

Ignored post by dhagen posted

Tony A

Expert

posted

Darryl,

... and the chances of Bill going along with that are .............?

Two hopes - and one of them's Bob!!

In FOCUS since 1986	WebFOCUS Server 8.2.01M, thru 8.2.07 on Windows Svr 2008 R2
	WebFOCUS App Studio 8.2.06 standalone on Windows 10

Posts: 5694 | Location: United Kingdom | Registered: April 08, 2004

Ignored post by Tony A posted

Virtuoso

posted

quote:
Originally posted by Tony A:
Two hopes - and one of them's Bob!!

Nice!

On a side note: Maybe there is hope!

"There is no limit to what you can achieve ... if you don’t care who gets the credit." Roger Abbott

Posts: 1102 | Location: Toronto, Ontario | Registered: May 26, 2004

Ignored post by dhagen posted

Tony A

Expert

posted

There's points in that article that could apply to some other software vendors I know of

In FOCUS since 1986	WebFOCUS Server 8.2.01M, thru 8.2.07 on Windows Svr 2008 R2
	WebFOCUS App Studio 8.2.06 standalone on Windows 10

Posts: 5694 | Location: United Kingdom | Registered: April 08, 2004

Ignored post by Tony A posted

hammo1j

Master

posted

Thanks very much to everyone who replied to this. Maybe IE8 will sort this out.

(Or maybe not since Microshaft seems intent on wanting the world to follow its standards while ignoring any worldwide standards itself!)

Server: WF 7.6.2 ( BID/Rcaster) Platform: W2003Server/IIS6/Tomcat/SQL Server repository Adapters: SQL Server 2000/Oracle 9.2
Desktop: Dev Studio 765/XP/Office 2003 Applications: IFS/Jobscope/Maximo

Posts: 888 | Location: Airstrip One | Registered: October 06, 2006

Ignored post by hammo1j posted

Virtuoso

posted

So close but no cigar.

I was a little bored on the weekend, so I started thinking about this problem. What I tried was to use cookies to store the users navigation for either excel or pdf file. The idea was pretty simple: As a pdf or excel file was generated, the forwarding page would identify the unique url file name and append it to a predefined cookie. When the page was re-loaded (by the back button), if the unique file name was already part of the cookie, then it would remove the name from the cookie and issue window.back(). If the file name did not exist, then it would append the file name to the cookie and allow the page to proceed as normal.

This worked surprisingly well except:
- I could not identify when a forward button was pressed.
- A back button issued on the original page would result in a blank page being presented (because there was no history to go back to).

All in all, I don't know if this behaviour is better or worse the what is currently there.

"There is no limit to what you can achieve ... if you don’t care who gets the credit." Roger Abbott

Posts: 1102 | Location: Toronto, Ontario | Registered: May 26, 2004

Ignored post by dhagen posted