Why Webcrossing Server-side JavaScript (SSJS) is the scripting language you should choose

Server-side JavaScript (SSJS) vs Web Crossing Template Language (WCTL)

Webcrossing's Server-side JavaScript (SSJS) is based on standard JavaScript, so anybody with any scripting experience at all can get started very quickly. Beginners also will find SSJS easy-going because there are so many JavaScript tutorials and references available. (*1), (*2)

As w3schools, the go-to-place for web standards and scripting help states, "JavaScript is THE scripting language of the Web. JavaScript is used in billions of Web pages to add functionality, validate forms, communicate with the server, and much more. JavaScript is easy to learn. You will enjoy it." (*2)

Webcrossing also has an older scripting language called Web Crossing Template Language (WCTL). WCTL is completely unique to the Webcrossing platform, and rather awkward to use. In this post I'll give a few examples of why SSJS is preferable to WCTL for new development, and why it is also generally easier to use, read and learn.

While this is true, many of the out-of-the-box scripts (or "templates" as they are sometimes called in Webcrossing lingo) go way back, before SSJS was created, and are still written in WCTL. Until WCTL-based scripts are completely replaced, developers often encounter WCTL sections of existing code, so they should have some familiarity with the WCTL syntax. Hopefully WCTL will disappear over time and Webcrossing developers will be able to avoid two learning curves.

However, if you are creating a completely new Web 2.0 application from scratch, you can blessedly ignore WCTL altogether and just concentrate on object-oriented server-side scripting using SSJS.

SSJS has all the control structures WCTL lacks

There are many things which are quite awkward to accomplish in WCTL, because of the lack of standard control structures. Those same tasks are quite easy in SSJS.

For example, let's say you simply want to output the numbers from 1 through 10 and their squares.

Here's how you would do it in WCTL:

%% set n 1 %%
%% while n <= 10 %%
%% n %%,%% n*n %%<br>
%% set n n + 1 %%
%% endwhile %%

(And you'd better hope you are not continuing to use the "n" variable in your chain of execution because it's impossible to create a local variable in WCTL.)

In SSJS you could write this more simply as:

for (var n=1; n<=10; n++) response.append (n + ',' + n*n + '<br>');

Or if you want to use the SSJS "+" shortcut for response.append you could write it this way:

for (var n=1; n<=10; n++) {
+ n + ',' + n*n + '<br>';
}

SSJS uses response.append() to build the "response buffer" (the page being dynamically created to serve to client browsers) instead of client-side document.write(). Otherwise, this example looks like ordinary JavaScript.

While WCTL only has while loops, SSJS has all the control structures of standard JavaScript, including while loops, for loops (both incremented and for/in loops for associative arrays) and do/while loops.

SSJS also has switch statements, which are not available in WCTL.

Other basics missing from WCTL, all present in SSJS, include:

• local variables,
• functions with parameters,
• labels,
• arrays,
• objects and
• numbers.

(In WCTL you can perform limited integer arithmetic using strings as numbers, but the number 1 is equal to the string "1" because strings are WCTL's only data type).

Setting/accessing stored node and user properties

Because of the way Webcrossing interacts with its native object-oriented database, there are no separate SQL databases to set up, and no tables or database schemas to design.

One of the great joys of Webcrossing's object-oriented database is that you can directly attach properties to any node - folders, files, messages, discussions, etc., and also to users. Webcrossing lets you just add properties and use them whenever and wherever you like.

Given this inherent simplicity, you want to be able to set and access these properties easily in your scripts. This process is conceptually much easier in SSJS than it is in WCTL.

Let's compare the two.

Suppose you have a root level folder /someFolder. To that folder, you want to attach a property called "color" and set its value to "blue." Remember, we don't need to first create a field in a record in a table anywhere, as would be required with an SQL-based system. We can just "do it."

In WCTL, however, this is awkward compared to "just doing it" in SSJS. In WCTL you have to perform a strange programming maneuver where you first save your current location, then go to the location in question, set the value, and finally return to your current location, like this:

%% set currentLocation location %%
%% setPath("/someFolder") %%
%% set path.color "blue" %%
%% setPath(currentLocation) %%

This does get old rather quickly.

In SSJS this could be written as simply as:

Node.lookup("/someFolder").color = "blue";

I think this is clearly conceptually easier for beginners than the WCTL version, is definitely easier in daily scripting practice, and is also much easier to read.

For setting user properties, it is similarly awkward in WCTL and direct in SSJS. The SSJS version is as simple as:

User.lookup("doug").color = "blue";

Conclusion

I think it's obvious that SSJS is the preferred way to get started for (1) standards compliance, (2) clarity, (3) ease-of-use, (4) available structures, (5) available data types, (6) easiest access to nodes and users in the database and (7) easiest for beginners to learn, with vast learning resources available.

doug

(*1) I learned JavaScript originally through what is still my favorite reference: "JavaScript, The Definitive Guide" by David Flanagan. This is part of the well-regarded O'Reilly series. The book gets revised regularly to keep things up-to-date. If you are completely new to JavaScript, even reading just the first four chapters will open up a world of knowledge to you. And all the core JavaScript objects and their methods (strings, dates, etc.) are in their own easy-to-find sections.

(*2) Online, w3schools has a great JavaScript tutorial at http://www.w3schools.com/js/default.asp.

Steve Jobs, 1955-2011

As remembered on Apple's home page,

 ...and by boingboing.net

You may leave other found tributes or your own in the comments. Farewell, Steve.

Funday Monday - Who was the Wild Child?

Who was Peter the Wild Boy?

From feral child to "human pet" at court in Georgian England, Peter the Wild Boy caused a sensation. And new analysis of his portraits may have solved the mystery of his unusual characteristics.

New analysis of this portrait suggests Peter had a rare genetic condition known as Pitt-Hopkins Syndrome, indicated by:

1. His short stature
2. Lustrous mop of thick curly hair
3. Hooded eyelids
4. Cupid's bow mouth, with a pronounced curve to the upper lip
5. He disliked clothes, but was wrestled daily into a green suit
6. Pictured holding acorns and oak leaves - symbolic of living wild in the woods - and some fingers on his left hand (not seen) were fused

Building a Conversation with 500 Students

This article appeared as a Syllabus "Case Study", July 2001, page 10. Even after all these years, I find that it still holds up. It was exciting to create a multi-directional Socratic dialogue with a class of 500 students - using Webcrossing software for the dialogue backbone freed me to focus on the students.

FACE-TO-FACE WITH VIRTUAL COMMUNITIES
Building a Conversation with 500 Students
Syllabus "Case Study", July 2001, page 10

Americ Azevedo has 500 students in his Introduction to Computers course at the University of California, Berkeley. Despite that, his teaching philosophy embodies the principles of the Socratic method. What makes this apparent contradiction possible is discussion software, a technology that enables him to “teach” and interact with his students outside of class in a flexible, dynamic way. Discussion software connects him, his students, and the TAs for the course, and allows them to communicate much more directly and frequently than they otherwise could.

Azevedo, who has taught courses in computers and human/computer interaction at several institutions, has always believed that the Socratic method is right approach to teaching. In courses with smaller enrollments, he has usually relied upon open-ended questions and in-class discussion while simultaneously tinkering with online discussion formats to supplement the ongoing Socratic dialogue. However, faced with the prospect of teaching hundreds of students in a large lecture hall three days a week for 50 minutes, Azevedo knew that in-class discussion would be nearly impossible and that he’d have to rely on online discussions to achieve his goals.

The immediate benefit of using discussion software has been an increase in participation by his students and a chance for him to get to know some of them quite well. “I can call up a list of all of their contributions to the course and see what they’re like quite easily.” Says Azevedo. “Through the use of the software I get a chance to hear the ideas and concerns of a large number of students. It also allows the shy students to participate as actively as the more outgoing ones.”

Flexibility was one of his primary concerns. “Most of the software that exists for course management is content-centered,” notes Azevedo. “It locks you into specific topics and doesn’t allow discussions to grow naturally.” Because it had many of the features he was looking for, Azevedo decided to try Webcrossing in the course. “What like about Webcrossing is that it’s discussion-centered and allows students to generate new topics, or threads, if they want to. It is really an experiment in developing a pattern language, a new way of submitting thoughts.”

Azevedo’s class site had topics that he’s generated, where he can post course information, posit questions, and link to other useful sites. It also includes many student-generated threads. In addition, the course is supported by the full array of UC Berkeley’s technology tools. For instance, through the Berkeley Internet Broadcasting Network, Azevedo has captured streaming video of all of his lectures. Students can link to these from the class site. Coupled with dynamic lecture notes, PowerPoint slides, and online assignments, the site is a rich resource for both discussion and study. “With these resources in place,” he notes, “we could expand the enrollment of the course to a distance learning situation with twice or four times as many students.”

E-mail is a part of Azevedo’s package as well. He is experimenting with the use of e-mail to communicate with his students, posting information about upcoming lectures to a listserv. Based on student responses, he can tailor the lecture to address the material they need specific help with, and skip what they’ve already absorbed. This has led to some interesting student-contributed material. “I asked them to define some terms that are used in the computer industry,” he says. “The students generated some very interesting metaphors that I used in lecture.”

Azevedo’s Introduction to Computers also has a lab requirement. “With 18 sections of labs 4 hours a week, we’re using all the available lab space,” he says. In the future, he hopes to use discussion software to enhance the laboratory experience, allowing the students in each lab section to communicate with each other and with the TA on projects. He’s also planning to experiment with a CyberLab that would replace some of the lab sections.

According to Azevedo, discussion software can enhance not only large lecture courses, but smaller enrollment courses as well. “When I used it with small classes, it generated a lot of excitement,” he notes. “There was more personal engagement than you get with a large course. My students generated hundreds of pages of text, and the themes just grew and expanded organically.”

In his large course, Azevedo has found that students don’t necessarily participate as much, but he has been surprised by the level of response at times. “I started a debate about participation credits: should students get credit for participating in these large lecture courses? This produced a raging debate on Webcrossing. It was a level of expression that you would normally never get in a large class. Students contributed ideas about how the course should be graded, some of which I incorporated into the course.”

He adds, “My co-teachers, Nicholas Cravotta, quickly adopted the new environment. For instance, he was able to give quick public feedback to a discussion topic led by student-generated questions. Normally, students would never get this kind of feedback in a large class.”

Early Funday Morning Lolcat

see more Lolcats and funny pictures, and check out our Socially Awkward Penguin lolz!

Debugging with log files

The easiest way to debug with Webcrossing is to just print values to the screen:

myvar: %% myvar %%<br>

or

+ 'myvar: ' + myvar + '<br>';

But sometimes - especially inside filters - it isn't possible (well, not practical) to do this.  Or maybe you are trying to catch an elusive bug on a production server and printing to the screen is not an option.  In that case, you need to write a log file with the values in it which you can examine after processing.

Let's use a debug file called, well, "debugFile".

In WCTL, the syntax is like this:

%% "debugFile".fileWrite( "myMacro ran" & crlf ) %%

or

%% "debugFile".fileWrite( "myVar:" & myVar & crlf ) %%

In SSJS, it looks like this:

"debugFile".fileAppend( "myMacro ran" + '\r\n' );

or

"debugFile".fileAppend( "myVar:" + myVar + '\r\n' );

You can add timestamps too if you intend to leave the debug code in for a while.

When you're ready to look at it, the debugFile file is in the /system directory on your server (if viewing from FTP) or the /webx directory (if viewing from the server's operating system itself).

Debugging SSJS - What the heck am I looking at?

If you have an error in a WCTL script file, the error and its location will be written into the webx.log file, a warning message will appear on the cache reset screen, and as Sue has pointed out the existence of the error - if not its provenance - is often made obvious when your site appearance goes pear-shaped. Errors in SSJS syntax can be a little more difficult to track down, if for no other reason than JS is more frequently used for backend-type functions where nothing gets written to the screen directly. If you have an error in a filter, for example, the only sign of it may be that the filter doesn't give the expected results.

One way to deal with this is to put all the significant pieces of your code inside a try/catch structure and write an exception handler. That's certainly best-practice for production code, but during development the Webcrossing server will provide you with a wealth of information, really an embarrassment of riches, for any uncaught exception in your JS code.

All you have to do is look in your /system folder for files named in the format of logJsErrorN.html (where N is an integer). One gets written whenever an exception is thrown. It's an HTML file, it can run to be upwards of 3000 lines, and there will rarely be a time when anything past the first couple of dozen lines will be of use to you. Here's an example:

The heading gives you a timestamp for the exception, tells you the name of the routine that failed, and the type of exception it threw. Then the next section gives the values of the routine's arguments and any local variables when the exception occurred. In the next section is listed the exact line of the function where the exception occurred - so it's worthwhile to keep your code clean and well-blocked. The last likely-to-be-useful line is the stack trace, showing you exactly how you got to where the exception was thrown.

Now, the next 2000-odd lines are an enumeration of every single object in the execution context at the moment of the exception: every global, every function, every built-in method and property. I'm sure there are circumstances where this information can be useful, but I've never run into one!