New SmartFrog features

I have now added to the Sourceforge CVS a range of new capabilities that
I promised a while back when I released LAZY functions. In essence, all
assertions and schemas can now be checked during resolution or after
deployment. These changes are largely backward compatible - to the
extent that our regression tests all passed without modification to
other than the error-message checking parts. Minor changes such as the
error messages generated or, in a few cases the class of exception, were
necessary. One non-backward compatible change is to the interface to
user-defined SmartFrog-language functions. This
"org.smartfrog.sfcore.reference.Function" interface has had to change,
but this is rarely used directly by users.

Note that as usual - documentation lags features...

New features:

1) Optional links. 

Links may now be tagged as optional and a default value given. This is
true for both eager and lazy links. An example is

sfConfig extends {
   //y 10;
   z OPTIONAL (5) y;
}

As it stands, calling sfResolve("z") will return the value 5. If the
definition of y is uncommented then calling sfResolve("z") will return
10. If the default value is not provided, the value NULL is returned (an
instance of the class SFNULL). This means that we can test to see if a
reference is defined (or set to NULL - another way to indicate
optionality) and provide values accordingly. For example

   x (IF (OPTIONAL y != NULL) THEN somethingForDefined ELSE
somthingForUndefined FI)

This is provided in response to a request from CERN. I might yet provide
a prefix operator "defined" that is equivalent to the test for NULL.

2) Assertions

Assertions may still be given as before:

sfConfig extends Compound {
    x 10;
    y 20;
    ok extends Assertions {
       xSmall (x < 20);
       yBig (y > 10);
       xLTy (x < y);
    }
    ... Etc ...
}

But now the values on which the assertions depend may be LAZY. Indeed,
even though the assertion may be fully resolvablable, the assertion is
left for checking after deployment as well as during language
resolution. To provide some control over when the assertions are
checked, an additional attribute "sfAssertionPhase" is provided:

sfConfig extends Compound {
    x 10;
    y 20;
    ok extends Assertions {
       sfAssertionPhase "static";  // or "staticLazy" or "dynamic" - the
default is dynamic if not provided 
       xSmall (x < 20);
       yBig (y > 10);
       xLTy (x < y);
    }
    ... Etc ...
}

The sematics of the attribute is:
   1) static - the assertions must evaluate to true at resolution time,
no lazy values allowed. The assertion is not carried over to deployment
   2) staticLazy - the assertions, if resolvable, must be true. However
Lazy values are allowed and are then unchecked. The assertion is not
carried over to deployment 
   3) dynamic - the assertions, if resolvable, must be true. However
Lazy values are allowed and are then unchecked. The assertion is carried
over to deployment 

A new method is added to Prim, sfValid(), wich returns a boolean and
this is effectively the conjunction (and) of all the assertions. Indeed,
resolving any attribute that is an assertion will return either true (if
satisfied) or a resolution exception if it fails. sfValid() could be
called in sfPing(), for example, or in sfReplaceAttribute to check that
every attribute was set to a valid value and resetting it to its
previous value if not. (Ideally, this could be checked without actually
altering the attribute - but this will require more work.)

3) Schemas

These are now a special case of assertion and are represented as before.
The attribute sfAssertionPhase is used as with assertions to decide if
they are to be kept on for deployment time. sfValid also checks the
scemas on components. 

sfConfig extends Compound {
    x 10;
    y "hello";
    okSchema extends Schema {
       x extends Integer;
       y extends String;
    }
    ... Etc ...
}

The built-in Prim and Compound schemas are defined as static only
checking and so are not kept to deployment. 

With both assertions and schemas, if they are kept to deployment time,
they appear in the ComponentDescriptions that result from the parsing
process. These can be very long ideed and can seriously hinder viewing
the structure of exceptions and the resultant overall description. As a
consequence, in some error messages, the printouts of the assertions and
schemas are truncated. So far, nothing has been done to improve the
printout of the whole ComponentDescription with assertions. The same is
also true of "lazy" functions.

Note that as well as the above way of describing the assertions and
schemas, there is an internal representation similar to the APPLY syntax
for functions. This is, for assertions 

    ok ASSERT { sfFunctionClass "org.smartfrog...CheckAssertions"; xBig
... }

And for schemas

    okS ASSERT { sfFunctionClass "org.smartfrog...CheckSchemaElement"; x
... }

This form doesn't need to be used and is created automatically from the
"normal" syntax by the "function" phase when processing a description,
but it will be seen in the printout of a processed ComponentDescription.
It is also legal syntax if desired.

So for those of you who like to live dangerously and checkout and run
from the tree... please play and feed back any problems. This will
appear in the next release which will probably be when the documentation
catches up!

Patrick

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642