You know how a dynamic web page works, of course. The browser sends a request containing a URL and maybe some other data, the server builds a response based on the data it gets, and sends it back. And somewhere in there the server might also change the contents of the database backend. When you want to do something a bit outside the normal process, getting the server to do exactly what you want it to can sometimes be a challenge.
With Webcrossing you have powerful tools that allow you to take over processing at multiple points during the life cycle of the request. This power comes from a set of special script routines called "filters". Dave's already written about the authentication filter, but that's only the tip of the iceberg.
Probably the most-commonly used of the filters are the add- and edit-, -pre and -post filters. Each of the principal built-in node types has them. So, for example, for discussions there are
discussionAddFilterPre
discussionAddFilterPost
discussionEditFilterPre
discussionEditFilterPost
Let's focus on the add filters for right now.
Most filters can be written in either WCTL or SSJS. Basically, if a filter routine exists in your script codebase, it gets called at a specific point in a specific operation; on entry it has access to certain relevant data which it can read and/or alter. You can even abort normal processing and return your own response page.
Here's a simple example:
%% macro discussionAddFilterPre %%
<html><head></head><body>%% formGetNameValues %%</body></html>
%% endmacro %%
This routine, written in WCTL, will execute after the "Add Discussion" form is submitted but before the discussion is created. Because it starts with <html> it will abort normal processing and return its contents directly to the requestor. In the case, the directive %% formGetNameValues %% is just a list of all name/value pairs from the submitted form.
But you need not abort processing. You could look at various form values and take an action based on that. For example,
%% macro discussionAddFilterPre %%
%% if getValue("title") == "Puppies" %%
%% setPath ("/Kittens") %%
%% endif %%
%% endmacro %%
This filter examines the value of the discussion form's title input field. If the title is "Puppies", the current location is changed from wherever it is to the folder named "Kittens". The discussion will be created, but in a different place than perhaps where the user intended.
The -post filters work similarly, but they execute after the item is created, not before. Here's a quick example, written this time in SSJS.
%% command discussionAddFilterPost() {
if (location.nodeAuthor.userName == "Joe Obnoxious") {
email("<sysop@somewhere.com">, "Oh no, it's that obnoxious guy again, posting at " + location.nodeUrl);
}
} %%
This filter looks at the name of the author of the just-created discussion Node (referenced by the location object) and in the case of a particular user, sends the sysop an email which contains a link to the new discussion (location.nodeUrl).
This brief article only scratches the surface of the customization potential and processing power of filters. I will write more about them in future posts.
No comments:
Post a Comment