Web Flow uses EL to access its data model and to invoke actions. This chapter will familiarize you with EL syntax, configuration, and special EL variables you can reference from your flow definition.
EL is used for many things within a flow including:
Access client data such as declaring flow inputs or referencing request parameters.
Access data in Web Flow's
RequestContextsuch asflowScopeorcurrentEvent.Invoke methods on Spring-managed objects through actions.
Resolve expressions such as state transition criteria, subflow ids, and view names.
EL is also used to bind form parameters to model objects and reversely to render formatted form fields from the properties of a model object. That however does not apply when using Web Flow with JSF in which case the standard JSF component lifecyle applies.
An important concept to understand is there are two types of expressions in Web Flow: standard expressions and template expressions.
The first and most common type of expression is the standard expression.
Such expressions are evaluated directly by the EL and need not be enclosed in delimiters like #{}.
For example:
<evaluate expression="searchCriteria.nextPage()" />
The expression above is a standard expression that invokes the nextPage method on the searchCriteria variable when evaluated.
If you attempt to enclose this expression in a special delimiter like #{} you will get an IllegalArgumentException.
In this context the delimiter is seen as redundant.
The only acceptable value for the expression attribute is an single expression string.
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]](images/note.png) | 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 is 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"/>
In general, you will find Spring EL, Unified EL and OGNL to have a very similar syntax.
Note however there are some advantages to Spring EL. For example Spring EL is closely integrated with the type conversion of Spring 3 and that allows you to take full advantage of its features. Specifically the automatic detection of generic types as well as the use of formatting annotations is currently supported with Spring EL only.
There are some minor changes to keep in mind when upgrading to Spring EL from Unified EL or OGNL as follows:
Expressions deliniated with
${}in flow definitions must be changed to#{}.Expressions testing the current event
#{currentEvent == 'submit'}must be changed to#{currentEvent.id == 'submit'}.-
Resolving properties such as
#{currentUser.name}may cause NullPointerException without any checks such as#{currentUser != null ? currentUser.name : null}. A much better alternative though is the safe navigation operator#{currentUser?.name}.
For more information on Spring EL syntax please refer to the Language Reference section in the Spring Documentation.
There are several implicit variables you may reference from within a flow. These variables are discussed in this section.
Keep in mind this general rule. Variables referring to data scopes (flowScope, viewScope, requestScope, etc.) should only be used when assigning a new variable to one of the scopes.
For example when assigning the result of the call to bookingService.findHotels(searchCriteria) to a new variable called "hotels" you must prefix it with a scope variable in order to let Web Flow know where you want it stored:
<?xml version="1.0" encoding="UTF-8"?> <flow xmlns="http://www.springframework.org/schema/webflow" ... > <var name="searchCriteria" class="org.springframework.webflow.samples.booking.SearchCriteria" /> <view-state id="reviewHotels"> <on-render> <evaluate expression="bookingService.findHotels(searchCriteria)" result="viewScope.hotels" /> </on-render> </view-state> </flow>
However when setting an existing variable such as "searchCriteria" in the example below, you reference the variable directly without prefixing it with any scope variables:
<?xml version="1.0" encoding="UTF-8"?> <flow xmlns="http://www.springframework.org/schema/webflow" ... > <var name="searchCriteria" class="org.springframework.webflow.samples.booking.SearchCriteria" /> <view-state id="reviewHotels"> <transition on="sort"> <set name="searchCriteria.sortBy" value="requestParameters.sortBy" /> </transition> </view-state> </flow>
The following is the list of implicit variables you can reference within a flow definition:
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.
As mentioned earlier in this section when assigning a variable in one of the flow scopes, referencing that scope is required. For example:
<set name="requestScope.hotelId" value="requestParameters.id" type="long" />
When simply accessing a variable in one of the scopes, referencing the scope is optional. For example:
<evaluate expression="entityManager.persist(booking)" />
When no scope is specified, like in the use of booking above, a scope searching algorithm is used.
The algorithm will look in request, flash, view, flow, and conversation scope for the variable.
If no such variable is found, an EvaluationException will be thrown.