Filters, part 3: When is a filter not a filter?

The original reason filters were given that name is that they filter the response to an HTTP request. Later as other protocols were built in to the Webcrossing server - email, NNTP, etc., filters were added to provide equivalent or appropriate functionality for them. Thus we have incoming and outgoing email filters, NNTP authentication filters, and so on.

But there is one class of filter that is arguably misnamed, because they run in the background. They are triggered by certain actions and so they give you hooks into various convenient parts of the event loop, but they cannot affect the output from the action. These filters are

• postCreate
• postRename
• postEdit
• preDestroy
• postUpload

The first four are triggered by (as the name suggests) the creation, renaming, editing, or deleting of any database node, no matter what type it is (folder, discussion, web file, or a custom Stored object) and no matter how the action is triggered (via the web interface, or an email or nntp request, or programmatically via a WCTL or SSJS script). So this gives you enormous flexibility in tying customized actions to database changes. It also means, of course, that you have to carefully define in your code which types of nodes you want to be affected and (if you're coding in SSJS) be careful to only use methods or properties available to that type of node. If you make a mistake in that respect, the code will bomb at that point and since it's running in the background the only sign of it will be a logJSError stack trace file.

postUpload unlike the others pertains to only one type of node, files. It fires whenever a new file is uploaded via the web interface, FTP, or WebDAV. It does NOT run when a file is created programmatically.

On entry, the current location is that of the triggering node. (That's why preDestroy, unlike the others, runs just before the action rather than just after it, so that the about-to-be-deleted location is still available.)

Final caveat: because all of these run in the background, there may be a slight delay between the triggering event and the execution of your code. In human turns it's generally imperceptible but you can't rely on the order of events.