Embedding Files within APEX: Where things go wrong

This is the final part of a three part series on embedding files in your APEX application. You should read all the articles (Part 1 and Part 2) before deciding whether or not to leverage this feature in APEX as it has its pros and cons.

The previous posts in this series covered how to upload, reference, and create installation scripts for embedded files within APEX. This post will cover some caveats that people may not be aware of when using embedded files within APEX.

I already hinted in the first post of this series that they're several reasons why you may not want to embed files within APEX. Besides performance issues they're situations which you'll get some unexpected behavior. I've included examples of some of these issues below. Each example assumes that you have a static file (test.js) included in the base application and it's also in the installation scripts.

Copying an Application 

A lot of times people tend to copy an application within a workspace to back it up before doing a big change or to run some one-off tests on their own. If you copy an application, despite selecting Yes for "Copy Supporting Objects Definitions" the application specific files are not copied.

In this case you'll need to manually run the Supporting Objects > Install Supporting Objects to install the file (assuming that the installation script has the latest version of the file). But wait. When you do that it'll actually remove the file from the original application and install it in the new one (i.e. it no longer exists in the application that you copied from).

Deleting a Copied Application

If you copied an application and selected "Yes" for "Copy Supporting Object Definitions" we know from the previous example that it doesn't install any embedded files. If you now delete the newly copied application and check off "Deinstall Supporting Objects" it will also remove any files from the base application that you copied from.

 

Summary

If embedding files in your APEX application sounds confusing don't worry, it is. I had to do many test cases while writing this blog to confirm some of the scenarios.

If you've read through the entire three part series on embedding files in your APEX application you'll notice that it can be very confusing and cumbersome. This can cause a lot of unexpected issues in the long run.

As much as possible I avoid embedding files in APEX and instead store them on a web server. To me, it's just not worth the hassle. Of course they're exceptions. If I can't get access to the web server or if the application is to be bundled as a stand alone application then it makes sense.

Embedding Files within APEX: Supporting Objects

This is part two of a three part series on embedding files in your APEX application. You should read all the articles (Part 1) before deciding whether or not to leverage this feature in APEX as it has its pros and cons.

A major misconception when uploading a file into APEX is that it will be included when you export the application. Though I agree that makes the most sense, unfortunately it doesn't work this way. You need to explicitly include an installation script that will copy the file into the workspace where the application is being imported to. Sound confusing? Unfortunately it is.

In the previous post I uploaded a file into an application. If I were to export then import this application into another workspace that file wouldn't be included. To explicitly include the file you need to create a Supporting Object installation script:

- Go to Application > Supporting Objects > Installation Scripts and click the Create button.
- At the bottom, under the Tasks heading select "Create Scripts to Install Files".

 - Select the file that is required for the application and click the Create Script button.

At this point in time, APEX will encode (base64) the file (in it's current state) and create a PL/SQL installation script that can be run when you import the application. If you change the file (in Shared Components > Static Files) it has no impact on the installation script (i.e. it's a snapshot of the file at this point in time).

Not updating the installation script with the latest version of the file is where a lot of issues occur when migrating the application from different environments. After someone initially creates the installation script, there's a high probability that you may change the base file, forgetting to update the installation script. This is one of the main reasons why I don't usually recommend embedding files into my application.

Part 3 of the series will cover some issues with embedding files in an application.

Embedding Files within APEX: WORKSPACE_IMAGES vs APP_IMAGES

This is first of a 3 part series on embedding files in your APEX application. You should read all the articles before deciding whether or not to leverage this feature in APEX as it has its pros and cons.

APEX allows you to embed static web files (CSS, JS, images, etc) into your application. This functionality removes the need to store web files on a web server which is required for some applications.

To upload your file into the application go to Shared Components > Static Files. Click the Create button. On the Create page you can upload a file and either associate the file to a specific application or no application.

Files associated to a specific application must have a unique filename within its parent application. It can then be referenced (most likely in a page template) using the #APP_IMAGES# substitution string. Ex: #APP_IMAGES#test.js

Files that are not associated with a specific application are available to all the applications within the workspace and can be referenced (most likely in a page template) using the #WORKSPACE_IMAGES# substitution string. Ex: #WORKSPACE_IMAGES#test.js

Files that are added to the application aren't stored on the web server. They are stored in the database. For high traffic applications this may not be a great idea and you may want to look at storing them on a web server.

Part 2 of the series will cover how to include the files in a installation script.

Oracle Magazine - On Code Reviews and Standards

Last year at Kscope 12 in San Antonio I gave a different kind of talk than I normally do. It was called "Building a Better Team" and focused on the importance and value of doing peer reviews and having coding standards.

It just so happened that Jeff Erickson, from Oracle Magazine, was in attendance. Following my talk Jeff asked me to do an interview for the Community: Up Close section of the magazine. The article, On Code Reviews and Standards was published this month! I've also included the video interview below.



If you don't already have a peer review process implemented in your organization I hope this article will help motivate you to start one.

ODTUG Marketing Committee

In case you missed it on the ODTUG blog, I along with Bambi Price are starting a new Marketing Committee and are looking for some volunteers to join the committee. All the information can be found in this article.

If you're looking to get involved with the ODTUG community and/or passionate about marketing this is an excellent opportunity for you. I look forward to working on this committee and help with ODTUG's marketing efforts.