“Thinking is easy, acting is difficult, and to put one’s thoughts into action is the most difficult thing in the world.”
— Johann Wolfgang von Goethe
Now that we have the visual portion of our widget all laid out the way that we want it, it’s time to crawl under the hood and start laying down some code that will make it all work. The easiest pace to start on that would be client side code. There isn’t that much of it, since the bulk of the action will take place on the server side, and it is all pretty basic standard stuff. For the most part, the client side code is just there to handle the various button clicks and to kick things over to the server side for processing.
The first button click to handle will be the save buttons on the initial data entry screen. There are actually two of them, but only one appears on the screen at any given time, and they invoke the same client side function. Here it is:
$scope.save = function() {
c.data.phase = 0;
c.data.action = 'save';
c.server.update().then(function(response) {
if (response.oneTimeCode) {
c.data.oneTimeCode = response.oneTimeCode;
c.data.phase = 2;
} else {
c.data.phase = 1;
}
});
};
Before throwing things to the server side for processing, we first set the phase to 0 and the action to save. This will control the logic flow on the server side, where we do all of the actual work. Once the server side code has completed, we check for the presence of a one-time code in the response, which basically tells us that all went well and now we are in the process of verifying the email address. If we don’t get a one-time code, then something went off of the rails, and we kick the phase back to 1 to start the process all over again.
The next button click to handle is the email verification, which we can do right here on the client side, as we are now in possession of the one-time code and we can compare that to the code entered on the screen. If the codes match, the we advance things to the set-up process, and if not, we just leave things as they are until the correct code is entered or the process is cancelled.
$scope.verify = function() {
if (c.data.security_code == c.data.oneTimeCode) {
c.data.phase = 0;
c.data.action = 'setup';
c.server.update().then(function(response) {
if (response.validationError) {
c.data.phase = 1;
} else {
c.data.phase = 3;
}
});
}
};
It is still possible at this point for things to go south, so we have to check for that as well, and once again, cycle things back to phase 1 if there is a problem. Otherwise, we advance to phase 3, which simply hides the email verification screen and reveals the set-up completion confirmation screen.
The last thing that we need to handle on the client side is the Cancel button. I just stole this code from an earlier project, and it just returns you to the home page of the main UI if you are in the main UI, or returns you to the home page of the portal, if you are running in the Service Portal.
$scope.cancel = function() {
var destination = '?';
if (window.parent.location.href != window.location.href) {
destination = '/home.do';
}
window.location.href = destination;
};
The only other code on the client side is a simple check to see if the server set an initial phase, which can happen if you try to run the set-up process more than once. Here is the entire client side script, with everything included:
api.controller=function($scope) {
var c = this;
c.data.phase = c.data.phase || 1;
$scope.save = function() {
c.data.phase = 0;
c.data.action = 'save';
c.server.update().then(function(response) {
if (response.oneTimeCode) {
c.data.oneTimeCode = response.oneTimeCode;
c.data.phase = 2;
} else {
c.data.phase = 1;
}
});
};
$scope.verify = function() {
if (c.data.security_code == c.data.oneTimeCode) {
c.data.phase = 0;
c.data.action = 'setup';
c.server.update().then(function(response) {
if (response.validationError) {
c.data.phase = 1;
} else {
c.data.phase = 3;
}
});
}
};
$scope.cancel = function() {
var destination = '?';
if (window.parent.location.href != window.location.href) {
destination = '/home.do';
}
window.location.href = destination;
};
};
That takes care of the easy part. All of the real work is over on the server side, and there is actually a lot that needs to go on over there, and much of it outside of the scope of the widget itself. That is undoubtedly a multi-installment activity, but we will start taking that on piece by piece next time out.
