Rule sets

UpCommands
Sitemap
 

A rule set is simply a tcl script containing rule processing commands.

To define and work with them we have the following commands:

Ruleset commands
Subcmd Description
::fmail::def
name rulescript

This command associates a <rulescript> with a <name> for later usage by ::fmail::process

Return value is the entered <name>.

Example

::fmail::def spamblock {
    on {![input hasHeader to]} do junkit
    on {
	[input unwantedSender] ||
	!([input localSender] ||
	  [input localTarget])
    } do junkit
}
	    
::fmail::process
object via rules

This command executes a named set of <rules> for an <object>.

The argument <via> is actually without any meaning. Its only purpose is to allow syntactic sugar while using the command. Its contents are ignored.

The <object> is specified through the name of its object command. See input below too.

The rule script is executed in a separate interpreter and has no direct access to the outside world except through the language elements defined below and the methods of the <object>.

Example

::fmail::process mail via spamblock
	    

Inside of a rule script the following command for building rules are available:

Rule commands
Subcmd Description
input
...

This command is an alias of the <object> given as argument to ::fmail::process.

This command additionally provides all defined Predicates as methods of the object. Predicates take precedence over normal methods, i.e. a predicate with the same name as a real method of the object shadows that method.

Example

input getHeader from
input hasHeader to
	    
action
name arguments body

This commands allows the definition of Actions from the inside of a rule script.

See ::fmail::action for a full explanation of the syntax.

process
ruleset args

This command allows the execution of a named <ruleset> from within another rule script.

See ::fmail::process too.

<args> must be either empty or contain two arguments. The first of these is a dummy serving as syntactic sugar, the second is the command of the object to use while executing the other rule script.

In case of an empty <args> the called rule script will use the object of the calling rulescript.

Example

process rules
process rules for anotherObject
	    
on
condition action args

The first command for building rules.

Evaluates the <condition> as an expression, then executes the named <action> if the result was 'true'. The additional <args> are given to the <action> as its first arguments.

The <condition> usually contains calls to the Predicates defined for the input object.

Example

on {[input hasHeader to]} ...
	    
never
action args

Equivalent to 'on 0'. Never executes its action.

Example

never vacation
	    
always
action args

Equivalent to 'on 1'. Always executes its action. The additional <args> are given to the <action> as its first arguments.

Example

always process spamblock
	    
default
action args

Equivalent to always, but implictly executes stop after the action.

Because of this it should be the last rule in a script, as no other rule will be executed after it.

In case of nested rule scripts its usage should be restricted to the toplevel ruleset too.

Example

default store2mh-folder inbox
	    
log
text

Adds the <text> to the log maintained by the rule engine.

Useful for debugging complex rule sets.


© Andreas Kupries
Last update at Thu Nov 11 21:48:40 MET 1999