From e16c6ed21d388cfa161f1ff3c4f08e612c6869e6 Mon Sep 17 00:00:00 2001 From: Keith Donald Date: Fri, 17 Oct 2008 19:35:06 +0000 Subject: [PATCH] polish --- .../src/flow-managed-persistence.xml | 47 ++-------- spring-webflow-reference/src/views.xml | 90 ++++++++++++------- 2 files changed, 63 insertions(+), 74 deletions(-) diff --git a/spring-webflow-reference/src/flow-managed-persistence.xml b/spring-webflow-reference/src/flow-managed-persistence.xml index b650a82c..c6182a2b 100644 --- a/spring-webflow-reference/src/flow-managed-persistence.xml +++ b/spring-webflow-reference/src/flow-managed-persistence.xml @@ -6,23 +6,14 @@ Most applications access data in some way. Many modify data shared by multiple users and therefore require transactional data access properties. - This chapter shows you how to use flows to manage data access in a web application. + They often transform relational data sets into domain objects to support application processing. + Web Flow offers "flow managed persistence" where a flow can create, commit, and close a object persistence context for you. + Web Flow integrates both Hibernate and JPA object persistence technologies. - - - Data access patterns - There are essentially three flow-managed data access patterns: - - - The FlowScoped PersistenceContext - The ConversationScoped PersistenceContext - The ViewState PersistenceContext - - - Apart from these three patterns, there is the pattern of fully encapsulating PersistenceContext management within the service layer of your application. + Apart from flow-managed persistence, there is the pattern of fully encapsulating PersistenceContext management within the service layer of your application. In that case, the web layer does not get involved with persistence, instead it works entirely with detached objects that are passed to and returned by your service layer. - This chapter will focus on the flow-managed persistence patterns, exploring how and when to use them. + This chapter will focus on the flow-managed persistence, exploring how and when to use this feature. @@ -82,32 +73,4 @@ Such data access operations should always execute non transactionally or in read-only transactions to maintain isolation of intermediate edits. - - ConversationScoped PersistenceContext - - This pattern creates a PersistenceContext in conversationScope on flow startup, and uses that context for data access until the conversation ends. - This pattern generally employs a manual flush mode; that is, the application decides when to flush changes to the database. - A convention for flow-managed flushing may be employed, such as always flushing after a transition from one view-state to another. - This pattern provides no flow-level isolation of intermediate edits since flushing synchronizes persistent object state with the database. - With this pattern, all data access generally occurs non-transactionally. - - - An implementation of this flow-managed persistence pattern is not yet available in the Web Flow distribution, and will be considered for future releases. - - - - ViewState PersistenceContext - - This pattern creates a PersistenceContext with a read-only transaction before view rendering. - The context is used to load the model for the view. It stays open through view rendering and commits after rendering completes. - Then on the occurrence of an event, this pattern creates a fresh PersistenceContext with a read-write transaction. - The model is merged with the new context and any changes are committed after event handling completes. - Therefore, this pattern results in edits being saved to the DB after each event. Any rollback of intermediate flow steps requires compensating transactions. - This pattern is often used in conjunction with an optimistic locking strategy to protect the integrity of data modified in parallel by multiple users. - This pattern stores much less flow state, but generally increases the amount of data access since persistent entities are fetched and flushed more often. - - - An implementation of this flow-managed persistence pattern is not yet available in the Web Flow distribution, and will be considered for future releases. - - \ No newline at end of file diff --git a/spring-webflow-reference/src/views.xml b/spring-webflow-reference/src/views.xml index fdc5b3d6..dc278c9a 100644 --- a/spring-webflow-reference/src/views.xml +++ b/spring-webflow-reference/src/views.xml @@ -319,63 +319,88 @@ public class StringToMonetaryAmount extends StringToObject { Validating a model - Model validation is driven by constraints specified against the model object. - These constraints may be specified declaratively, or enforced using a programmatic validation routine or external Validator. + Model validation is driven by constraints specified against a model object. + Web Flow supports enforcing such constraints programatically. Programmatic validation There are two ways to perform model validation programatically. - Both options use a ValidationContext parameter for recording validation error messages in addition to the current Principal and user event that triggered validation. - The user event is the same value that matches against the 'on' attribute of a transition. - - - Prior to Web Flow 2.0.4, a MessageContext was required instead of a ValidationContext. - This style validator is still supported, however, the ValidationContext provides access to the MessageContext and additional information. + The first is to implement validation logic in your model object. + The second is to implement an external Validator. + Both ways provide you with a ValidationContext to record error messages and access information about the current user. Implementing a model validate method - The first way is to define a validate method on the model object class. - To do this, create a public method with the name validate${state}, where state is the id of your view-state. + Defining validation logic in your model object is the simplest way to validate its state. + Once such logic is structured according to Web Flow conventions, Web Flow will automatically invoke that logic during the view-state postback lifecycle. + Web Flow conventions have you structure model validation logic by view-state, allowing you to easily validate the subset of model properties that are editable on that view. + To do this, simply create a public method with the name validate${state}, where ${state} is the id of your view-state where you want validation to run. For example: +} +]]> + + In the example above, when a transition is triggered in a enterBookingDetails view-state that is editing a Booking model, + Web Flow will invoke the validateEnterBookingDetails(ValidationContext) method automatically unless validation has been suppressed for that transition. + An example of such a view-state is shown below: + + + +]]> + + + Any number of validation methods are defined. Generally, a flow edits a model over a series of views. In that case, a validate method would be defined + for each view-state where validation needs to run. + Implementing a Validator The second way is to define a separate object, called a Validator, which validates your model object. - To do this, create a class that defines a public method with the name validate${state}, where state is the id of your view-state. + To do this, first create a class whose name has the pattern ${model}Validator, where ${model} is the capitialized form of the model expression, such as booking. + Then define a public method with the name validate${state}, where ${state} is the id of your view-state, such as enterBookingDetails. + The class should then be deployed as a Spring bean. Any number of validation methods can be defined. For example: + + In the example above, when a transition is triggered in a enterBookingDetails view-state that is editing a Booking model, + Web Flow will invoke the validateEnterBookingDetails(Booking, ValidationContext) method automatically unless validation has been suppressed for that transition. + A Validator can also accept a Spring MVC Errors object, which is required for invoking existing Spring Validators. @@ -386,12 +411,13 @@ public class BookingValidator { - - Declarative validation + + ValidationContext - Spring Web Flow does not yet ship integration with a declarative validation framework such as Hibernate Validator. - It is expected that integration will be provided in a future Web Flow release. - This integration will allow declarative validation constraints to be defined against model properties. + A ValidationContext allows you to obtain a MessageContext to record messages during validation. + It also exposes information about the current user, such as the signaled userEvent and the current user's Principal identity. + This information can be used to customize validation logic based on what button or link was activated in the UI, or who is authenticated. + See the API Javadocs for ValidationContext for more information.