Tuesday, August 9, 2016

Coding standards in Oracle Application Express

The problem

With many clients the same problem often arises in different situations, different company contexts but the root of the problem stays the same, whether it's about big data, PL/SQL back-end stored procedures/interfaces, Oracle Forms or Oracle Application Express, and so on... : the coding standards are often horrible. Not two companies use the same standards. What, for instance, is a good prefix for a variable name? l_variable, v_variable, lv_variable, ln_variable, ... or for a cursor. cur_emp, c_emp... a record structure? type_book, book_type, book_typ, ... v_book_type, t_book, ... I have seen them all, even mixed... "Oh, but we have some document somewhere on our network drive describing standards", yeah sure, but how much of it is being applied in the actual code? Application Express, being even to this day still often (unfairly) downgraded as a basic tool to create rapid application (wizards) without complexity... click, click, click, ready, is raising in popularity. It gets a better and better of a reputation nowadays, and it is not just for rapid development. but for complex web applications.

Application Express

Application Express allows you to create whatever web application you can imagine. There is no need to think that you'll better rely on Java NetBeans or Microsoft's ASP.NET framework if you think the business is "too complex", despite it being promoted as a "rapid tool". Nothing is "too complex" for Oracle Application Express. You don't even need a separate license, unlike Oracle Fusion Middleware. The thing is, you'll need coding and working standards and... these are two scenarios I've heard of:

Some companies use MVC, which is, in my humble opinion, a good way of applying patterns in APEX, but just do not over-engineer it. What I mean by that is that it is a great idea to separate business logic and GUI, but keep in mind that your core is still PL/SQL, a 4GL language, not a 3GL like Java or C#. The line between data layer and business logic layer is much thinner in a 4GL like PL/SQL, so separating that entirely may create a lot of unnecessary overloaded functions and procedures. The idea of calling GUI packages from the APEX engine and call BL packages from the GUI packages is great though.

Some companies use no standards, which is in - also my own humble opinion - not recommended .... and that is, by the way, an understatement. 

Many tutorials show you examples of PL/SQL code (anonymous blocks) in APEX page rendering/processing processes. Do not do this; use packages. You'll thank me later. ;-)
In a large environment it is even recommended to use a different schema for each application.

A great way to build your GUI layer is to create a package for each page in the application, e.g. "SCHEMA.GUI_PXXX_CONTEXT" where CONTEXT is a description. APP1024.GUI_P100_INPUT_ORDER is a good name. All PL/SQL code on that page, for processing, rendering, dynamic actions, validations ... can use the package's procedures. The name of this package immediately leads you to page 100 in application 1024. The logical components come in a business layer, for instance: APP1024.BL_MANAGE_ORDERS.

You are not alone

If you have questions while learning or developing in APEX, remember you can always check APEX Discussion Forum, one of the most active communities found on OTN. If you cannot find your question you can post a new question and you'll get it answered in a short time. I am amazed how people in this era of social media still use books and print-outs to find their answer to a question, Use these social media to your advantage!

Search This Blog