Showing posts with label Flash charts. Show all posts
Showing posts with label Flash charts. Show all posts

Thursday, January 19, 2012

How to remove the thousands group separator in numbers representing years from apex flash charts

Always check out the original article at http://www.oraclequirks.com for latest comments, fixes and updates.

A quick tip for formatting years when they show up as labels in flash charts inside Oracle Application Express (Apex).
The problem is in that Anychart is too smart, so when it encounters a label that looks like a number, it will format it with the separator for the thousands, i.e. "2012" will be displayed either as "2,012" or "2.012" depending on the application locale settings.

As I don't really liked to see years formatted that way, I thought I had to find a way to suppress the thousands separator without having to resort to using a custom XML chart source file. After a few attempts, it turned out that by prepending a non-breaking space to the string, I could fool anychart's super-smart engine eventually. The technique applies to UTF-8 encoded pages.

UNISTR('\00A0') || TO_CHAR(gl_date, 'YYYY')

Not a big deal but something that may come in handy if you are in a hurry and short of more brilliant ideas. May be there are other ways to achieve the same result, this was just the first one that occurred to me.

The chart clearly displays my annual income as apex freelance, just in case you are wondering :-P

Wednesday, February 16, 2011

Avoiding the flash chart security warning in Apex with EPG

Always check out the original article at http://www.oraclequirks.com for latest comments, fixes and updates.

If you host multiple web sites on the same apex server (using Apache as proxy and EPG) and some of these applications display flash charts, you might incur in the annoying problem of the security warning:


Flash Security Error:
AnyChart can not be launched due to Flash Security Settings violation.
Please refer to Security Error Article in AnyChart Documentation to fix this issue.
There are at least two possibilities to fix this problem (see at the bottom of this post for an interesting update):
1. as per AnyChart documentation, by placing a policy file placed in the domain root folder.
2. by replacing the substitution string #HOST# with a valid and stable URL prefix in the flash chart region source.

As i couldn't implement the first solution due to inexplicable problems with the cumbersome flash security settings, i was left alone with the other option. I always feel very frustrated when I can't get to the bottom of a problem but after spending four hours trying to figure out what the hell the flash player is expecting and without any evidence of progress, no matter how hard I tried, I simply gave up in favor of the second strategy, which took five minutes to be done.



What is happening is easily explained:
if you inspect the page source at run time, you'll find out that apex is replacing the string #HOST# with the values taken from a couple of CGI environment variables called 'HTTP_HOST' and 'SCRIPT_NAME':
BEGIN
dbms_output.put_line ( 'http://'
|| OWA_UTIL.get_cgi_env ('HTTP_HOST')
|| OWA_UTIL.get_cgi_env ('SCRIPT_NAME')
|| '/');
END;
Unfortunately the content of these variables change with the http access conditions.
For instance in my case there is Apache acting as proxy server and I get different values depending on whether I access the site through the proxy server at port 80 or directly through port 8080. In the former case HTTP_HOST will contain 127.0.0.1:8080, in the latter www.somedomain.com:8080.
In other words, if I access the page containing the flash chart via apache I'll get the flash security message otherwise it will work correctly.

As the correct way of accessing the apex page for the end-user is via the proxy server on port 80, the valid and stable URL prefix that I need to specify in the apex chart region source is http://www.somedomain.com/apex matching the URL prefix of the page being displayed in production.

So one might be tempted to hard-code the URL in the chart source region but this not an ideal choice for a variety of reasons, starting from the fact that in this fashion our application won't display the charts in our test or development environment because the chart source region will refer to the production site.
My solution is to create an application item called BASE_URL that is initialized with the right URL basing on the setting of a build option. As i am already used to have a PRODUCTION build option in all applications enabling certain features like visitor tracking and google ads when its status is include, I simply created a couple of mutually exclusive application computations that run "on new instance" and update the value of BASE_URL with the static value http://www.somedomain.com/apex when PRODUCTION's status is include or the PL/SQL expression
'http://' || owa_util.get_cgi_env('HTTP_HOST') || owa_util.get_cgi_env('SCRIPT_NAME') || '/'

when the status is exclude.

May be this is not the panacea for all possible situations, but it worked out pretty well until now and it doesn't even require any action on your part if you chose "include" as default value on export for the build option.

Updated February 16 after David's comment
While i was writing this posting I was thinking of doing a little modification in my Apache server configuration, then I published the article without doing the test first. David's comment reminded me that I still had to do that task to complete my job.
I modified the configuration of Apache where it is instructed to forward the requests received against apex on to IP 127.0.0.1:8080, a typical configuration that you will find in several examples in the Apex OTN forum.
# previous config
# ProxyPass http://127.0.0.1:8080/apex
# ProxyPassReverse http://127.0.0.1:8080/apex

# new config
ProxyPass http://www.somedomain.com:8080/apex
ProxyPassReverse http://www.somedomain.com:8080/apex
Then i reverted the chart region source to its original version with the #HOST# string and to my surprise the chart was displayed without reporting the "infamous" security message.
As a further step I also added the web domain to /etc/hosts as an alias for 127.0.0.1 just to avoid some unnecessary roundtrip between the DNS server and the web server.

In the end, it looks like we can work around the problem by manipulating Apache's configuration and without the need of crossdomain.xml or changes in chart source regions, at least for "simple" architectures like this.

yes you can!

Two great ways to help us out with a minimal effort. Click on the Google Plus +1 button above or...
We appreciate your support!

latest articles