APEX Thoughts and Findings
PDF & Word doc creation in APEX
Alternative (non-BI Publisher) approach for pdf http://www.plpdf.com/
Word document generation approach
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.
Calling out to Web services
Forget all the existing tooling in this area. Just use utl_http and SOAP, in PL/SQL crafted by hand.
Use this fine paper as the basis for a staff training session
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.
Dividing the job up
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.
All that cache option stuff
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/
Unit Test tooling
Version control tooling
Interface testing tooling
Code quality checking tools
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
- EXTjs http://www.extjs.com/
Printing from a browser
Big Public Sites
More thought needed
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.