APEX Page Numbering

Today while perusing posts in the #orclapex hashtag, I came across this from Christina Moore.

#orclapex Get lazy managing menu lists with sql. https://t.co/ai7264cldn

— Christina Moore (@cmoore_sp) May 4, 2016

She hasn't been blogging long but I love her style and format. I found this one on classic report templates a great resource, though I wish the Oracle team would produce content like this to accompany the documentation, or as an extension to apex.oracle.com/ut

Anyway, back to the tweet. The post she links is about planning page numbers. It had me intrigued because I do like sourcing menus with SQL direct from the APEX dictionary. My long standing top post includes a SQL pattern I use regularly to populate APEX menus.

With respect to Christina, I would like to nitpick with some points, or at least offer my perspective.

Planning page numbers

I consider myself to be a page number pedant, and why not? I'm sure we all named our Oracle Forms .fmb files in such a way to have a useful order in the folder, even though a search facility was available.

Why not do the same for APEX page numbers? I like to group my generic popups together in the lower end. Admin pages surrounding 101. Then segments of the application are grouped in 20s, 30s, 40s etc. A report/form combination is handy together since the next/previous page buttons are useful when jumping between the two, as Christina also describes.

I've even found use across applications where pages with similar functions share the same number, making it even easier to jump to the page I need. Christina mentions this when copying pages. Consistency is always a winner.

Page Grouping

Unless I've been really serious about page segmentation, I couldn't see myself applying a condition with a bounded range of page numbers such as
:APP_PAGE_ID between 100 and 200
I find this akin to hardcoding, something Steven Feuerstein could rabbit on about for days. I typically use Page Groups for times I need to identify a set of pages, in part because you're essentially documenting the pages by categorising them. Inherent, inline documentation that can be found by the next developer.

Using page groups also lends itself to building menus out of SQL, potentially in a hierarchical manner.

Conditions

I also find the use of sys.dual superfluous in cases like this, to a point where it's like rubbing hair the wrong way.  All that's required is a simple PL/SQL expression (as shown above), and declarative if possible.

The Alternative

Instead of defining a process to number your pages, you could just let APEX find the next number for you. For playpen applications or those under a hundred pages, that's probably fine. Even then there will come a day you regret not forming some assemblance in your pages.

(Bert Myers)

Organisation is only human. Such abstraction has enabled our species to plan crops, track livestock, leap ahead in our understanding of the universe. Heck, nature has been doing it for over 500 million years.



... too profound?