I have noticed (too) often when talking to other APEX developers, that the Advisor functionality is not well known.
Although this is also described in a lot of Best practice guides, the functionality is in my humble opinion highly underestimated!
The APEX Advisor
I actually don't know how long it's been there, but it is quite some time.
And it's all standard and included in the APEX Application Builder.
It is to be found under Utilities.
It kicks off following popup window
I recommend to have a look at the section Checks to perform:
It may well be possible that you have opted for whatever reason to not follow one of the pre-defined rules of the APEX Development team. You can chose not to check on those rules.
Usually I advice to select all checks and read the advice of the Advisor. You can always opt of course not to do anything with one of the remarks. Because one thing must be clear: your app can run very fine with several Advisor errors or warnings in it. You do not need to fix them all. But it is advised to solve as many as possible and you may learn something from the best practises according to the APEX Development Team. They're smart people ... believe me ;-)
Depending how large your app is - of course - running the Advisor may take some time.
In the end it provides you with a clear overview and with the option to navigate directly to where you need to be to fix the problem.
The result filter
The filter comes in very handy to keep an overview or to focus on one specific type of error (or warning).
An advisor error
I'm not walking you through every possible error an Advisor can identify.
For each error/warning the Advisor will give you an overview of what he thinks is wrong or can be done better.
With the View button you navigate directly to the place in your application that concerns this hit.
He doesn't know everything
An example of errors an Advisor run is always indicating is the following:
What the Advisor cannot see here, is that this "EVENT_LINK" is part of a specific template. It's not necessarily a real error. So these errors can be ignored.
So okay, here you go. Hope to have convinced some developers to start using it. It's really a good practice to run it at the end (or beginning if you prefer) of every working day!
Have you ever been in a situation where you have two date fields and the second one is dependant on the first one? Sure you have!
Every time you do something with a start- and end-date ...
It's so very logic that the end-date must be later than the start-date. As long as we can't travel in time, this is a certainty.
Example
As often, my examples originate from the HR field.
This example is a page in an APEX app that gathers information for a candidate employee.
The candidate category was identified as 'Fixed Term', which implies you have to provide a start-date and an end-date for the contract.
We're gonna focus now on the Date start and on the Date end.
In the example used, the Date start must be a date in the future. The Date end must be later then the Date start.
When you do nothing
It's obvious, when you do nothing, you allow input of all dates.
I'm writing this blog post on November 21st. You can see I'm allowed to enter a date in the past for a Date start:
Same thing for the Date end. Even worse: I'm allowed to enter (pick) a date before the Date start:
Which results possibly in something like this:
What about validations?
Yes, of course, you can use validations to force the user in entering the correct dates. But those validations are executed on page submit. That's a bit too late, don't you think? So read on, it gets interesting now!
Known and standard features of APEX
To start of, we're gonna use a standard APEX feature to make sure the Date start is a future date.
A small notice here: a "future date" in a data entry application may not be clear enough as a spec. Because when reading "future", it will be checked against the system date. So when entering a date today, save the information and update it tomorrow, this system date has obviously changed. So make sure you get the intention of your customer clear! In our example we simplify and acknowledge that we're validating purely against the system date.
First identify the Date start:
Go to the property panel and have a look at the Settings section:
Three options here: Highlighted date, Minimum date and Maximum date. They all operate similarly. Actually the APEX Help explains it quite clearly:
We're now making sure that we highlight the current date (sysdate +0 days).
Same for the minimum date. It will make sure that you cannot pick a date in the past!
Yes!! One down.
We're now at this stage:
You're unable to pick a date in the past!
Also note some other interesting properties for datepicker fields, like e.g. the Show other months (Y/N) property. I suggest to try them out, but it's not the subject of this post ...
You can now do the same for the Date end. However, it will only enforce the user to pick a date in the future. What if the Date start is entered for December 1st (remember, the system date right now is November 21st)? You can still enter November 22nd for the Date end. Not what we want!
Full solution step by step
We're gonna use some javascript coding to make the relation between the Date start and the Date end.
However it's been coded in a way that it can be any two date fields on the same page.
Page level functions
In the page properties, navigate to the JavaScript section.
Two functions need to be included here:
function stringToDate(_date,_format,_delimiter) {
var formatLowerCase=_format.toLowerCase();
var formatItems=formatLowerCase.split(_delimiter);
var dateItems=_date.split(_delimiter);
var dayIndex=formatItems.indexOf("dd");
var monthIndex=formatItems.indexOf("mm");
var yearIndex=formatItems.indexOf("yyyy");
var month=parseInt(dateItems[monthIndex]);
month-=1;
var formatedDate = new Date(dateItems[yearIndex],month,dateItems[dayIndex]);
return formatedDate;
}
function setMinAndMaxDates( fieldnameStartDate, fieldnameEndDate, maximumLengthInYears) {
var minDateAsString = $x(fieldnameStartDate).value;
var selectorEndDate = apex.jQuery("#" + fieldnameEndDate);
if (minDateAsString == null || minDateAsString == '') {
The first function (stringToDate) will need to hold the date format that you use. Generally accepted in my neck of the woods is the format "dd-mm-yyyy". So you will need to adapt this to your own setting. Or when you allow the user to pick the date format in a preference page, you will need to make this function more flexible as well!
The second function (setMinAndMaxDates) will actually add the needed attributes to the page items on the fly.
As you can see, the function accepts 3 parameters. The fieldnameStartDate and fieldnameEndDate refer to the page items you want to refer to. This makes the use of these functions very flexible. And you can just copy and past it over to any other page in your app.
Dynamic action doing the magic
As so often is the case, here again the dynamic action will do the magic!
In the use case described here, "something" will need to happen to the Date end when a date is picked in the Date start.
Logically the On change dynamic action is used on the Date start.
Following properties are set on Dynamic action level:
And because the functions are coded generically, the javascript in this TRUE action remains extremely simple:
As soon as you pick a date in the Date start datepicker, the Date end gets defaulted to the same date.
Date end
No dates can be picked before the Date start.
Here you go .... all done !!!
Oh no ... there is a "but"
Yes, the user gets guided perfectly when using the datepicker. But he can still pick a date and then change it manually!
My conclusion
So it doesn't take away all your pains. But it does support your user in the best possible way. And because that user can still manage to make things wrong, you should also provide the validations on page submit.
But I hope you agree with me that it is a nice way to help the user with the data entry.
Credits
For this blogpost I must specifically thank my colleague Joost Hoevers, as he has coded the nice solution and made it perfectly re-usable!
this is just a quick note. Seems logical, but YOU have to take care of it!
Recently I uploaded an APEX export file from an app that my colleague had created.
I just wanted to check something he had done, so I uploaded the application in my own workspace. That's a workspace I use to quickly check something or do some research on.
It is however on the same database that my colleague is using to develop this particular application. And his customer is actually looking at that environment as well during the development phase.
So I uploaded the the export file and installed the app, accepting all the defaults there are when you import and install an APEX app.
But what I didn't know, is that APEX is NOT changing the application alias. Something that is done when you import an app that got exported from the same workspace. I believe it adds the new application ID to the alias.
But since this app came from a different workspace, it nicely installed it with the existing alias, causing the original app to fail.
So I just wanted you to know ... I will never forget this. And you may learn from my mista ... well ... from my experience! ;-)
This is something I shared quite some time ago (back then it was APEX 4.x, but it's still valid) on another forum. But I got the question back lately. So, here I am back with the same message ....
An integrated Apex App with Oracle E-Business Suite (EBS) has an unfortunate side effect concerning Interactive Reports.
Some of the settings of such a report is easiest done when running that report as a developer and then save it as Default and Primary Report Setting. So everybody who runs the report gets to see it the way you - as developer - has saved it.
When you execute the Apex app from within the EBS, the user you're using to connect to Apex is inherrited from EBS and as such not an Apex Developer user. Consequence: you are not allowed to save your IR as Default setting!
The trick around this to logon to Apex builder (as developer obviously) and to the EBS with the same browser session. Then launch your app via EBS. So the app opens in the same browser as the one used by your Apex builder.
In your app you have now the oportunity to use the edit-bar (at the bottum: "Home" / "Application" / "Edit page" / .....) and ... most of all, you can in this session save your reports as default (and primary) setting. Which is the solution of the problem.
In many applications the result of a page submit is the creation of one or more lines in some database table(s).
When these processes become heavy and have to take a lot of business
rules into account and that perhaps in combination with sometimes not optimal
network trafic, it may happen that the user doesn't see that APEX is
processing his stuff.
As a result he or she may become impatiant and start hitting that Save button over and over again ...
When this results in multiple occurance of the record in the database,
this creates data inconsistency. Something that every developer is -
quite rightfully - scared as hell for.
There are some ways to prevent this behaviour from happening.
This blogpost is about preventing those double entries. But while doing my research and in fact the winning tip for the solution was coming from my good friend and APEX mentor Dimitri, I found a very nice extra.
Did you, just like me, wonder how the APEX Builder has this spinning wheel showing up when saving your changes? And could you, just like me, not figure out how that was done? Well ... just read on!
So here's my business case.
A reasonably complex APEX page has a couple of buttons:
Cancel - needs no explanation
Save - simply writes the entered date to several tables in the database
Finalize - does the same things as "Save", but also starts an approval workflow process
In our case, this Finalize was the issue.
Kicking off that workflow requires some business logic, some validations, well, it's a process that wasn't done in milliseconds.
Nothing was done on the APEX page to prevent the page from submitting multiple times. And nothing was done to show the end user that a process was running.
The only thing: when the process was done, then a message was shown, something like "Well done, your request has been sent to your manager".
The first week after go live of the system, we noticed that our end users were much more impatient then our test users. Because they didn't immediately saw the result of the 'press on the button', they started hitting that button multiple times. And so submitting the page multiple times. And so creating the same record multiple times.
So let me show you in this very much simplified sample what was the first setup of the APEX application.
The old way
Nothing was done to prevent double entries at all.
Base table used is hr_employee. And it contains some very basic personnel information.
Only 1 record in there before the exercise:
On this table a form with report was created.
So I start hitting this Apply Changes button like crazy and it's almost impossible to mimic the customer's case with this simplified example.
But believe me, it happened and let say Mr. McEnroe is created twice in the db.
An important setting to keep in mind in this example is on page level
This setting can allow or prevent the page to be resubmitted multiple times. This feature was called into place to prevent a page to be resubmitted e.g. after a page reload in the browser. Or when hitting the back and forward button of your browser.
So ... there is our first clue!
The button (Save and Apply Changes) are both performing a Page Submit.
One step up and prevent page from being reposted
So I could redo all the steps as described above, with this option set to "No - Prevent this page from being re-posted". But I'm not gonna, because you will not see the difference, except for this one single setting:
In most situations this setting will save you. Although, if you remember the customer case, this setting was already set to prevent the re-posting.
So our example wasn't about being reposted or not. It really was due to multiple submissions. It was like the process was launched a second time, before the first time had come to an end.
There are other reasons why we could assume this, because at some point in the process it was checked if a request could be approved and then some status was changed so the same person could never approve twice the same request. Because this little piece of functionality was in there and it had never occurred during test cycles, we were pretty confident that we had built a safe system.
Until ... one week after go live the customer came back to us and said: "multiple occurrences of the same record exist, created within less than a second from one and another. Please help!!!"
And then, the main test user had a brilliant idea. She sat down behind her computer, opened the specific page, entered some data and pointed the button and started clicking it like mad.
And there it was ... not two or three, but at least nine or ten records were saved to the db.
So we needed another solution. And when I ran out of ideas, I called a help line.
Disable the button after having pressed it
The solution is as easy as it is simple. Prevent the the button from being pressed more then once.
In example one and two, the process was launched upon page submit. The button basically submitting the page.
Compared to both examples above, the change is with the button definition. No longer use the Page Submit, but set its behaviour to Defined by Dynamic Action.
Note: in this example we need the Database Action. In many cases you will not need that, but you will launch your actions via a page process.
Now create the dynamic action:
First DA True Action:
Disable the button, making sure it is NOT fired on Page Load (by default it will fire on Page Load).
Finally add a second DA True Action:
To stick to the original behaviour, it's quite simple: just perform a Page Submit and set the Request to the Button name (Create). This is important, otherwise the defined page process that was previously directly linked to the button, will not be fired.
For the Page Submit obviously the default is set that the action should not fire on Page Load.
And look what came with this solution for free!
Yup ... the spinning wheel. There is that very nice extra that I was talking about in the introduction.
From now on - until further notice - I believe this will be my standard way of building an APEX page that submits something to the DB.
I will no longer submit the page directly from the button, but will have a dynamic action do this, after I have disabled the button.
Also when you stay on the same page after the process is done, you do not need to enable the button again. Your Page Load will do this for you.
For me this really was an eye opener. For so many years I was used to write as much as possible in page processes that got fired on Page Submit.
I even made a habit out of it to - when possible of course - only write something to the DB after a page submit.
And it never occurred to me to do this in another way than via the button behaviour "Submit Page".
As simple as it may seem and as logic as it in fact is ... I only discovered this recently. I don't know if the APEX Builder is using the same method, but it looks the same. And that's good enough for me ;-)
Just a note, more for myself than anything else. So I quickly can find it back, because somehow I keep on forgetting the command and then I'm spending too much time in finding it back.
So this is what you do when you've created a theme roller styling that you like and want to copy to another (or all your other) apps.
What I typically do is created a style in one app. When it's all finished and approved by the customer and I've gathered all signatures - ;-) - then I run this command in the console of the browser.
Make sure your Theme roller is opened when you open your console of the browser!
> apex.utr.config()
As stated on the prompt, just copy that JSON file and go to the application where you want to import it.
Also there first open Theme Roller and then open the console of your browser.
Simply paste that line and hit enter.
Now your settings are loaded into the Theme Roller of your new app. Use Theme Roller (save as) to save your settings in the new app ...
This is APEX 5.0.1. In APEX 5.0 you have to make a small change to the text and add the "apex." in front when you have pasted it in the new app ...
Somehow I forgot what blogging was. But constructing a house, making it your home and moving into that new home took quite some time and above all energy. So blogging didn't have my highest prio for the last couple of months.
I know, it's just excuses, but as all that is none of your interest, I'll get on with the work :-)
So, I'm preparing a demo / workshop to show people what, how and why to migrate your apps to the Universal Theme (UT) once you did the technical migration to APEX 5.
This is all very well documented by the Oracle APEX Team, fow which many many thanks!
Here's just an overview of what I needed when doing my research. I'll build up the blog post along with my prep.
Migrating to Universal Theme
What is this UT?
So what is this UT and what's all the fuss about it?
Well, these insights from my point of view, not a commercial talk, nor a high-specialist talk. But an every day APEX developer and Oracle specialist.
I believe that my profile of developer is exactly why they have developed the UT to begin with.
I was trained by Oracle in the mid-nineties. This means PL/SQL, Oracle forms, PL/SQL, Oracle Reports, PL/SQL, Designer, PL/SQL and also some PL/SQL.
I have gradually picked up some HTML knowledge. Learned to deal with XML and more recently also JSON file formats.
I've upgraded my knowledge via self-study on CSS, Javascripting and I'm following some blogs on web-design in general. I try to keep up with the latest, which is not always easy. From the web-design/development point of view: I'm an old guy.
So UT for me exactly takes away those deep technical requirements that I'm not specialised in.
Still I urge you to have some knowledge of the web development skills mentioned above. But UT will help you a lot!
And there is one more thing I like so much about the UT:
as developer we can come up with great ideas of what an app can/should do. We're also capable of actually building just that. But what about the design, the user interface? It's often not our strongest skill. I know it's not mine. On top of that: I'm color blind. I literaly see things differently than other people.
Now with the UT, they can build the app and don't bother too much on the color schemes. Because it can be changed once you're done developing. Or during development. There even is a Theme Roller which allows you to change colors of the objects and it picks colors that fit together. More later, but ... honestly: WAW !
Other than all that, there are a number of reasons why you should migrate to UT. Or at least try to, because there are also some down sides. But all this is well explained in the Oracle documentation.
You may have good reasons to oppose against UT. Perhaps you have invested a lot in your own custom theme. With lots of nice looking stuff in there that works just as you want it to.
Although perhaps UT has those customizations built-in standard, it will take an effort to match and align them. Not even having spoken about the testing efforts after migration.
UT follows the latest stuff in web design. Certainly concerning navigation it is quite a change to the old style of navigation. But what if you actually like that? Perhaps you or your users are not so keen on change?
And another important - if not the most important - reason why not to migrate: you have invested already a lot in development of the app(s) in the first place. Now you have to invest in those same apps.
Bottom line: think about these things upfront and discuss them fairly with your boss or customer.
We as developer probably all wouldn't like anything more than to migrate. Don't forget it comes with a price tag!
Backup there ... slowly, one step at the time
Of course, first backup the app you want to migrate. And also of course, I'm assuming that the technical upgrade to APEX 5 has been successfully done.
One reason to take a backup is the obvious one: it's a backup.
But I hadn't thought of a second one myself until it was pointed out to me: once you have migrated your app to the new UT, it's a good idea to import the old one (with a new APPLICATION ID) so you can run both versions at the same time. And do all your tests.
If there is something you don't like, you can start off again from the original version and migrate all over again.
Probably a good idea to run each version in another browser.
Now let's take it step by step
Basically all I'm doing here is following the steps in Oracle Migration Guide!
So it seams a bit over the top to retype those steps here. and I don't want you to think that I came up with all those steps by myself ;-)
So open that migration guide in a different window or tab and leave it open!
But there are some things you need to know about your old app before you migrate.
UT is far more grid orientated then the old themes. That is, if you had already a GRID theme to begin with!
So take some time to investigate on this.
Another very important one is the TAB-levels used in your old theme. UT doesn't use tabs anymore (thank you very much!) and it the Wizard is not capable of migrating apps that have multi-level tabs.
If this is your case, then first go and adapt the original theme to one-level tabs!
Follow Oracle's guidelines on the migration when switching from old to new.
Match template classes?
The migration guide tells you to switch this option to "No", without explaining why.
So what do I do? Yup, I left it to its default ("Yes").
And it all worked out fine. I was lucky? No, I wasn't ... I just had a very simple app to start off with.
However there must be a reason why they say to switch it to "No".
And there is. It's all the next step: the mapping of the classes.
APEX will try to help you with this mapping. But when this option was set to "Yes", it will only offer templates that are from the same class as the original ones. This will often NOT be the case and you will be left with quite some frustrations when migrating the more complex apps!
So keep control and believe Oracle there ... switch it to "No"!
Map your templates tot the UT templates
Although this is just a small step as described in the guide, take your time here. You even may want to try different versions of migrations in order to find the right settings.
It will save you a lot of time if you do the correct mapping here, rather then just picking one and you're left with a whole lot of individual changes on every page of your app to correct the situation.
Here once more the backup of the original app may come in handy!
Because this is such an important step, I'm taking some more time on it:
So here is a very simple example of an app created with the Blue responsive theme 25.
UT was not created yet in this application before I started.
And this is how the working app looks like in APEX 5 without having migrated it to UT:
So I create the UT in the application.
And I start the Switch wizard.
First attempt with the Match Template Classes set to "Yes" (against Oracle's advice).
Mapping:
Note the mapping options for Standard Region:
This actually is a reminder for you that you have the mapping option set to "Yes". Because see what happens if you go back one step and set it to "No".
You can actually just go back here with the "<" button.
Note the mapping options for Standard Region now:
Already here you should be convinced to set that parameter to "No". Actually, it beats me why the "Yes" exists in the first place and even more why that is set as default. But that's probably just me ;-)
And now comes the nicest part of this step. the Universal Theme Migration Helper.
Today (3rd of August 2015) it's up to version 1.1 supporting themes 21, 22, 23, 24, 25 and 26.
If your custom theme is based on one of these, then certainly pay attention to this section of the migration guide.
I have now added the Bookmarklet to my bookmarks (in my case the browser is Chrome):
For the more complex apps, this will make a huge difference in the mapping proposed by APEX. In my case there's not a lot of difference as my app is a very basic example.
But adding this Bookmarklet is an easy thing to do and you need to this only once. Well, for each browser you're using in case you use multiple browsers.
And this is what it looks like in APEX 5 in Universal Theme:
My conclusion
It's all relatively easy to do. But do your homework first.
Know where you start from.
And thoroughly test your migrated apps on look and feel AND on functionality.
Mind you, now you've only done a migration. You should investigate also if you can replace some custom stuff with standard APEX 5 + UT stuff. A lot of things are in there that weren't in the old themes (or APEX version). You've just taking the effort to migrate, now is the good time to look into the app to see if you can replace/remove some custom work. I strongly believe that it's way better to stick as much as possible to the standards of APEX!
And my advice: try to migrate. It will pay off in the end.
If you have many applications - may be even linked to one another - start with one and see if it still works all together.
And then take it one by one. Keeping in mind that the user interface changes. So apps that belong together, probably need to have the same UI feeling.
Grouping your apps is never a bad idea.
Theme Roller
I promised some more on the Theme Roller.
Well, following screenshots speak for themselves. Id didn't write one single line of code. I didn't know any of the names of the colors used. I just turned the wheel ... very easy to go and find (or create) your company color scheme. And the different styles can be saved and re-applied to other apps.
Before
After(s)
I'm not pretending this color combination is a good idea! Just wanted to point out how easy it is to change it ... :-p
And if you're still not convinced, have a look here:
Thanks for sticking with me up to here :-)
and happy to share ...
