| WCTL Webcrossing Template Language | SSJS Server-side JavaScript | |
|---|---|---|
| tight integration with OODB | yes | yes |
| easy for beginners | yes | no |
| good for experienced programmers | if you can get used to its limitations | definitely |
| tag-based | yes | no, every string going to the response buffer must be quoted (with one exception I will write about later in a full post) |
| use with client-side JS | easy-peasy | can be a bit of a hair-puller |
| case sensitivity | no | yes |
| number crunching ability | limited, integers only | full suite of JavaScript Math methods |
| execution speed | very fast | fast |
| use directly in Control Panel HTML textareas | yes | no |
| error handling | graceful, but little information | not always graceful, but great stack traces |
| out-of-box scripts | most are WCTL | a few are SSJS |
| object-oriented | pseudo, not really | yes |
| has arrays | no | yes, plus StoredArray() objects stored in DB |
| function parameters | no | yes |
| variable scope | very broad, across entire execution request | normal JavaScript variable scope |
| have multiple database location objects open at once | no, just current location | yes |
| have multiple user objects open at once | just user and author | yes |
| create new object types | sort of | yes |
| bottom line | blazingly fast, good for beginners, a little quirky | powerful, not so forgiving, just a trifle slower than WCTL |
WCTL and SSJS duke it out [Part 3]
OK, here's where it gets fun. Part 1 was about WCTL (Webcrossing Template Language) and Part 2 was about Webcrossing's newer, more powerful scripting language, SSJS (server-side JavaScript). Now they'll both put on their boxing gloves and show us their stuff.
Subscribe to:
Post Comments (Atom)
A couple of comments about "tag-based" and "use with client-side JS". It's not really correct to say every string going into the response buffer must be quoted. And it doesn't have to be a hair-puller to use with client-side JS. WCJS is a lot easier than that.
ReplyDeleteFor example, the following is taken FROM INSIDE A WCJS FUNCTION - as is.
// a client-side script to track input characters in the message box
%%
<script language="javascript" type="text/javascript">
function limitText(limitField, limitCount, limitNum) {
if (limitField.value.length > limitNum) {
limitField.value = limitField.value.substring(0, limitNum);
} else {
limitCount.value = limitNum - limitField.value.length;
}
}
</script>
%%
That goes right into the response buffer AND is a client side JavaScript function to boot. It's used to dynamically count input into a user field.
doug
Thanks, Doug, for reminding me of that. I've added a note above that there is an exception to the general rule.
ReplyDeleteThere are a couple of "gotchas" with that technique, and I think it warrants an entire post of it's own!
This comment has been removed by the author.
ReplyDeleteSince we're "duking it out" here :) I think I might take issue with your "easy for beginners" assessment.
ReplyDeleteWebcrossing's SSJS (which I love!) is, after all, based on standard JavaScript, so anybody with any scripting experience at all can get started very quickly.
WCTL (which I hate!), on the other hand, is completely unique to the Webcrossing platform.
Because it's so standards compliant, there is an inherently smaller learning curve in getting into SSJS for people who already script in any way at all.
Also, there are a lot of things that are quite awkward to accomplish in WCTL because of the lack of control structures, which are 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 as:
for (var n=1; n<=10; n++) response.append (n + ',' + n*n + '<br>');
Or if you want to use the "+" shortcut for response.append you could write it this way:
for (var n=1; n<=10; n++) {
+ n + ',' + n*n + '<br>';
}
That's basically standard JavaScript.
Which is really easier to write and read for a beginner?
Another thing conceptually easier in SSJS is getting the value of a property set at a node (e.g. "/someFolder").
One of the joys of Webcrossing's object-oriented database is that you can have properties attached to anything - folders, files, messages, discussions, users, etc. So you want to be able to access these properties easily in your scripts.
In WCTL, to (for example) store the value of a property set somewhere in a variable you have to do a strange programming maneuver where you save your current location, go to the location in question, obtain the value, and then return to your current location, like this:
%% set currentLocation location %%
%% setPath("/someFolder") %%
%% set theVar path.someProperty %%
%% setPath(currentLocation %%
In SSJS this could be as simple as:
theVar = Node.lookup("/someFolder").someProperty;
There is no need to "change one's location" to look up properties stored in different locations in SSJS. I think that makes it conceptually easier for beginners.
And don't get me started with obtaining custom user properties in WCTL via the %% author.someProperty %% technique!
Let the duking continue! :)
doug
Doug, you are absolutely correct in your description of setting properties, etc. In fact, I explained that in detail in the two articles leading up to this summary. And I even admitted WCTL is indeed "a bit quirky."
ReplyDeleteBut by "beginner" I meant a rank beginner with absolutely no scripting experience. I stand by my recommendation that WCTL is easier to deal with if you are a rank beginner. :)
I would love to see an article here by you about why you love SSJS so much!