A few years ago it was deemed state-of-the-art to store any kind of extra resources (images, css/js-files) directly on the webserver.
Of course this was just the best-practice, left with many who were not able to follow because of company restrictions: no access to web server, not allowed to store files, too many regulations, and so on.
Luckily APEX 5++ gave us nicely working Static Application Files and Static Workspace Files. Now everyone is using those to store extra files.
A while ago I posted a guide how to set up nginx as a reverse proxy in front of tomcat to run ORDS and APEX. See the post here.
An open problem was that APEX was still thinking it runs on port 80 with http, while nginx was running https on port 443.
As a big fan of APEX Packaged Applications I always wanted to have a real life usecase for the Survey Builder.
Usually the APEX images reside in a directory on your server called /i/, which can be changed on instance or application level.
In 95% of all cases I saw, the image prefix is /i/, sometimes it is extended by a version number like /i501/ or /i181/. Continue reading
Just recently I talked about changing the /ords URL to something else, now I want to show another way to manipulate the URL.
I always disliked deploying multiple ORDS instances, just to provide different paths to the same DB. This happened out of legacy or SEO purposes so far.
Now let’s set up a simple reverse proxy to achieve any URL structure you want for your APEX server.
Usually ORDS is deployed on Tomcat simply as /ords, right?
What do you do, if you want a different name than ords, let’s say you would like to see “bruce” in the URL? Simple solution: just rename ords.war to bruce.war before deploying to Tomcat.
But what if you want to have “mod/plsql“, as in http://myserver.tld:8080/mod/plsql ?
Oracle APEX offers a declarative setting for Text and Textarea items to “Trim Spaces”, which would remove leading/trailing spaces from the user input before saving the value to the database.
A few days ago (Friday, of course) apex.oracle.com has been upgraded to APEX 18.2. As widely know, once apex.oracle.com is upgraded the general availability of such a release is very close.
For me it is a stable enough release, to have a look what changed in terms of packages and views.
On a recent installation we had problems serving APEX static files (application and workspace), they would always report a 404 not found back from ORDS.
When installing Oracle APEX you also get a wealth of additional resources to explore: Packaged Applications.