Trent's Tech Tips

I had just been looking at exposing some procedure for URL access, using ORDS. ORDS offers the following configuration properties: security.inclusionList security.exclusionList security.disableDefaultExclusionList security.validationFunctionType security.requestValidationFunction Which you can see on the docs: https://docs.oracle.com/cd/E37099_01/doc.20/e25066/config_file.htm#AELIG7204   If you look at the administrator guide:  https://docs.oracle.com/cd/E37097_01/doc.42/e35129/adm_mg_service_set.htm#AEADM209 it suggests pointing the validation function to: wwv_flow_epg_include_modules.authorize, and modifying the function: wwv_flow_epg_include_mod_local, within the APEX schema to return true or false depending if you want your procedure to be accessible or not. This unwrapped function is effectively called at the end of wwv_flow_epg_include_modules.authorize if none of the apex procedures matched. If you leave the value of security.requestVal...

A typical usage scenario is you create a region, give it a static ID, and set the default display to be hidden - the latter is handled if you select your region template as modal region. A typical JavaScript dynamic action to display the dialog, would be: $('#dialog-region').dialog({ width: 500, title: 'My Dialog', buttons: [ { text: 'Submit', click: function() { $(this).dialog("close"); } }, { text: 'Cancel', click: function() { $(this).dialog("close"); } } ] }) So the question is, how do we get some other dynamic action to fire when the button is clicked? Option 1 On the button, give it an id property, such as: { text: 'Submit', id: 'btn-submitDialog' click: function() { $(this).dialog("close"); } } And then, on your dynami...

If you are on a slow connection like me, you may find how much of a pain it is deploying apps that house some BI publisher report templates. It only takes a few templates before your app export becomes 10MB+ in size. Perhaps in a future release, report templates will be treated in the same way as application images, in that you can add them as a script to supporting objects so that you don't need to export the templates each and every deployment. If you haven't seen, apex_util has a procedure to download report queries, so by using that procedure coupled with storing your files in your own maintained table, you can avoid the issue of massive application exports. First create a table to store the templates: create table rtf_template( code varchar2(25) PRIMARY KEY , layout BLOB); / Then, add your template file to the table. We will need two application items (or 1 will do if you identify the layout with exactly the same name as the query). So I've created: ...

When you submit the page, you will typically have page processes that run. For me, I use these request values to determine which processes are run. This is rather straight forward for on submit processes as you can just specify the condition request = Expression 1 Or, if you have multiple requests that link to this process, Request is Contained within Expression 1, and Expression 1 would be a comma delimited set of values. Request simply refers to the bind variable :REQUEST (or apex_application.g_request). If we try and do the same on a page rendering process, we no longer have access to this value - which makes sense. If you update the branch, to set the request portion of the URL, we will then be able to access the bind variable :REQUEST in all page rendering processing points. This has the obvious downside that if the user wants to reload the page,  clicks in the address bar and hits enter (or clicks refresh), the processes on that condit...

Before APEX 4.1, if you wanted to add more complex validation using PL/SQL, you would have to do a loop through the apex_application.g_f0x array and act accordingly - as per:  http://docs.oracle.com/cd/E37097_01/doc/doc.42/e35127/apex_app.htm#autoId2 Aside from validations, you may want some process to do something with values before deleting/updating/creating. Apex 4.1 introduces some new substitution strings: http://docs.oracle.com/cd/E37097_01/doc/doc.42/e35125/concept_sub.htm#BEIIBAJD APEX$ROW_NUM - the row number being processed APEX$ROW_SELECTOR - If a check has been marked in the checkbox (value will be 'X') APEX$ROW_STATUS - C if created; D if deleted; U if updated I wasn't really sure how to work with these, and nor did I really investigate, when I first saw them in the builder guide. A recent thread in the forums, and it all makes sense! With these changes, you no longer need to deal with the array, but instead can just refer to the above subs...