APEX Blueprint, YMMV (part 2)

H

How you done things might be obvious to you now, but not you in the future. Not to mention your colleagues. So if you want to avoid being asked the WTF question, think about how to make your code clean and readable.

If you didn't read part 1 about Obvious things + Database rules (tips), please do that first.

APEX Workspace

• Consider using single workspace with multiple schemas on the same instance (it promotes sharing objects between apps)
• workspace files
• access related schemas with grants
• possibility to publish/subscribe to Master app (theme, authentication, LOVs...)
• Put apps into groups, use app numbers to your advantage
• create gaps (for related and translated apps)
• keep similar/related apps close together
• Set workspace color according to the environment type (from APEX 21.2)
• you will need workspace admin for that

Application setup

• Go through all options in Shared components and try to understand them
• Application Definition Attributes
• always use app alias and app group
• use Friendly Url to have app/page alias in url instead of app/page number; you can later change app/page numbers without users noticing it
• use Substitutions for strings you would normally hardcode (date/number formats, classes, icons...), check escaping options
• Security Attributes
• authentication and authorization schemes of your choice
• disable Rejoin Sessions
• enable Deep Linking so users can create bookmarks
• enable Session State Protection, use checksums on sensitive pages/forms
• set init and cleanup code (if you know how)
• Go through templates and their options
• Store styles & scripts in app/workspace file repository, not on the page
• it might be acceptable to do some specific JS/CSS tweaks on the page if it is small and used just on that page/component
• Personalize the App Builder
• add missing columns for pages (auth scheme, build option, comments...)
• remove columns you don't use
• save the report so you don't have to set it up again
• Check Builder – Utilities – Advisor regularly (daily/weekly)
• Check Builder – Utilities – Embedded Code report to review hardcoded things
• Don't use APEX_COLLECTION for everything

Thoughts on pages

• Always use page alias, page group and auth scheme
• Consider using page numbers >= 100 and < 1000, use hundreds for big modules
• 100-899 for application, 100 for homepage
• 900+ for admin stuff, that will leave you with 800 pages for your app
• keep related pages close but create small gaps so you can add related pages close together later
• you can change page numbers if needed
• if you have hundreds of pages in your app, split them into multiple apps
• Don't abuse the page zero, don't put everything here, use it for:
• app items shared through multiple pages (and accessible by JavaScript)
• navigation & breadcrumbs
• footer (copyright, contact info, support chat, site map, links...)
• debug info (for developers only)
• remember that some regions won't be available on modal pages
• When using page wizards keep that in mind that it might set page/component properties in a different way when you start with a blank page
• start with blank page if you can, wizards take shortcuts
• Use (create) LOV in shared components for every LOV you want to use
• don't hardcode the queries
• you will most likely use it somewhere hence save time in a long run and you also have a nice list of LOVs used in your app in Shared Components
• somehow I like redundant LOV_ prefix for list of values
• Use views instead of tables to show data to user (can't stress this enough)
• abstraction level, security... remember the part 1?
• some people are against using APEX items in views; I love it, it keeps my APEX regions clean from WHERE conditions, I just use the reference to the object and keep everything there with all those benefits of compile warnings, dependencies, easier and traceable change...; you can set and get items from PL/SQL
• Use packages to store data from user (forms, grids)
• you can use some TAPI generator to ease the pain; preferably mine :-) but one is even included in APEX, check SQL Workshop – Utilities – Methods on Tables
• when calling procedure/function from APEX never mix positional and named arguments, you might be surprised
• Use Authorization Schemes based on package, not on app items
• store logic in packages, don't use app items to store the results
• use these schemes on pages and components
• tight auth schemes to navigation
• if possible, create also matching ROLES in database (CREATE ROLE)
• Use Error Handling Function to trap errors from APEX and provide users with human friendly message
• Use Build Options to enable/disable some set of features/components
• you can deploy app even with unfinished modules
• or easily remove marked components

Page components

• Be consistent in naming (items, regions, processes, dynamic actions..., static_id attribute)
• a good name is very important and with proper prefix can be better than any documentation
• meaningful names, no useless prefixes/postfixes
• Use prefixes when naming processes
• INIT_ prefix for setting up items (pre-rendering)
• SET_ prefix for computations (pre-rendering)
• ACTION_ prefix for actions (pre-rendering)
• SAVE_ prefix for submit processes (processing)
• GET_ prefix for AJAX callbacks (processing)
• CHECK_ prefix for validations (processing)
• Use prefixes for static_id on page components (except regions)
• just REGION_NAME for regions (no prefix)
• BUTTON_ (or BTN_) prefix for buttons
• For page/form items keep the P#_NAME format
• use matching column name whenever possible
• item placement is also important; I like using Hero regions above every data region for related items not to mix them with data (form) items
• For global/app items use G_NAME format
• For page 0 use P0_NAME format, use items on page zero if you need to access them in JavaScript, otherwise use application items

Verify your code

I usually have a lot of interactive grids in my applications, so I created an alternative report on Page Regions to check if all grids are properly set. I have check for grid attributes, for columns (if they need sync or not) and for grid handler setup. With many additional columns.

You can create your own reports to check if you are consistent and comply to your set of rules. You can check pages, regions, various components like items, buttons, DA... Almost everything is available through APEX views. The magic word is: APEX_DICTIONARY. Explore it.