| JavaScript in HTML Areas | KEVIN RESCHENBERG
04-21-2014 |
My last post showed some CSS examples and then briefly showed how to incorporate scripts into your pages by using an HTML area.
This technique is useful but there are a couple of important considerations.
Let's first get this one out of the way: Is it safe to use JavaScript? What if your user has JavaScript disabled in the browser? PeopleSoft relies heavily on JavaScript
and nothing at all would work in that case, so don't be concerned about this. Yes, it's safe to assume your user has it enabled.
JavaScript in an HTML area potentially gives you access to everything you see in the page source. But take baby steps. If there is an error in your code, it can have
unpredictable effects on the rest of the page. I find it best to write a small piece of code, test it, and then go on to the next piece. If there is a syntax error
in your code, you often will not be able to find it easily. (You may see an impossibly large line number for the line in error, for example.) If there is an error and you
can't find it, a quick and dirty way to proceed is to place alert() calls in various places to see where the JS interpreter trips up.
Controlling page elements
Take a look at the page source. Elements with IDs can be manipulated by your code. You could move them around, change their style attributes,
attach event handlers, or even completely
rewrite them using innerHTML or outerHTML. If an element does not have an ID (because, frankly, PeopleSoft is using IDs for its own purpose
and not to make it easy for us to rewrite its generated code!) then you can usually still access it through HTML DOM properties such as nextSibling.
Be sure that your script is located after the point where the element is defined or your script will not be able to find it. Or you could fire your code after the
page is ready by handling an event—but that's a little out of scope for this introduction.
Ajax processing
PeopleSoft uses Ajax techniques to make pages more responsive. If you uncheck the "allow deferred processing" checkbox on an object then it will react to input
immediately. In the past this meant posting the page, waiting for the app server to rebuild the page and rendering the new page in the browser. Now the process is more efficient.
In many cases the page remains displayed and only the relevant parts of the page are updated. To support this new method, PeopleSoft made a choice that might be unexpected.
All of our JavaScript is captured and replayed each time something happens on the page. So for example if you have an input box without deferred processing (so that it
reacts immediately to input) then as soon as you tab out of the field your JavaScript is rerun. I think—just wild uninformed speculation here—that this is
an attempt to preserve the function of pages designed before Ajax came around. In the past, any trip to the server would cause the entire page to be redisplayed and, of
course, all JavaScript to be rerun. With Ajax the page is not redisplayed and scripts normally would not run again. I'm guessing that having Tools capture and rerun the
scripts is just to make things work the way they used to.
Now, you may not want your scripts to run multiple times. Here is one way to prevent that. It's an ugly hack and I'm not claiming that this is the only way but it seems to work.
<script type="text/javascript">
var x;
if (x === undefined) {
// This is the FIRST time. Do something here.
x = "";
}
</script>
Commented scripts
If you want to comment out a script, be careful of this next little gotcha. As I mentioned above, your code is captured so that it can be rerun. Tools just looks for
"<script" and starts copying. That means that even if the code has been commented out, it will still be saved and run later! The way to prevent this is to be
sure that the string "<script" does not occur:
<!-- Comment starts here but Tools doesn't know that
<script type="text/javascript">
// CAUTION: This script will run even though it is commented out!
</script>
-->
<!--script type="text/javascript">
// This script really is commented out and won't be run
</script-->
Don't pollute the global scope
My use of variable name x in the example above was a poor choice. This is a global variable visible to all of the code on the page. We don't know—maybe
PeopleTools uses a variable of the same name for some other purpose, and we have just overwritten it. There are many ways around this. Google "don't pollute the global
namespace" (or scope) for lots of information. If you just want to get it done and you're not very confident of your JavaScript skills, you could just prefix your
function and variable names with your company name or other string that is unlikely to be used in other code. Purists will hate that advice but your secret is safe with me.
Form name
In the page source you may see some IDs containing "win0". That is the name of the form. However, if the user opens a new window then it won't be "win0". The name
of the form is returned by %Formname. Use that in your code and it will be replaced by the correct name at runtime.
Your scripts can communicate with the server (i.e., your PeopleCode) through input fields and buttons. Sometimes you may want to pass information back and forth but keep it
hidden from the user. Next time we'll wrap up with a discussion of that. With that piece of the puzzle, if you are adventurous, you can greatly expand the capabilities
of your pages.
|
