In the first two parts of this blogpost series we covered the basics and the technique on how to provide nice/friendly/readable URLs for a public APEX Application.
Again here the links for two examples: the Sample Database Application which will be used as example in this post and the click-click Website (which is multilingual, just change /en/ to /de/ in the URL).
This Blogpost will cover the necessary changes in an APEX Application, to work with human readable URLs.
and that the active Authentication Scheme isn’t No Authentication (using DAD), since that would lead to problems in combination with the APEX Listener with APEX 4.2.3 and below (Bug 17796199 fixed in 4.2.4).
The Path is important, otherwise a new cookie (and new APEX session) would be created when visiting /home at first and /customers after that.
The Cookie Name is optional, you can also leave that blank.
Target is URL
Above we prepared the application to support our new URL structure. Now its time to walk through our application and change every Button, List Item, Branch and whatever Link you may have to use the new and shiny URLs.
A good idea here is to define an application substitution string which holds the base URL. In my demo I have defined a substitution string called G_URL which is set to /pls/apex/hrurl. In URL Targets I then can use it like this: &G_URL./customer/#CUSTOMER_ID#
Base URL to support Form Submits
So far everything works fine, we can call and show all our Pages. But when trying to submit (save) a form we get an error saying that wwv_flow.accept doesn’t exist.
This happens, because wwv_flow.accept is simply appended to the end of the active URL. e.g. http://apex.oracle.com/pls/apex/hrurl/customer/2/wwv_flow.accept
The easy workaround is to define a Base URL using a simple HTML Meta Definition.
Can you see it? It is this simple command: <base href=”/pls/apex/” />
UPDATE: older IE versions (yes, some people still call it a browser) need a fully referenced base href, like: <base href=”http://apex.oracle.com/pls/apex/” />
Now wwv_flow.accept is appended to the base URL and all submits work fine again.
Would be great, if the APEX Dev Team could include the base-URL definition automatically.
AJAX Calls and Interactive Reports
There is still a tiny problem with our friendly URLs. AJAX calls (also Interactive Reports and regular report pagination) don’t work anymore. The AJAX calls are returned with a HTML error code.
Problem here is htmldb_Get doesn’t use the base-URL, it tries to find f?p in the current URL and replaces that with wwv_flow.show (the AJAX Entrypoint). Our URLs don’t show f?p, so wwv_flow.show is appended to the end of the current URL, which is obviously wrong.
This Bug still exists in APEX 4.2.4, I hope it will get fixed in APEX 5.0.
There is no easy workaround here. The only option we have is to overload and redefine htmldb_Get, which I did for the demos.
Again: overwriting htmldb_Get is a workaround which is likely to break with the next APEX Version.
Using friendly URLs is possible today, even in older APEX Versions when using mod_plsql. There are some things you need to take care of in your application, as listed above.
Once you know your way around, it takes a couple hours to turn an existing public application into using human readable URLs.