4. Expression Language (EL)

An important concept to understand is there are two types of expressions in Web Flow: standard expressions and template expressions.

<evaluate expression="searchCriteria.nextPage()" />
				

Template expressions

The second type of expression is a template expression. A template expression allows mixing of literal text with one or more standard expressions. Each standard expression block is explicitly surrounded with the #{} delimiters. For example:

<view-state id="error" view="error-#{externalContext.locale}.xhtml" />
				

The expression above is a template expression. The result of evaluation will be a string that concatenates literal text such as error- and .xhtml with the result of evaluating externalContext.locale. As you can see, explicit delimiters are necessary here to demarcate standard expression blocks within the template.

	Note
	See the Web Flow XML schema for a complete listing of those XML attributes that accept standard expressions and those that accept template expressions. You can also use F2 in Eclipse (or equivalent shortcut in other IDEs) to access available documentation when typing out specific flow definition attributes.

Starting with version 2.1 Web Flow uses the Spring Expression Language (Spring EL). Spring EL was created to provide a single, well-supported expression language for use across all the products in the Spring portfolio. It is distributed as a separate jar org.springframework.expression in the Spring Framework. Existing applications will need to remove dependencies on org.jboss.el or org.ognl and use org.springframework.expression instead. See the section below on EL Portability for other notes on upgrading.

In Web Flow 2.0 Unified EL was the default expression language with jboss-el as the implementation. Use of Unified EL also implies a dependency on el-api although that is typically provided by your web container. Tomcat 6 includes it, for example. Spring EL is the default and recommended expression language to use. However it is possible to replace it with Unified EL if you wish to do so. You need the following Spring configuration to plug in the WebFlowELExpressionParser to the flow-builder-services:

<webflow:flow-builder-services expression-parser="expressionParser"/>

<bean id="expressionParser" class="org.springframework.webflow.expression.el.WebFlowELExpressionParser">
    <constructor-arg>
        <bean class="org.jboss.el.ExpressionFactoryImpl" />
    </constructor-arg>
</bean>
                

Note that if your application is registering custom converters it's important to ensure the WebFlowELExpressionParser is configured with the conversion service that has those custom converters.

<webflow:flow-builder-services expression-parser="expressionParser" conversion-service="conversionService"/>

<bean id="expressionParser" class="org.springframework.webflow.expression.el.WebFlowELExpressionParser">
    <constructor-arg>
        <bean class="org.jboss.el.ExpressionFactoryImpl" />
    </constructor-arg>
    <property name="conversionService" ref="conversionService"/>
</bean>

<bean id="conversionService" class="somepackage.ApplicationConversionService"/>
                

	Note
	OGNL support is deprecated as of Web Flow version 2.4.

OGNL is the third supported expression language. OGNL is the EL most familiar to Web Flow version 1.0 users. Please refer to the OGNL language guide for specifics on its EL syntax. If you wish to use OGNL this is the Spring configuration necessary to plug it in:

<webflow:flow-builder-services expression-parser="expressionParser"/>

<bean id="expressionParser" class="org.springframework.webflow.expression.WebFlowOgnlExpressionParser"/>
                

Note that if your application is registering custom converters it's important to ensure the WebFlowOgnlExpressionParser is configured with the conversion service that has those custom converters.

<webflow:flow-builder-services expression-parser="expressionParser" conversion-service="conversionService"/>

<bean id="expressionParser" class="org.springframework.webflow.expression.WebFlowOgnlExpressionParser">
    <property name="conversionService" ref="conversionService"/>
</bean>

<bean id="conversionService" class="somepackage.ApplicationConversionService"/>
                

Use flowScope to assign a flow variable. Flow scope gets allocated when a flow starts and destroyed when the flow ends. With the default implementation, any objects stored in flow scope need to be Serializable.

<evaluate expression="searchService.findHotel(hotelId)" result="flowScope.hotel" />
			

Use viewScope to assign a view variable. View scope gets allocated when a view-state enters and destroyed when the state exits. View scope is only referenceable from within a view-state. With the default implementation, any objects stored in view scope need to be Serializable.

<on-render>
    <evaluate expression="searchService.findHotels(searchCriteria)" result="viewScope.hotels"
              result-type="dataModel" />
</on-render>
			

Use requestScope to assign a request variable. Request scope gets allocated when a flow is called and destroyed when the flow returns.

<set name="requestScope.hotelId" value="requestParameters.id" type="long" />
			

Use flashScope to assign a flash variable. Flash scope gets allocated when a flow starts, cleared after every view render, and destroyed when the flow ends. With the default implementation, any objects stored in flash scope need to be Serializable.

<set name="flashScope.statusMessage" value="'Booking confirmed'" />
			

Use conversationScope to assign a conversation variable. Conversation scope gets allocated when a top-level flow starts and destroyed when the top-level flow ends. Conversation scope is shared by a top-level flow and all of its subflows. With the default implementation, conversation scoped objects are stored in the HTTP session and should generally be Serializable to account for typical session replication.

<evaluate expression="searchService.findHotel(hotelId)" result="conversationScope.hotel" />
			

Use requestParameters to access a client request parameter:

<set name="requestScope.hotelId" value="requestParameters.id" type="long" />
			

Use currentEvent to access attributes of the current Event:

<evaluate expression="booking.guests.add(currentEvent.attributes.guest)" />
			

Use currentUser to access the authenticated Principal:

<evaluate expression="bookingService.createBooking(hotelId, currentUser.name)"
          result="flowScope.booking" />
			

Use messageContext to access a context for retrieving and creating flow execution messages, including error and success messages. See the MessageContext Javadocs for more information.

<evaluate expression="bookingValidator.validate(booking, messageContext)" />
			

Use resourceBundle to access a message resource.

<set name="flashScope.successMessage" value="resourceBundle.successMessage" />
			

Use flowRequestContext to access the RequestContext API, which is a representation of the current flow request. See the API Javadocs for more information.

Use flowExecutionContext to access the FlowExecutionContext API, which is a representation of the current flow state. See the API Javadocs for more information.

Use flowExecutionUrl to access the context-relative URI for the current flow execution view-state.

Use externalContext to access the client environment, including user session attributes. See the ExternalContext API JavaDocs for more information.

<evaluate expression="searchService.suggestHotels(externalContext.sessionMap.userProfile)"
          result="viewScope.hotels" />