Examples of ELResolver

javax.el.ELResolver
Enables customization of variable, property and method call resolution behavior for EL expression evaluation.
While evaluating an expression, the ELResolver associated with the {@link ELContext} is consulted to do the initial resolution of the first variable of an expression. It is also consulted when a . or [] operator is encountered.
For example, in the EL expression ${employee.lastName}, the ELResolver determines what object employee refers to, and what it means to get the lastName property on that object.

Most methods in this class accept a base and property parameter. In the case of variable resolution (e.g. determining what employee refers to in ${employee.lastName}), the base parameter will be null and the property parameter will always be of type String. In this case, if the property is not a String, the behavior of the ELResolver is undefined.

In the case of property resolution, the base parameter identifies the base object and the property object identifies the property on that base. For example, in the expression ${employee.lastName}, base is the result of the variable resolution for employee and property is the string "lastName". In the expression ${y[x]}, base is the result of the variable resolution for y and property is the result of the variable resolution for x.

In the case of method call resolution, the base parameter indentifies the base object and the method parameter identifies a method on that base. In the case of overloaded methods, the paramTypes parameter can be optionally used to identify a method. The paramsparameter are the parameters for the method call, and can also be used for resolving overloaded methods when the paramTypes parameter is not specified.
Though only a single ELResolver is associated with an ELContext, there are usually multiple resolvers considered for any given variable or property resolution. ELResolvers are combined together using {@link CompositeELResolver}s, to define rich semantics for evaluating an expression.

For the {@link #getValue}, {@link #getType}, {@link #setValue} and{@link #isReadOnly} methods, an ELResolver is notresponsible for resolving all possible (base, property) pairs. In fact, most resolvers will only handle a base of a single type. To indicate that a resolver has successfully resolved a particular (base, property) pair, it must set the propertyResolved property of the ELContext to true. If it could not handle the given pair, it must leave this property alone. The caller must ignore the return value of the method if propertyResolved is false.

The {@link #getFeatureDescriptors} and {@link #getCommonPropertyType}methods are primarily designed for design-time tool support, but must handle invocation at runtime as well. The {@link java.beans.Beans#isDesignTime} method can be used to determine if the resolver is being consulted at design-time or runtime.
@see CompositeELResolver @see ELContext#getELResolver @since JSP 2.1
org.activiti.engine.impl.javax.el.ELResolver
Enables customization of variable and property resolution behavior for EL expression evaluation. While evaluating an expression, the ELResolver associated with the ELContext is consulted to do the initial resolution of the first variable of an expression. It is also consulted when a . or [] operator is encountered, except for the last such operator in a method expression, in which case the resolution rules are hard coded. For example, in the EL expression ${employee.lastName}, the ELResolver determines what object employee refers to, and what it means to get the lastName property on that object. Most methods in this class accept a base and property parameter. In the case of variable resolution (e.g. determining what employee refers to in ${employee.lastName}), the base parameter will be null and the property parameter will always be of type String. In this case, if the property is not a String, the behavior of the ELResolver is undefined. In the case of property resolution, the base parameter identifies the base object and the property object identifies the property on that base. For example, in the expression ${employee.lastName}, base is the result of the variable resolution for employee and property is the string "lastName". In the expression ${y[x]}, base is the result of the variable resolution for y and property is the result of the variable resolution for x. Though only a single ELResolver is associated with an ELContext, there are usually multiple resolvers considered for any given variable or property resolution. ELResolvers are combined together using {@link CompositeELResolver}s, to define rich semantics for evaluating an expression. For the {@link #getValue(ELContext,Object,Object)}, {@link #getType(ELContext,Object,Object)}, {@link #setValue(ELContext,Object,Object,Object)}and {@link #isReadOnly(ELContext,Object,Object)} methods, an ELResolver is not responsible forresolving all possible (base, property) pairs. In fact, most resolvers will only handle a base of a single type. To indicate that a resolver has successfully resolved a particular (base, property) pair, it must set the propertyResolved property of the ELContext to true. If it could not handle the given pair, it must leave this property alone. The caller must ignore the return value of the method if propertyResolved is false. The {@link #getFeatureDescriptors(ELContext,Object)} and{@link #getCommonPropertyType(ELContext,Object)} methods are primarily designed for design-timetool support, but must handle invocation at runtime as well. The java.beans.Beans.isDesignTime() method can be used to determine if the resolver is being consulted at design-time or runtime.
org.camunda.bpm.engine.impl.javax.el.ELResolver
Enables customization of variable and property resolution behavior for EL expression evaluation. While evaluating an expression, the ELResolver associated with the ELContext is consulted to do the initial resolution of the first variable of an expression. It is also consulted when a . or [] operator is encountered, except for the last such operator in a method expression, in which case the resolution rules are hard coded. For example, in the EL expression ${employee.lastName}, the ELResolver determines what object employee refers to, and what it means to get the lastName property on that object. Most methods in this class accept a base and property parameter. In the case of variable resolution (e.g. determining what employee refers to in ${employee.lastName}), the base parameter will be null and the property parameter will always be of type String. In this case, if the property is not a String, the behavior of the ELResolver is undefined. In the case of property resolution, the base parameter identifies the base object and the property object identifies the property on that base. For example, in the expression ${employee.lastName}, base is the result of the variable resolution for employee and property is the string "lastName". In the expression ${y[x]}, base is the result of the variable resolution for y and property is the result of the variable resolution for x. Though only a single ELResolver is associated with an ELContext, there are usually multiple resolvers considered for any given variable or property resolution. ELResolvers are combined together using {@link CompositeELResolver}s, to define rich semantics for evaluating an expression. For the {@link #getValue(ELContext,Object,Object)}, {@link #getType(ELContext,Object,Object)}, {@link #setValue(ELContext,Object,Object,Object)}and {@link #isReadOnly(ELContext,Object,Object)} methods, an ELResolver is not responsible forresolving all possible (base, property) pairs. In fact, most resolvers will only handle a base of a single type. To indicate that a resolver has successfully resolved a particular (base, property) pair, it must set the propertyResolved property of the ELContext to true. If it could not handle the given pair, it must leave this property alone. The caller must ignore the return value of the method if propertyResolved is false. The {@link #getFeatureDescriptors(ELContext,Object)} and{@link #getCommonPropertyType(ELContext,Object)} methods are primarily designed for design-timetool support, but must handle invocation at runtime as well. The java.beans.Beans.isDesignTime() method can be used to determine if the resolver is being consulted at design-time or runtime.

Examples of org.camunda.bpm.engine.impl.javax.el.ELResolver

    }
  }


  public Object invoke(ELContext context, Object base, Object method, Class<?>[] paramTypes, Object[] params) {
    context.setPropertyResolved(false);
    ELResolver delegate = getElResolverDelegate();
    if(delegate == null) {
      return null;
    } else {
      return delegate.invoke(context, base, method, paramTypes, params);
    }
  }

View Full Code Here

Examples of org.camunda.bpm.engine.impl.javax.el.ELResolver


    return elContext;
  }


  protected ProcessEngineElContext createElContext(VariableScope variableScope) {
    ELResolver elResolver = getCachedElResolver();
    ProcessEngineElContext elContext = new ProcessEngineElContext(functionMappers, elResolver);
    elContext.putContext(ExpressionFactory.class, expressionFactory);
    elContext.putContext(VariableScope.class, variableScope);
    return elContext;
  }

View Full Code Here

0 1 2 3 4 5

TOP

All source code are property of their respective owners. Java is a trademark of Sun Microsystems, Inc and owned by ORACLE Inc. Contact coftware#gmail.com.