This two-part article is about how I learned P4JsApi and some of its surrounding technologies. My hope is that it’ll help you get up to speed more quickly. So…
Part One: Getting Up To Speed
A New Process Monitor
So I set about making it, and I’m here to tell you what I learned in the process. Here’s a screenshot of what I ended up with (you can’t see from the picture, but the bars are animated, just like the future!):
Looks pretty good to me. About those colors: When a process has been running for period of time determined by the user, its bar turns from blue to orange. When the user clicks on one of the process bars, a little translucent box glides in to view, just like on the Enterprise's computer:
Then there’s a preferences dialog that lets the user change some options…
Based on these screenshots, I think I’ve met my initial goals: fancy drawing (well, a little fancy), talking to the Perforce server, gathering input from the user, and yes, it almost looks like it could be on the Enterprise. The rest of this article details how I got there…
- The Mozilla Canvas Tutorial at https://developer.mozilla.org/en/Canvas_tutorial. Canvas is an HTML element that lets you draw your own custom stuff. After I realized that the free Google charts weren’t going to be flexible enough to do what I wanted (more on this later too), I decided to do custom drawing for the bar chart in my app using a Canvas element.
Getting Set Up In A P4 Client
You should be able to get started by going through the first few sections, specifically Enabling Applets, The Permissions Table Entry, The Central Settings File, and Programming Applets. You might as well read the whole thing though; you’ll probably need it all at some point.
Oh, and make sure you’re running a Perforce client from release 10.1 or later; P4JsApi wasn’t in prior releases.
A Word On Security
With freedom comes responsibility, yes? So I got to use all this cool P4JsApi stuff, but given that one uses it to access the company’s crown jewels (via the Perforce server), I also needed to watch for obvious security holes. It turns out that the main issues to look for have to do with gathering and disseminating data: anything you collect from the server, and anything you collect from the user, needs to be scrutinized and groomed before creating and modifying HTML with it.
document.getElementById("statusLabel").innerHTML = P4JsApi.encodeForHTML(process.status);
In this case I have an object I’ve created, called process, which contains a string in its status field that comes directly from the server. Wrapping process.status in the encodeForHTML method ensures that there is nothing in the status field that is going to execute when it gets written out to HTML.
Likewise, if you know that your output is going to be an integer, you can use the parseInt method for even better security, like so:
document.getElementById("idLabel").innerHTML = parseInt(process.id);
So, what are the chances that there is an executable script in a process’s status or id field? Admittedly slim. But a motivated and malevolent user can find ways to insert executable script into your data; using these methods is your first line of defense to prevent that from happening.
Next up in Part Two of this article: Nuts and Bolts, or how to actually use P4JsApi…