Webcrossing's original scripting language is a proprietary, built-in language called WebCrossing Template Language, or WCTL. Some years later, the Mozilla Spidermonkey JavaScript engine was grafted onto Webcrossing to act as a second server-side scripting language. We'll cover that in more detail in Part 2 of this series.
But first, WCTL. WCTL is currently officially "deprecated," so as not to scare off new developers, but it is still supported, and it has a number of useful qualities. In other words, you don't have to learn vast amounts of WCTL if you don't want to, but if you happen to pick it up, it can be quite handy.
WCTL is a tag-based language, and everything not inside WCTL tags is HTML output to the page. Server-side JavaScript (SSJS) is, of course, just the opposite. WCTL tags are delimited by %%'s, for example:
Hello, %% userName %%, welcome back!
Because it's not necessary to quote everything sent to the page, WCTL is much faster for front-end developers writing user interface. Besides just being faster to develop, WCTL runs a trifle faster than SSJS. WCTL can be used directly in Control Panel HTML textareas (SSJS can't). WCTL at its simplest is quite accessible for the amateur site owner who wants to add just a bit of dynamic content here and there, like the simple example above. But WCTL can be quite powerful, as demonstrated by the fact that most of the out-of-the-box scripts are written in WCTL. And it's CaSe INsensitive and is very forgiving of errors, unlike SSJS, which tends to barf all over the page if you aren't careful.
But WCTL is limited in some ways, and is admittedly a bit quirky. It is not really object-oriented, has only one data type (strings, although integer math can be done), has no arrays, and you can't use parameters with functions ("macros") you create yourself (although variable scope is very broad, so in reality that's more a nuisance than a real problem).
Webcrossing has the concept of "location" (in the forum hierarchy), which refers initially to the location at which a script is being executed. In WCTL, a sort of pseudo object-oriented dot notation - %% path.someproperty %% - makes it possible to reference stored properties of the current location. To reference the values at some location other than the initial one, you can %% setPath( uniqueID ) %% to the unique ID hex number of the forum object you want to reference so that %% location %% then refers to the new location, and then %% path.someproperty %% will refer to the new location's property.
You can do the same thing with users. %% user %% refers to the currently-viewing-user, and %% author %% can refer to either the actual content author of the current location, or some arbitrary other user whose properties you are interested in. For example, %% user.userEmail %%. Or %% author.userEmail %%. To examine that arbitrary user (author) you do: %% setAuthor( userId ) %%. From there, use %% author.someproperty %%. But, if you do that - Danger, Will Robinson! - you lose access to properties of the current location and will have to %% setPath() %% to regain access. (Remember, I did say it was a little quirky.)
You can mix and match SSJS and WCTL, although there is a small performance hit for doing so. So you could write your user interface in WCTL for speed, error-forgiveness, and to save time; and call SSJS functions to provide the complicated programming that is more convoluted to do in WCTL. In fact, that's exactly what some of us do.
We'll cover the Webcrossing implementation of SSJS in Part 2, and then Part 3 will summarize what the two languages are each best and worst at.
No comments:
Post a Comment