Over the years while developing Oracle APEX
application, I noticed in every application I was following the same steps. It was a routine I followed over and over. For example: in every application I created a global page (page 0), enabled Feedback, ran the Advisor multiple times a week, used certain naming conventions etc.
A few years ago I wrote those steps in our APEX R&D
development guide, so within our team we would be consistent. Just like the database best practices
, I thought it would be a good idea to share the APEX best practices
with you as well. There are about 9 pages, here's a screenshot of the first page:
I don't like too many rules, but a few are good to have, especially when you get new people on board or when the customer is working together with you. As I said in my previous post where I described our database guidelines, the guidelines in itself is not meant to be "this is best and you have to follow", it's more something to start from which you can adapt.
Based on those guidelines, we created a "starter application", so you get a head start in your project. The app in itself wasn't spectacular in itself, it contained the global page, feedback, some administrator pages which give statistics of your app, some application items, error handling package etc.
If you know what you have to build, it wouldn't even take that long to build it from scratch. I just don't like to do repetitive things, I far rather concentrate on the real solution, so anything that can help, I will embrace :) I also won't hesitate to take some components or solutions from other projects and reuse those. But just one piece of advice, always check if what you've been doing before, is still valid today and "the best" way of doing it -for your current problem-
. For example if you developed something in APEX 4.2, maybe in APEX 5.x there's a build-in package to do that. Or the other way, that a feature of APEX became deprecated (e.g. apex_plsql_job) and you should use a database feature (dbms_scheduler).
In 2015 I also gave a presentation at some Oracle conferences how I developed in APEX 4.2 vs 5.0, which you find here
So I could use my starter app for this project, but just as with Quick SQL (to create your database objects), there's a new feature in Oracle APEX 5.2 that will make the starter app irrelevant, so I will cover the new way of doing something in 2017 and further.
The new way of building an application, is to start from a "Blueprint". The concept is very similar to my workflow previously, but now it's built-in the APEX Builder and it's more powerful as it allows to customize the features you want to include in your app.
Blueprint is at the time of writing only available in Preview mode (since March 2017) through apex.oracle.com
and will probably undergo some more changes. I see a lot of potential in this feature. It's not only the wizard you can use, rumors are you can also use JSON syntax to define your app.
Here's the video I recorded where I give a bit of background and you see me using Blueprint:
At the time of writing Blueprint isn't finished yet. Not sure what the end result will be, but although there's still a lot of room for improvement, it already looks spectacular. As you could see in the video, I will use it as my starting point for my multiplication table project. I've exported the app of apex.oracle.com
and imported in my Oracle Exadata Express
environment. Next I'll make changes to this app and customize further.
Blueprint is (or will become) the fastest and most low code way to build an Oracle APEX application.