Function expressions

Function expressions define instantiations of Java classes, which conforms to our component model. The WebComp architecture currently expects a particular type of objects which can serve HTTP requests. In scripts, functions are defined by:

• URLs for static or dynamic web-objects. URLs are written without any quotes. An URL expression implicitly denotes a web-function (a handler) which is able to present the resource named by that URL.
• Static text in double quotes. This implicitly denotes a web-function which wraps static text.
• References to Java classes (Function components) which conforms to our component model, prefixed with '@'.
• Functions applied to some argument, using the '|' operator. A function can be partially evaluated, i.e. it still takes more arguments before an object could be instantiated.

Web-functions can be also composed by using the '+' operator which means that requests are served by executing each component in sequence. For instance the expression

MY-ATTRIBUTE = "<h1>This is a heading</h1>" + body.html + $FOOTING; 

defines MY-ATTRIBUTE to be a concatenation of the heading and the content of body.html and the value returned from the attribute FOOTING defined elsewhere in the script. Expressions formed by the '+' operator actually uses a simple function that takes two other functions as arguments.

Java component functions

Java classes implementing functions can easily be plugged into a running WebComp system. For instance, accessing static resources can be explicitly done as follows:

RESOURCE = @wcomp.htmlparser.HtmlParserFunc | 'my-resource.html';

The implementation class of the function is prefixed with '@' and the operator '|' means that the function at the left side is applied to the expression at the right side. It is up to the component programmer to define how many arguments to take. An expression which apply all needed arguments evaluates to an instance of the component. We say that the component is activated.

Partly evaluated functions

An expression which apply some arguments but not all evaluates to a new function which takes the remaining arguments. Such partly evaluated functions may be assigned to attributes which can later be referenced to evaluate the function further. For instance:

ifOldBrowser  = @wcomp.func.HeaderMatch 
           | 'user-agent'
           | 'Mozilla[1234].*';

page1 = $ifOldBrowser | "You use an old browser" | "You use a new browser";
page2 = $ifOldBrowser | $alternative1 | $alternative2;

HeaderMatch takes 5 arguments: the name of a HTTP request header, a regular expression, a function to call if the value of the given header matches the regular expression and a function to call if not. We can define a new function (ifOldBrowser) which takes two arguments. One function to call if the client browser is old and another to call if not. This is a partially evaluated function. It is fully evaluated when giving the remaining arguments. We can do this many times.

Partially evaluated functions can also be used as arguments, which adds expected arguments to the resulting function. And one can use parantheses in expressions. For instance if foobar takes one string argument:

template = $ifOldBrowser | ($foobar | 'SORRY, BAD BROWSER!') | $foobar;
page1 = $template | 'GOOD BROWSER';

Argument placeholder

Arguments to functions must be given in the order they are specified in the corresponding constructor method. It is however possible to alter the order by using a questionmark as a placeholder for an argument. If for instance a function $datasource takes three argument, URL, username and password the following would define $mysource to be a function taking only the URL as an argument (the username and password are given).

mysource = $datasource | ? | 'my-usename' | 'my-password'; 

Lazy evaluation

Note that evaluation of functions is lazy in the sense that activation of a component normally does not happen before the first time it is used (typically when a client do a HTTP request which use the function). This means that before this happens, definitions of arguments may be changed (typically by redefining attributes). Note that as soon as activation has happened, a redefinition of an argument would not have any effect. Note however, that by default, activations are not shared between different scripts.