APEX Thoughts and Findings

Seems that to do this properly, we need Oracle BI Publisher
HowTo Whitepaper

Alternative (non-BI Publisher) approach for pdf http://www.plpdf.com/

We capture all to the 'custom content' from the user in an APEX screen. We then call BI Pub to merge in the content. Some of this content is 'rich' e.g. graphs/charts. BI Pub can use Word as the method by which document templates are prepared.

Remaining difficulty is with content that used to be driven by VB-macros embedded into Word docs. Since BI-pub generates to .rtf no such scripting is possible. Will have to explore requirements in this area.

Rationale Sizing

Forget all the existing tooling in this area. Just use utl_http and SOAP, in PL/SQL crafted by hand.

Service example

Google Maps

Use this fine paper as the basis for a staff training session

• SQL Injection proofing

also

• URL Tampering

Oracle Audit Vault for fine grain audit

Trigger based example

So, how do we get started? The best idea seems to be to 'rough up' the main styles of screen that we might need. Forget APEX at this stage. We just use our fave HTML painter tool. Once we have the HTML sorted, we reverse engineer this into APEX templates. Once a first cut is available, we get AT & ergo folks to pop in their feedback.

Rather than have one BIG application, let's consider having a number of modules. Each module is an APEX application. Oracle use this approach when they build the APEX tool itself.

Rather than develop reams of code embedded inside the APEX model. Take commonly used UI components and expose them as PL/SQL procedures. Each proc emits UI elements via htp.p calls. Parameters to the proc can assist multiple use.

There are many options, in many places, across APEX where a level of cache behaviour can be specified. Best practice is to leave all of this at default and have Apache cache commonly used stuff.

The usual deal. Ensure that you dev against a Db with roughly the same number of rows as you will have in production. APEX debug view is good for finding 'hotspots' in pages.

Have two screens per developer. One for the APEX dev environment, the other showing the page being developed. Also consider the use of Firefox with Firebug as a dev browser. http://getfirebug.com/

• PL/SQL unit test - PLUTO
• Continuous build - Hudson and utPL/SQL
• Quest software

Subversion

SOAP Testing Hackability

• Advisor

www.fluent-interaction.co.uk - Hannah Locke

Session handling in APEX is easily configured. Info here.

Transaction management is discussed here. The important thing to note is that there is an implicit commit whenever a page is submitted. This happens when the page returns and your database session effectively ends.

Re locking … reckon that we will use a 'hard' lock table. i.e. this user has this thing locked out to them. Fortunately, we don't have many 'things' - perhaps as few as one. Good overview article here

A very nice Javascript library that can be bolted onto APEX

• EXTjs http://www.extjs.com/
• EXTjs in action http://oracleinsights.blogspot.com/2008/01/demo-website-extjs-with-oracle-apex.html

Some hints re css

Internet Apps

Commercial Apps

General slides

So, what will our most granular unit of deployment be? Some folks (ZZ) have concerns about the use of a 'page export' level method. They recommend 'whole application' (aka module). We gotta try this out to establish the actual situation. The good news is that it seems that the 'APEX model' - as held in the Db is hard to break.

• APEXLib - nice addons for APEX
• More on APEXLib
• Spellchecker and language settings
• Tooltips
• Web based word processor
• FCKEditor
• Postcode lookup
• Rationale for using Tomcat HTTP Server instead of Oracle HTTP Server
• Setting up Apex with Tomcat and the DBPrism plugin
• Apex Packaged Applications - Bug Tracker

• Training videos