Object path expressions provide a simple way to navigate through persistent objects and relations between them, and to resolve the values of their fields for a given root
object and a path.
The Object Path Expression Language is a simple language that was initially designed to access persistent objects from within ISML templates without having to write Java code. The concept was later extended to make object path expressions available to other domains as well, such as pipelines, pipelets, and queries.
An object path consists of elements separated by colons:
This:is:an:object:path
The elements of the object path can be simple identifiers, consisting of alphanumeric characters, or they can be special expressions like parameter elements, null values or literals.
Object path expressions can contain elements with parameters. Such subexpressions are used like arguments for Java method calls. Parameter values are resolved as object path expressions as well.
Parameters directly follow their parent element (which represents a "method call") and are marked by round brackets. Multiple parameters can be separated by a comma.
This:is:an:object:path(This:is:an:argument:path) This:is:an:object:path("This is a constant") This:is:an:object:path(This:is:an:object:path("This is a constant")) A:B(C:D(E)):F(G, H:I(J))
An object path consists of at least one element, and can be of arbitrary length.
Note
Literals can only occur as parameters in object paths, such as in Product:Price("EUR")
. They cannot serve as root expressions, such as This is a constant
.
See section Object Paths in ISML for details.
Literals are marked by double-quotes at the beginning and the end of the expression.
"This is a constant string value."
A literal can also be passed as a parameter:
This:is:an:object:path("This is a constant parameter")
If the literal represents a value other than a string, it may contain a class cast which is enclosed by round brackets within the quoted expression.
"(Integer)123" "(BigDecimal)123.45" "(java.text.DecimalFormat)#,###"
The type for the cast must be a Java class that can take a string as an argument in its constructor. If the type is not located in one of the default packages java.lang
, java.math
, java.text
or com.intershop.beehive.foundation.quantity
, the full class name (including package) must be specified.
If the cast type constructor takes more than one string argument, multiple arguments can be separated using square brackets. Each argument can be a literal type itself.
"(Money)[USD][(BigDecimal)123.45]"
Note
Java primitives such as (int)123
are not supported. The cast type must be an object type.
The object path expression language supports literals for Java classes using the syntax (Class)<any Java class name>
. For example, the following expressions are allowed:
OrderBO:Extension ("(Class)com.intershop.sellside.appbase.b2c.capi.order. OrderBOPaymentExtension") ServiceConfigurationRepository:Services ("(Class)com.intershop.component.orderimpex.capi.export.order. OrderExportService")
The expression null
or NULL
(case-insensitive) is a reserved word representing a null value.
The individual elements of object paths are mapped to invocations on Java objects or to lookups from the pipeline or session dictionaries. Which mappings are actually available depends on the position of the object path element inside the object path (see Lookup Strategies).
When resolving an object path, the root object is determined first, and then each subsequent element of the object path is used to navigate from the current object to the next object, starting from the initial root object. The object resolved last is then the final result.
The following types of lookup operations for a single object path element are available:
<ISLOOP>
construct.get
method that takes a string (or an object) as argument.get
Methods get
+ element name. If the object path element has parameters, the parameter values are resolved and passed as arguments to the underlying get
method.is
Methods is
+ element name. Such methods typically return a boolean value, e.g., isValid()
. If the object path element has parameters, the parameter values are resolved is
method.has
Methods has
method, e.g., the full method name is has
+ element name. If the object path element has parameters, the parameter values are resolved and passed as arguments to the has
method.createIterator
Methods createIterator
method, e.g., the full method name is create
+ element name
+ Iterator
. If the object path element has parameters, the parameter values are resolved createIterator
method.Collection Lookup
Java-collection classes like java.util.Map
and java.util.Collection
do not follow the JavaBean standard. Therefore, their properties are not accessible using ObjectPath. For this, an extra lookup method has been implemented
that supports some special mappings for Maps, Collections and Arrays. The following path names can be resolved and are mapped to their underlying Java implementation method:
Map | Collection | Array |
---|---|---|
Values | Iterator | Size |
EntrySet | Size |
|
KeySet |
|
|
Size |
|
|
The available mappings of individual object path elements are combined to form so-called lookup strategies. A lookup strategy resolves a particular object path element or a complete object path by selecting and applying well-defined
lookup methods. Lookup strategies distinguish two different dimensions:
The object path framework is based on so-called fallbacks. In order to resolve an object path element, mappings are tried in the order determined by the fallback priority until a mapping was found that produced a valid result for the current path element.
This fallback mechanism is implemented by a fallback lookup strategy. The fallback strategy defines the applicable lookup methods and the order in which they must be tried.
When resolving the values for elements of an object path, the position of the element within the path is important, because it has an impact on the lookup methods that are applicable for resolving the element.
The position lookup strategy distinguishes three positions in a path. For each area, a fallback strategy (consisting of multiple lookup methods) is configured.
For example, in the expression
This:is:an:object:path
This
is the head, is:an:object
is the body, and path
is the tail.
The head position is particularly important to resolve the initial root object from where the rest of the path can be resolved. Therefore, the pipeline dictionary lookup and the session dictionary lookup methods are typical fallbacks for the head position.
In a loop context (e.g., ISML loops), the tail position is of special interest, as it must return a value that can be looped over (e.g. iterated). Therefore, it contains the createIterator
lookup method as a possible fallback. Such a lookup method does not make sense in the body part of a path, which is why it is missing there.
Note
Literals can only occur as parameters in object paths, such as in Product:Price("EUR")
. They cannot serve as root expressions, such as This is a constant
.
Note
The reflection lookup for an ISML object path does not support null
values for method arguments.
The reflection lookup has to recognize the type of the argument. When using null
values the lookup cannot distinguish between methods with the same name and number of arguments but different argument types.
This lookup configuration applies to all simple ISML expressions (except <ISLOOP>
), such as <ISPRINT>
, <ISSET>
, etc.
Fallback Priority | Head Position | Body Position | Tail Position |
---|---|---|---|
1 | Literal Value (full path) | Reflection | Reflection |
2 | Template Loop Stack | Extensible Object single attribute | Extensible Object single attribute |
3 | Pipeline Dictionary Lookup | Reflection | Reflection |
4 | Session Dictionary Lookup (with prefix | Map lookup | Map lookup |
5 |
| Collection lookup | Collection lookup |
Note
Content assist in Intershop Studio provides convenient access to object path expressions in templates.
This lookup configuration applies to ISML <ISLOOP>
expressions only.
Note
The loop node requires a result object that is iterable, such as a collection, an array or an iterator.
Therefore somewhat different fallbacks apply.
Fallback Priority | Head Position | Body Position | Tail Position |
---|---|---|---|
1 | Literal Value (full path) | Reflection | Reflection |
2 | Template Loop Stack | Map lookup | Extensible Object multiple attributes |
3 | Pipeline Dictionary Lookup | Collection Lookup | Reflection |
4 | Session Dictionary Lookup (with prefix |
| Map lookup |
5 |
|
| Collection Lookup |
Object paths can be used to define aliases for input parameters of pipelets. Pipelets generally support three kinds of fallback for the whole object path:
Parameter values are resolved recursively, again starting with fallback priority 1.
Fallback Priority | Head Position | Body Position | Tail Position |
---|---|---|---|
1 | Pipeline Dictionary Lookup | Reflection | Reflection |
2 |
| Extensible Object single attribute | Extensible Object single attribute |
3 |
| Reflection | Reflection |
4 |
| Map Lookup | Reflection |
5 |
|
| Map Lookup |
6 |
|
| Extensible Object multiple attributes |
Note
Content assist in Intershop Studio provides convenient access to object path expressions in pipelines.
For pipeline decision nodes, the values to be compared can be obtained using object path expressions. Generally, the same fallbacks as for pipelet aliasesapply, except that literalsand nullcannot be used directly as decision value.
Pipeline loop nodes support three general fallbacks for the whole object path:
Note
The loop node requires a result object that is iterable, such as a collection, an array or an iterator.
Therefore somewhat different fallbacks apply.
Fallback Priority | Head Position | Body Position | Tail Position |
---|---|---|---|
1 | Pipeline Dictionary Lookup | Reflection | Reflection |
2 |
| Map Lookup | Extensible Object multiple attributes |
3 |
|
| Reflection |
4 |
|
| Map Lookup |
The return value of a web service can have an alias that works similar to a pipelet alias. Therefore, the same fallback strategies apply here. See Pipelet Input Aliasesfor details.
Object path expressions can be used in the Intershop Studio pipeline debugger to inspect the values of objects that are currently stored in the pipeline dictionary. For this, open the Watch view and enter an object path. The same syntax and capabilities applicable to pipelet aliasescan be used here.