Skip to main content

APEX 5 New Package Features

To get a proper list of the new packages and API's APEX 5 provides us, we have to wait for the documentation of course. But if you're impatient and want to now more, you can get a list of all package procedures and functions by running this SQL on the APEX 5 Early Adopter instance:


select distinct s.synonym_name, p.procedure_name
from all_procedures p join all_synonyms s on p.object_name = s.table_name
where p.owner like 'APEX%'
  and s.synonym_name like 'APEX%'
order by 1, 2;

You'll get a list of over 700 procedures/functions. Most should look familiar. But there are some new kids on the block like : APEX_JSON, APEX_SPATIAL and APEX_ZIP.
You can examine the ALL_SOURCE view to get more insight by looking at the parameters and the examples in the comments.

The APEX_ZIP package is - according to the comments in the package - based on the work of Anton Scheffer (see this blog post). The functions / procedures can be used to zip and upload a file or to download and unzip a file. 

The APEX_SPATIAL package enables you to use the Oracle Locator and Spatial Option within APEX. I am not sure whether one of the functions in that package actually require a Spatial Option license - and if you can easily violate the (absence of that) license by calling such a function "by accident". Maybe one of the Oracle people can shine a light on this - always tricky - subject!

The APEX_JSON package finally, is used for generating and parsing JSON with PL/SQL. As an example - more or less "borrowed" from Morten Braten's post

Generating JSON
begin
   apex_json.initialize_output(p_http_header => false);
   apex_json.open_object();
   apex_json.write('Item1','value1');
   apex_json.open_array('Attributes');
   apex_json.open_object();
   for i in 1..3 loop
     apex_json.write('Attr'||i, i);
   end loop;
   apex_json.close_object();
   apex_json.close_array();
   apex_json.write('ExtraData','More to come');
   apex_json.close_all();
end;

results in :

{ "Item1":"value1" 
,"Attributes":[ { "Attr1":1 ,"Attr2":2 ,"Attr3":3 } ] 
,"ExtraData":"More to come" }

Parsing JSON
declare
   l_json varchar2(32767) := '{"empno":123, "empname":"King", "empsal":3000}';
begin
   apex_json.parse( l_json );
   htp.prn( apex_json.get_number( p_path => 'empno' ));
   htp.prn( apex_json.get_varchar2( p_path => 'empname' ));
end;


Results in : 123 King

This feature can be very handy when you want to generate JSON as a source for one of the many Javascript charting libraries that usually need data in this format. Or - the other way around - when a call to an ORDS Web Service returns JSON and you need to display the results somewhere on a page.
Post a Comment

Popular posts from this blog

Push changed rows to an Interactive Grid

For pushing changes from the database to the end user, the regular solution is using websockets. A change in a record is detected - using a trigger or using the CQN (Change Query Notification) feature - and a notification is send to a websocket server. That websocket server broadcasts the notification over a channel to all browsers that are tuned in to that websocket channel. Then the browser reacts to that notification, usually showing an alert or refreshing a report. This trick is described on multiple sites, just Google for "oracle apex websockets" or similar.

So back in the old days, we used that notification in the browser to refresh the (interactive) report. But along comes the Interactive Grid (IG). While he full-refresh mechanism still works for IG, an IG has also the option to refresh just one row.  So wouldn't it be awesome that just the changed row(s) get refreshed upon a change in the database, instead of the whole report? Can we do it ... yes we can!
First i…

Refresh selected row(s) in an Interactive Grid

In my previous post I blogged about pushing changed rows from the dabatase into an Interactive Grid. The use case I'll cover right here is probably more common - and therefore more useful!

Until we had the IG, we showed the data in a report (Interactive or Classic). Changes to the data where made by popping up a form page, making changes, saving and refreshing the report upon closing the dialog. Or by clicking an icon / button / link in your report that makes some changes to the data (like changing a status) and ... refresh the report.  That all works fine, but the downsides are: The whole dataset is returned from the server to the client - again and again. And if your pagination size is large, that does lead to more and more network traffic, more interpretation by the browser and more waiting time for the end user.The "current record" might be out of focus after the refresh, especially by larger pagination sizes, as the first rows will be shown. Or (even worse) while you…

Dockerize your APEX development environment

Nowadays Docker is everywhere. It is one of the main components of Continuous Integration / Continuous Development environments. That alone indicates Docker has to be seen more as a Software Delivery Platform than as a replacement of a virtual machine.

However ...

If you are running an Oracle database using Docker on your local machine to develop some APEX application, you will probably not move that container is a whole to test and production environments. Because in that case you would not only deliver a new APEX application to the production environment - which is a good thing - but also overwrite the data in production with the data from your development environment. And that won't make your users very excited.
So in this set up you will be using Docker as a replacement of a Virtual Machine and not as a Delivery Platform.
And that's exactly the way Martin is using it as he described in this recent blog post. It is an ideal way to get up and running with an Oracle database …