Document Properties
KbidH24830
Last Modified04-Feb-2020
Added to KB01-Jul-2013
Public AccessEveryone
StatusOnline
Doc TypeReferences
Product
  • ICM 7.6
  • ICM 7.7
  • ICM 7.8
  • ICM 7.9
  • ICM 7.10

Reference - Object Path Expressions

1 Introduction

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.

2 Object Path Syntax

2.1 Object Path Elements

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.

2.2 Parameters

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.

2.3 Literals

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")

2.4 Null Values

The expression null or NULL(case-insensitive) is a reserved word representing a null value.

3 Mapping of Object Paths to Java Objects

3.1 Lookup Methods

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:

  • Pipeline Dictionary Lookup
    The object path element is used as key for the pipeline dictionary. This lookup is normally used to determine the root object.
  • Session Dictionary Lookup
    The object path element is used as key for the session dictionary. This lookup is normally used to determine the root object.
  • Template Loop Stack Lookup
    The object path element is used as key for the current iterator in the template loop stack. This lookup is only used within an ISML <ISLOOP> construct.
  • Extensible Object Lookup
    The object path element is used as name for an extensible object attribute. The attribute is looked up for the current locale for the current user. Alternatively, multiple attributes can be looked up from the extensible object (e.g., in a loop context).
  • Map Lookup
    The object path element is used as key for a hashmap-structure. The object to which the lookup method is applied must have a get method that takes a string (or an object) as argument.
  • Java Reflection Lookup for get Methods
    The object path element is used as suffix for a get-method, e.g., the full method name is get+ element name. If the object path element has parameters, the parameter values are resolved and passed as arguments to the underlying get method.
  • Java Reflection Lookup for is Methods
    The object path element is used as suffix for an is-method, e.g., the full method name is 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
    and passed as arguments to the is method.
  • Java Reflection Lookup for has Methods
    The object path element is used as suffix for a 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.
  • Java Reflection Lookup for createIterator Methods
    The object path element is used as part of the name of a 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
    and passed as arguments to the 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

     

     

3.2 Lookup Strategies

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:

  • a fallback lookup strategy and
  • a lookup strategy depending on the position of an object path element inside the object path.

3.2.1 Fallback Lookup Strategy

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.

3.2.2 Position Lookup Strategy

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.

  • the head: this is the first element of an object path
  • the body: this is the middle part (consisting of 0..n elements)
  • the tail: this is the last element of the object path

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.

4 Object Paths in ISML

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.

4.1 ISML Expressions

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 get

Reflection get

2

Template Loop Stack

Extensible Object single attribute

Extensible Object single attribute

3

Pipeline Dictionary Lookup

Reflection is

Reflection is

4

Session Dictionary Lookup (with prefix T_)

Map lookup

Map lookup

5

 

Collection lookup

Collection lookup

Note

Content assist in Intershop Studio provides convenient access to object path expressions in templates.

4.2 ISML Loops

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 get

Reflection createIterator

2

Template Loop Stack

Map lookup

Extensible Object multiple attributes

3

Pipeline Dictionary Lookup

Collection Lookup

Reflection get

4

Session Dictionary Lookup (with prefix T_)

 

Map lookup

5

 

 

Collection Lookup

5 Object Paths in Pipelines

5.1 Pipelet Input Aliases

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:

  1. Check for the null value.
  2. Resolve a literal value (if the expression is enclosed by double-quotes).
  3. Resolve the object path element by element using the position-dependent fallbacks listed in the following table.

Parameter values are resolved recursively, again starting with fallback priority 1.

Fallback Priority

Head Position

Body Position

Tail Position

1

Pipeline Dictionary Lookup

Reflection get

Reflection get

2

 

Extensible Object single attribute

Extensible Object single attribute

3

 

Reflection is

Reflection is

4

 

Map Lookup

Reflection createIterator

5

 

 

Map Lookup

6

 

 

Extensible Object multiple attributes

Note

Content assist in Intershop Studio provides convenient access to object path expressions in pipelines.

5.2 Pipeline Decision Nodes

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.

5.3 Pipeline Loop Nodes

Pipeline loop nodes support three general fallbacks for the whole object path:

  1. Check for the null value.
  2. Resolve literal value (if the expression starts and ends with doublequotes).
  3. Resolve the object path element by element using the position-dependent fallbacks listed in the next table.
    Parameter values are resolved recursively, again starting with fallback priority 1.

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 get

Reflection createIterator

2

 

Map Lookup

Extensible Object multiple attributes

3

 

 

Reflection get

4

 

 

Map Lookup

6 Web Services

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.

7 Object Paths in Intershop Studio

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.

Disclaimer

The information provided in the Knowledge Base may not be applicable to all systems and situations. Intershop Communications will not be liable to any party for any direct or indirect damages resulting from the use of the Customer Support section of the Intershop Corporate Web site, including, without limitation, any lost profits, business interruption, loss of programs or other data on your information handling system.

Customer Support
Knowledge Base
Product Resources
Support Tickets