Community
Participate
Working Groups
Currently, when you define a node, you can give it a fixed string static label or a dynamic label that is tied to a value of a property. This works ok in most situations, but more flexibility is sometimes necessary. One thought is to allow embedding of scriptlets to specify how the label is to be computed. The challenge with scriplets is handling label update properly. Which properties do we need to listen for? This can be solved by having the script work through a property manager that tracks property access and sets up listeners on accessed properties.
Expanding this scope of this enhancement to track creating a generic expression language to be used throughout model annotations and sdef UI files. I am currently investigating an approach based largely on JSP EL.
Progress so far can be seen in org.eclipse.sapphire.modeling.el package. The key class is Function, which can be implemented directly to provider custom functions in various contents. The EL package also has a variety of standard functions as specified by JSP EL language. The standard functions haven't been tested yet. The eventual goal is to have these be instantiated by the EL parser.
The EL architecture is shaping up nicely. I have all operators from JSP EL spec implemented, along with type conversion rules. I have even converted the code that handles the dynamic-label feature for master details content outline node to use (manually-constructed) EL expression. In particular... <dynamic-label> <property>Name</property> <null-value-text>[contact]</null-value-text> </dynamic-lavel> ... is represented in code like so... ${ empty Name ? "[contact]" : Name } The next step is to implement the parser so that expressions like the above one can be directly written in sdef files and models. In terms of architecture, functions have a reference to FunctionContext, which supports retrieving properties and listening on their changes. Now that's a general concept of properties, not the specific concept of Sapphire model properties. FunctionContext is the base class. ModelElementFunctionContext is a subclass that wraps around an IModelElement and exposes that element's properties to functions. The function contexts can be extended arbitrarily by expression hosts. Everything in the expression tree is a Function, including the key terminals Literal and PropertyReference. Functions are evaluated via push rather than pull model. That is, a function listens on its operands, when operands change the function is re-evaluated. If re-evaluation caused a value change, then the function notifies its listeners, etc. An expression host would listen on the expression to know when expression value has changed and trigger appropriate actions.
Implemented expression language parser along with about 150 unit tests. Removed ILabelDef type added previously. The expression language is now integrated into the following contexts: * master details content outline node label * section label * section description
Note that a plain string parses as a literal expression. This makes it possible to integrate EL into any context that previously accepted only static strings without breaking existing usage. Here are some example expressions from the contacts sample: Contacts ${ Name == null ? "<contact>" : Name }
Added EL support to property enablement. All previous enablement usecases are now expressed via uniform @Enablement( expr = "..." } syntax.
> Added EL support to property enablement. All previous enablement usecases > are now expressed via uniform @Enablement( expr = "..." } syntax. Actually, @Enablement( service = SomeClass.class ) syntax is still supported. The new EL syntax replaces all other usecases.
Added a section showing EL-based enablement functionality to the gallery sample.
Added ability to register EL functions via Sapphire extension system.
I have finished EL documentation (available under Sapphire Developer Guide). Calling this completed.
Verified in sample and documentation.
