A topic that periodically resurfaces surrounding XPage development is the notion of creating "classes" in JavaScript. There are several schools of thought - not just in our own community, but across the entire web development spectrum - regarding how best to handle inheritance in JavaScript, because the language itself is not classical... it is prototypal.

 

In nearly every other language, we define a class and then create objects that are instances of that class. With JavaScript, however, there is no need to define two separate structures: we can just define an object that has the behavior we need and use it. If we need something that extends that object's behavior, we can create a new object, link its prototype to the existing object, then add the new behavior. Trying to squeeze the language into our own narrow comfort zone robs the language of its flexibility and power, and ourselves and our users of the kind of functionality we could be creating for them.

 

More to the point for XPages, perhaps, is that if we're planning on creating deep classical hierarchies at runtime, it's likely that we've identified a need to do so either because the functionality we plan to implement will be complex, we want our code to be reusable, or both. While JavaScript is perfectly capable of doing complex things, when we're doing complex things in SSJS, we're interacting with Java API's, whether that be the core Domino API or other third party libraries; we're using Java classes, even if we aren't creating any of our own. To put it another way, SSJS is just an entry point to Java, so we can either hang out in that foyer all night... or venture inside and join the rest of the party.

 

That said, I understand that many XPage developers are nervous about taking that leap; I understand: I've been there myself. In the meantime, I'd like to offer some code that may help to soften the landing: a single-function library that allows you to easily structure your JavaScript code into reusable, extensible, class-like objects.

 

 Before we actually dig into that function, let's take a look at a very basic example of a class you might create:

 

To "instantiate" this class, we simply call the Person function, and pass it a config object that bundles all of our constructor arguments into one:

---

---

This constructor defines two variables: the employee object that we will actually return, and employmentStatus, which at first glance looks like a throwaway variable because the constructor function finishes before we get a chance to do anything to it. But because we returned something from the function, as long as the object we returned is alive, any other variables that were defined within the same function as that object still exist... but only that object can get to them.

 

If you've ever heard the term "closure" in connection to JavaScript, this behavior is what that term refers to: employee and employmentStatus are defined inside the same function, and we return employee from that function, so as long as something, somewhere in our code still has a valid handle on the employee object, employee's methods can access - and change - the value of employmentStatus, but nothing else can. Ergo, employmentStatus is a private property of our Employee class.

 

Why does all this matter? If the only thing that the fire() and rehire() methods do is change the value of employmentStatus, why not just make that property public? Because, unlike this example code, in a real application, firing an employee is a complicated affair. There are systems that the employee needs to be locked out of, payroll needs to be notified to stop sending a paycheck, and so forth. You can't just set an employee's status to "Terminated" and leave it at that. Keeping this field private ensures that, if a call to getStatus() used to return "Active" and now it returns "Terminated", at some point in between a method was called that had an opportunity to do other things before it changed that value.

 

Now let's extend Employee by creating another descendant class: 

As before with the Employee class, we only need to add what's different at this layer. Developer will automatically support getStatus(), because a Developer is an Employee; we don't need to specify that again here. Similarly, Developer will support getFirstName(), because a Developer is an Employee, and an Employee is a Person. We are, however, choosing to override toString(). This is fully optional, but it often makes sense to include a way to retrieve a full text-based description of the object's state in a single method, and in both the Java and JavaScript world, the convention is to call that method toString().

 

In particular, check out line 11 of the above example class. Often when overriding a method in a parent class, the parent's definition of that method is already doing most of the work that we need done, but not all (otherwise we wouldn't be overriding it to being with, we'd just inherit it). In Java, any method of a child class (e.g. Developer) can refer to "super" to get a handle on the current object as an instance of its parent class (e.g. Employee). This isn't actually another object, it's just a temporary reclassification (in Java terminology, "cast") of the object we're already in. So we can call super.toString(), and it will execute the toString() method as it's defined in the parent class, but run it against the current object. Implementation of that pattern gets a bit messy in JavaScript, so this library takes a slightly different approach.

 

In JavaScript, functions are objects. So, just like a function can be a method of a larger object, functions themselves can have methods (and properties). This library takes advantage of that by giving each overridden method a method of its own; because "super" is a reserved word in JavaScript (although the language doesn't actually use it), the method is called "ancestor" instead. So in the above example, the Developer implementation of toString() includes a reference to developer.toString.ancestor(). Because this is a strange pattern, let's do a split on the period and analyze this expression in three parts:

1. developer - refers to the object that will be returned. We could just use "this" instead, but "this" is surprisingly volatile in JavaScript; by naming the object we'll return ("var developer = Employee(config)..."), we can refer to it by its name inside the object itself, which ensures that we're always referring to that object, even if something bizarre happens that causes the scope of "this" to change at runtime.
2. toString - gives us a handle on the toString method of the developer object. Because we're not appending parentheses to this handle, it does not run the method, just provides a handle to the actual function object (as opposed to the result of its execution). This is crucial, because we're obtaining this handle inside the method that this handle points to, which is already weird enough, but calling the method inside the method would cause recursion. Recursion is a powerful thing when done right, but that's not what we want here. We simply want the method we're already in to be able to get a handle on itself - not to run it again, but to retrieve one of its own members.
   
3. ancestor() - gives us a handle on the method we're already in, but as it's defined in the parent class, and then executes it against the current object instance.

In short, this one line of code is yet another example of letting the parent class do the work for us, where appropriate. We let the ancestor method glean most of the information that's being requested, then tack on the one extra bit that it doesn't have access to.

 

Before we wrap this up, let's change our example object to be an instance of the Developer class: 

So we've only added a couple properties to the config object we're passing to the constructor, but the resulting object is capable of much more specialized behavior than it was when it was just an instance of Person. And yet, to customize what this object can do, we need only modify the class where the change is appropriate, and that change will filter down to all instances of any class that inherits from the class that we changed. That is ultimately what makes object-oriented programming so powerful.

 

One last thing: every object created using this pattern supports two additional methods: getClassName() and instanceOf(). In our final example, the former will return "Person.Employee.Developer" if the code is running client-side in Firefox; function.name is not part of the official JavaScript spec, so in SSJS and most browsers, getClassName() will return "..". I know, not terribly useful. The instanceOf() method is another example where the behavior differs: in Firefox, you can pass it either a handle on the constructor function or its name (e.g. me.instanceOf("Person") === me.instanceOf(Person)); it returns true if the object was created using either the specified constructor or any of its ancestors. In SSJS and most browsers, however, the argument must be a real handle on the constructor... passing it the name doesn't work - again, because in those contexts functions don't have a .name property. And yes, for the JavaScript ninjas among you, I already tried using arguments.callee.caller; that's not standard either.

 

Finally, here is the library that makes this pattern of code reuse possible. And, to give credit where credit is due, the code of this library was inspired by techniques used by Douglas Crockford, Dean Edwards, and John Resig. Hopefully all of you already know who they are and consume any content that they produce. If not, now would be an excellent time to start.