Contributing EL Variables |
org.eclipse.jst.jsf.context.symbol.source.AbstractContextSymbolFactory
.
Once you create your implementation, you can declare it to the
framework using the
org.eclipse.jst.jsf.common.contextSymbolFactory extension
point. In the extension, you need to provide a unique
factoryId. This factoryId is used to identify your factory and
can then be used in your symbol factory meta-data section. See also the Design Time Application Manager for information.protected abstract ISymbol internalCreate(String symbolName, int scope, IAdaptable context, List problems, final IAdditionalContextSymbolInfo additionalInfo);
Starting in WTP 3.0, several default symbol factories have been added for common tasks.
These new factories can be used by specifying their factory ids (see JSP model processor). The following are the new ids with an explanation of their function:
Id | Additional meta-data | Explanation |
---|---|---|
org.eclipse.jst.jsf.core.staticJavaTypeSymbol | optional-value-binding-static-type | Creates a statically-typed Java symbol based on the type signature passed using optional-value-binding-static-type meta-data value. |
org.eclipse.jst.jsf.core.valueExpressionSymbolFactory | optional-value-binding-valueexpr-attr | Creates a new symbol, using the attribute on the current tag specified by optional-value-binding-valueexpr-attr to extract type information from an EL expression. |
org.eclipse.jst.jsf.common.unknownTypeSymbolFactory | Creates a new symbol with an unknown type that effectively allows all properties as valid. |
Deprecation note: Prior to WTP release 3.0 (Ganymede train), the method:
protected abstract ISymbol internalCreate(String symbolName, int scope, IAdaptable context, List problems);
was used for this API. This method is now deprecated in favor of the new method that takes the IAdditionalContextSymbolInfo object. Existing code is still backward compatible and is the equivalent of calling the new method with null for the additionalInfo argument. You can migrate to the new method by simply implementing it instead and ignoring the additionalInfo argument which is always optional.
JSF has many ways to contribute variables. If the framework has
overlooked any or if you have added new ways yourself without affecting
the way other variables, such as managed beans, are declared, then you
can do so through the
org.eclipse.jst.jsf.common.symbolSourceProvider
extension. Your symbol provider will implement the
org.eclipse.jst.jsf.context.symbol.source.ISymbolSourceProviderFactory
interface. Every time the framework requests a list of variables
through the default VariableResolver and ExternalContext, your provider
will be queried for all its symbols at one or more scopes.
Note that your symbol provider may not called if:
The variable provider extension allows you to register your own design
time resolver. You declare your resolver using the
org.eclipse.jst.jsf.core.variableresolver extension point.
Your extension will declare a unique id and a class. The class
must extend
org.eclipse.jst.jsf.designtime.el.AbstractDTVariableResolver
.
To register your resolver as the active one for a project (note: JSF
1.1 only supports a single variable resolver at a given time.
Future versions supporting JSF 1.2 will have a more robust scheme
matching what is defined in the newer specification), you use
DesignTimeApplicationManager.setVariableResolverProvider specifying the
id defined in your extension as the argument.
Once your variable resolver is registered and active for a project, all variable resolution requests to the framework will call your implementation. This gives you complete control over how all EL variable symbols are discovered and instantiated by the design time framework.
Starting in WTP 3.0, Variable and Property Resolvers support a decorative mechanism for adding variables and properties. By setting the forRuntimeClass on the extension for these resolvers you can cause the resolver to only be consulted if the runtime class specified is found in the application configuration. This allows the design time to behave similar to the runtime which allows decorative chaining of variable and property resolvers. See the org.eclipse.jst.jsf.core.variableresolver extension point. for more information.
Starting in WTP 3.0, Variable and Property Resolvers can be declared as being constructed on per-project basis instead of the (default) per-workspace convention. See the entension point docs on instancePerProject value for more information.