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#orclapex Get lazy managing menu lists with sql. https://t.co/ai7264cldn— Christina Moore (@cmoore_sp) May 4, 2016
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 200I 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 ofsys.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) |
... too profound?
No comments:
Post a Comment