WCTL gotchas

Webcrossing Template Language is the first scripting language to be built into the Webcrossing Core. At the time it was a huge innovation in server configurability, as it allowed for dynamic page customization without having to recompile the server binary.

Life and the internet moved on, of course, and now that kind of scriptability is utterly routine, and in Webcrossing itself WCTL has been superceded by the more widely-known and flexible Javascript syntax. But even though WCTL is formally deprecated there are circumstances where it's the better tool, so it behooves the Webcrossing developer to know some of the ins and outs of this quirky layout-oriented language.

One such quirk is the interplay between the %% user %% and %% author %% pseudo-objects.

user (I'll dispense with the %% delimiters for the rest of this post) always resolves to the user currently viewing the page delivered by the server. It can be the hex id of a registered user, the hex id of a named guest user, or 0 for an anonymous guest user. You can read any property from the user, whether built-in or custom. Thus, user.userName resolves to the user's name, user.user2ndLine to the user's tagline (that appears underneath the name in posting bylines), and so on. If you have previously defined a custom property, say, .phoneNumber, then user.phoneNumber will deliver the value of that property.

Writing user properties in WCTL requires the use of special pseudo-methods. Thus, you cannot say

set user.userName "Fred Jones"

("set" is the WCTL assignment keyword), but rather 

user.setUserName("Fred Jones")

That works for all the built-in user properties. But what about custom properties?

set user.phoneNumber "555-1212"

works, BUT it only works as long as you are working with the user pseudo-object. What if you want to work with a different user than the current one?

You can store an arbitrary user's id in a local variable with

set someUser userLookup("joe user")

Then you can read or write any of the built-in properties:

someUser.userName

someUser.setUser2ndLine("What a cool tagline!")

However, you cannot access any custom properties this way.

someUser.phoneNumber

will throw an error, and there is no setter pseudo-method for custom properties.

Here is where the author directive comes in. During normal processing, author resolves to the creator of the current location. But you can use the setAuthor directive to force author to another value, and then custom properties are writeable! So in order to set the .phoneNumber property programmatically in WCTL, the following is required:

%% set saveLocation location // changing author clears the current location, so you must preserve it %%

%% set theUser userLookup("joeUser") // another quirk: setAuthor(userLookup()) throws an error, so you must use an intermediate variable %%

%% setAuthor(theUser) %%

%% set author.phoneNumber "555-1212" // writes the custom property %%

%% setPath(saveLocation) // restores location and author to their original values %%

Obviously, that's a lot more work then the WCJS equivalent

User.lookup("joe user").phoneNumber = "555-1212";

but believe or not, there are plenty of times when it will be the quicker alternative!