You will be amazed how easy it is, try to follow these 10 points:
1. Use the wizards
In APEX you can build up pages manually or by using the Create Page wizard. Usually the wizard is way faster and will build all pages in the same fashion. This helps in achieving a consistent look and feel of your application. It also does some extra work by adding a page to the menu, creating breadcrumbs, and so on.
Sometimes it is also faster to delete an existing page and rebuild it through the wizard, rather than adding new fields manually, ie. when the underlying table has changed.
2. Stick to the standard Oracle APEX functionality
By using APEX wizards you automatically use standard functionality. As such this will have the highest probability to work flawless also in future versions of APEX. Once you deviate from the “APEX way” of doing things, you will slowly drift into a potentially unstable application.
Wow, that sounds cryptic, right?
Here is an example: when you create a form page in APEX, you end up with a default Automatic Row Fetch process on process point Before Header. You now could decide that process point “After Header” is so much nicer and move the process over there.
With a bit of luck your application still works, but might break at some point in the future because Oracle APEX adapts its behavior and decides that this Automatic Row Fetch process has to run “Before Header”.
3. Use settings
Let’s take the “Server-side Condition” as an example. It exists for almost all component types and decides, whether a component is being available/processed, or not. As condition type you can choose a myriad of different options like “Item = Value” or “Request = Value” or “PL/SQL Expression”, where PL/SQL Expression should always be the last resort, as all other declarative options are actually faster processed.
Using a setting rather than coding around it has the advantage of being stable. If a future Oracle APEX version introduces some changes, those declarative settings will be adapted to continue to work.
4. Avoid custom code
As with the settings, custom code should always be avoided, where possible. Why is that? Every single line of code has a certain cost associated to it: you need time to write this code, to fix this code, test this code, and to maintain the code in the future (APEX/DB/… upgrades).
5. Use plugins
Plugins are a great way to extend Oracle APEX and teach it new tricks. Need a new chart type? A dropzone file upload functionality? Extending the Interactive Grid toolbar? A multi-column LOV? These and many more plugins can be found on apex.world or with commercial providers like our FOEX Plugin Framework, or the APEX SmartPivot Plug-in.
In APEX almost everything can be extended as a plugin, which is also a great way of modularization to re-use code. Writing plugins isn’t too hard and there are many great examples among all those open-source plugins on apex.world. So it is absolutely possible for everyone to look at an existing plugin and change it to fulfill your needs.
6. Leave UI fidgeting to the end
Especially for beginners who often try to accomplish a certain look: don’t get hung up on that and leave it be until everything else is done. Then ask yourself if it is really vital to achieve what you have in mind.
The APEX Universal Theme is pretty awesome and provides an up-to-date and modern web look. It also gets updated with each release of APEX and introduces additional features. That means the feature you are looking for might be introduced in the next version. It can also mean your handcrafted workaround (custom CSS) might not work anymore in the next version.
In case you don’t know what’s already possible, take a look at the “Sample Universal Theme” Packaged Application, which can also be accessed via apex.oracle.com/ut
7. Stay lean
This is more a general advise, rather than APEX-specific. You might be confronted with lots of requirements and you try to (over-)achieve. Take a step back and start with a minimum viable version of your application. Show it to others, customer, business unit, and take their feedback. It might already be doing what they want. And this way you can avoid to implement too many pages and features.
8. Reduce complexity
You know this one: let’s say there is a requirement for a form. And another one for a very similar form, with just a few changes. And maybe a third similar form with some additional unique behavior. Which way do you go? One form to rule them all? Or three very similar forms?
This is a tough nut to crack. In retrospect, after being caught in this trap myself quite a few times, I’d say go for the multiple pages/copies route. It seems to be a waste and duplication, but it also allows for very simple duplicates. Once a single case changes, you only have to adapt this one, not the entire (huge and complex) form.
9. Forget your past
Have you just started with Oracle APEX? Are you coming from some other background than web apps on top of databases? Chances are, that your existing experience and expectations influence what you want to achieve now with APEX. Don’t try to replicate Forms, don’t think of Excel, don’t mimic Notes, Foxpro or whatever.
Clean slate, new start. Use the right tool, but also use the tool right!
10. Question requirements
Business units or customers often wish for things they actually can’t comprehend. They don’t know if what they want is feasible, easy to achieve, within the technology limits, or even simply physically possible. Maybe they don’t know yet, that the old client-server days are over and we can now offer different solutions.
Go back and ask them about the requirement(s) and show them some APEX beauty. They might like what they see and forget about old stuff.
What else would you add to this list?