Spring is a great addition to your Java stack.  It helps you access the request for inside your Spring beans easily.  Maybe I'm doing it wrong, but reading the request body seems blasted verbose after that.  It takes a surprising amount of code.  



## Access the Request

Spring's bread and butter, of course, is inversion of control.  So, to get to the request object itself is no big deal.  Just inject it (canonical packages shown for… fun, mostly):

```java
@javax.inject.Inject
javax.servlet.http.HttpServletRequest req;
```

And now for the pile of non-abstracted code.

## Parse the Body

Number one, the body is accessed from the [`HttpServletRequest`](http://docs.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html) object it a place that wasn't obvious to me: `request.getReader()`.  Heads up, we've got a BufferedReader here.  Hey, at least we don't get a stream that we have to wrap in more than one reader!

```java
private String getBody() {
  String body = "";
  if (req.getMethod().equals("POST") )
  {
    StringBuilder sb = new StringBuilder();
    BufferedReader bufferedReader = null;

    try {
      bufferedReader =  req.getReader();
      char[] charBuffer = new char[128];
      int bytesRead;
      while ((bytesRead = bufferedReader.read(charBuffer)) != -1) {
        sb.append(charBuffer, 0, bytesRead);
      }
    } catch (IOException ex) {
      // swallow silently -- can't get body, won't
    } finally {
      if (bufferedReader != null) {
        try {
          bufferedReader.close();
        } catch (IOException ex) {
          // swallow silently -- can't get body, won't
        }
      }
    }
    body = sb.toString();
  }
  return body;
}
```
    
The code.  There is to much.  Let me sum up.  There's only going to be a body if you are doing a post.  Otherwise, don't worry about it.  If there is data, pull it into a string.  Everything else is for (not) handling errors.

There's a bit there.  It's not the worst.  But after getting used to [Express' bodyParser](http://expressjs.com/api.html#req.body), it was hard to see this.

Want to read the body of a request within a Spring bean?  It takes a surprising amount of code.

Read Request Body in Spring Bean

Spring Security (previously Acegi) gives you an awesome AOP way of locking down methods in your Java application.  And well-placed <a href="http://www.youtube.com/watch?v=ldFOHUaf2zg">lock down</a> is a special power indeed.  However, Spring disappoints a bit on this score because it turns out its default behavior is to 'or' the roles listed in @Secured annotation.  You'd think the default would be the stricter 'and', but alas.  But never fear, there is hope.


*Updated (21 June 2012)*:

The easy way
------------

This article can be simplified into this line of code:

```java
@PreAuthorize("hasRole('ROLE_role1') and hasRole('ROLE_role2')")
```

There are other combo options [as documented by Spring](http://static.springsource.org/spring-security/site/docs/3.0.x/reference/el-access.html).

If you wish to go on, enjoy the custom code and xml config that follows:  :)

There is always hope.  

Note:  My experimentation with this and the line numbers in files mentioned here are from spring-security-core/3.0.7.RELEASE.

GrantedAuthority
----------------

Your authorities populator or however you're getting roles assigned to your user will eventually place them in the place that you can get to them programmatically: 

```java
SecurityContextHolder.getContext().getAuthentication().getAuthorities()
```

And here is where the @Secured annotation will eventually look for them (AbstractSecurityInterceptor.java:204):

```java
Collection<ConfigAttribute> attributes = this.obtainSecurityMetadataSource().getAttributes(object);
```

This collection of `GrantedAuthorities` is are the roles that have been assigned to the user associated with your request to a method.
    
@Secured
--------

When you want only users with certain authorities to access methods, you apply the `@Secured` annotation to the method needing protection.  Also note that you can specify multiple roles in this annotation:

```java
@Secured({"role1", "role2"})
public void makeSomethingAwesome() {
  // pure awesome
}
```

Again, to note what is important and initially stunned me:  By default, you just need one of these roles (either role1 OR role2) to make it into the innards of this awesomeness.  This is because of the default configuration.  From the [Spring Security docs](http://static.springsource.org/spring-security/site/docs/3.0.x/reference/ns-config.html):

The default strategy is to use an AffirmativeBased AccessDecisionManager with a RoleVoter and an AuthenticatedVoter. 

Role Name Prefix
----------------

Another point worth making is about the prefix required for roles.  Roles that are counted by the `RoleVoter` are only seen as roles if they start with the specified prefix.  By default, `RoleVoter` sees this prefix as "ROLE_".  It is settable, but be warned that your roles will count for nothing and your `@Secured` method will be totally exposed unless it looks something like this:

```java
@Secured({"ROLE_role1", "ROLE_role2"})
public void makeSomethingAwesome() {
  // pure awesome that is now protected
}
```

From the `RoleVoter` docs:

> Votes if any ConfigAttribute#getAttribute() starts with a prefix indicating that it is a role. The default prefix string is <code>ROLE_</code>, but this may be overridden to any value. It may also be set to empty, which means that essentially any attribute will be voted on. As described further below, the effect of an empty prefix may not be quite desirable.

The 2 Keys
----------

There are two key interfaces that Spring Security is using to determine how you want your roles checked that you specify in the `@Secured` annotation:

- AccessDecisionManager implemented as AffirmativeBased, ConsensusBased or UnanimousBased
- AccessDecisionVoter, implemented as RoleVoter

The decision manager is the class that has a collection of voters.  The decision manager orchestrates the voters and asks each in turn whether the requesting user should be let through the `@Secured` annotation or denied.  By default, the `AffirmativeBased` manager is used.  

Each decision manager functions differently in how it counts the votes of its voters:

- AffirmativeBased - if any voter comes votes 'yes' or 'access granted', the manager allows access
- ConsensusBased - this manager is majority rules.  There can be votes 'yes' and 'no', and as long as 'yes' votes outnumber 'no' votes, access is allowed
- UnanimousBased - this manager requires every voter to vote 'yes' or else access is denied

Since this discussion is based around roles, we only care to use Spring's `RoleVoter`.  Here's part of its implementation, starting on line 98:

```java
public int vote(Authentication authentication, Object object, Collection<ConfigAttribute> attributes) {
  int result = ACCESS_ABSTAIN;
  Collection<GrantedAuthority> authorities = extractAuthorities(authentication);

  for (ConfigAttribute attribute : attributes) {
    if (this.supports(attribute)) {
      result = ACCESS_DENIED;

      // Attempt to find a matching granted authority
      for (GrantedAuthority authority : authorities) {
        if (attribute.getAttribute().equals(authority.getAuthority())) {
          return ACCESS_GRANTED;
        }
      }
    }
  }

  return result;
} 
```

Verbalized, this `vote()` method goes through each role specified in the `@Secured` annotation and for each of those checks whether the user has that role.  If he does, the voter returns its vote as 'yes'.  Got that?  _At the first match, the vote is yes_.  This is a logical 'or'.

Making the role vote a logical 'and'
------------------------------------

I don't want my roles 'or'ed together.  I want the uesr to be required to have them all in combination or I will deny him access.  Since we've already shown that the default `RoleVoter` uses a logical 'or' operation, I guess we'll need to write our own role voter that uses a logical 'and'.  Potentially, that might be called 'HasAllRolesVoter', and  might look like this:

```java
public class HasAllRolesVoter extends RoleVoter {

  @Override
  public int vote(Authentication authentication, Object object, Collection<ConfigAttribute> attributes) {
    Collection<GrantedAuthority> authorities = authentication.getAuthorities();
    int requiredMatches = attributes.size();
    int matches = 0;
    for (ConfigAttribute attribute : attributes) {
      if (this.supports(attribute)) {
        for (GrantedAuthority authority : authorities) {
          if (attribute.getAttribute().equals(authority.getAuthority())) {
            ++matches;
            break;
          }
        }
      }
    }

    int result = ACCESS_ABSTAIN;
    if (requiredMatches > 0 && matches < requiredMatches) {
      result = ACCESS_DENIED;
    } else if (matches > 0 && matches == requiredMatches) {
      result = ACCESS_GRANTED;
    }
    return result;
  }
}
```

It looks much like `RoleVoter`.  It extends `RoleVoter` and overrides `vote()`, which now goes through the roles on the `@Secured` annotation, checks each against the roles of the user, incrementing a count with each match.  If, in the end, there are as many matches as roles specified, we've found them all.  This is just a potential implementation.  There are probably many better was to get this done.

So now can we do a logical 'and'?  Yes.  There are 3 ways of accomplishing this (and probably more):

1. AffirmativeBased w/ HasAllRolesVoter
2. ConsensusBased w/ HasAllRolesVoter
3. UnanimousBased w/ RolesVoter

Note that in the last option `UnanimousBased` access manager can use just the plain jane `RolesVoter`.  This is because `UnanimousBased` calls the `RoleVoter` up for vote for each individual role (one by one via the `singleAttributeList`) as opposed to the roles as a collection.  Thus, that combination ignores the fact that `RoleVoter` normally 'or's matching roles together.

Configuration
-------------

So, there really hasn't been too much to this solution.  But as with most frameworks of this flexibility and complexity, the key is knowing how to actually specify that you want it to work this way.  To specify a `UnanimousBased` access manager using the plain `RoleVoter` (my eventual solution for my own problem) looks something like this:

```xml
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:sec="http://www.springframework.org/schema/security">
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
         http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.0.xsd">

  <bean id="accessDecisionManager" class="org.springframework.security.access.vote.UnanimousBased">
    <property name="decisionVoters">
      <bean class="org.springframework.security.access.vote.RoleVoter" />
    </property>
    <property name="allowIfAllAbstainDecisions" value="false" />
    <property name="messageSource" ref="messageSource" />
  </bean>

  <sec:global-method-security secured-annotations="enabled" jsr250-annotations="enabled" pre-post-annotations="enabled"
    access-decision-manager-ref="accessDecisionManager" />

</beans>
```

Smooth as butter.  As with most Spring solutions, the answer was in an xml configuration.  Oh boy.

Spring Security (previously Acegi) gives you an awesome AOP way of locking down methods in your Java application.  And well-placed <a href="http://www.youtu

'And' Spring @Secured Roles

Our app throws all sorts of exceptions.  Well, it doesn't usually.  It shouldn't normally.  Er... But, when it does we want to put in some handling so that the app doesn't blow up in some unsuspecting user's face.  And even then, sometimes we want special handling for certain exceptions and make sure others are just caught.  And that's what we'll do with AccessDeniedException.



The Simple Case
---------------

In the simple case, all exceptions that bubble up to the servlet container will just need to be caught and a user needs to get a nice view instead of stack trace shown to them.  There's a nice class called `SimpleMappingExceptionResolver` that does, in fact, resolve this.  Provide it with the mappings from exception types to views that you've created, and as exceptions surface, the user will be shown the views instead of the exceptions.  Here's the config:

```xml
<bean class="org.springframework.web.servlet.handler.SimpleMappingExceptionResolver">
  <property name="exceptionMappings">
    <props>
      <prop key=".AccessDeniedException">errors/accessDenied</prop>
      <prop key=".DataAccessException">errors/dataAccessFailure</prop>
      <prop key=".TypeMismatchException">errors/resourceNotFound</prop>
      <prop key=".NoSuchRequestHandlingMethodException">errors/resourceNotFound</prop>
      <prop key=".MissingServletRequestParameterException">errors/resourceNotFound</prop>
    </props>
  </property>
  <property name="defaultErrorView" value="errors/generalError"/>
  <property name="warnLogCategory" value="com.rockycode"/>
</bean>
```

As it turns out, this is perfect for the simple case.  What if I want something special?  And when don't I?!

Custom HandlerExceptionResolver
-------------------------------

In my case, I want to catch `AccessDeniedException` just like all others, except I want to do some special checking of the user attributes who just go rejected via Spring Security.  This means I need a custom `HandlerExceptionResolver`.  And thankfully these things aren't all that complicated.  Something custom to handle our `AccessDeniedException` might be called `AccessDeniedExceptionResolver` and looks somewhat like this:

```java
public class AccessDeniedExceptionResolver implements HandlerExceptionResolver, Ordered {

  private int order;

  public ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) {
    ModelAndView view = null;
    if (ex instanceof AccessDeniedException) {
      // super special handling lives here
      view = new ModelAndView("specialness");
    }
    return view;
  }

  // .. getters and setters ..
}
```

The `resolveException()` method is where the magic goes.  I only care about a certain type of exception, so I check for it and do special stuff.  If not, the `view` is returned as null with just falls through to the next resolver in line if there is one.  And blast it, we want one.  Let's just use our existing simple case resolver.


Setting up 2 ExceptionResolvers
-------------------------------

In `AccessDeniedExceptionResolver`, we implemented `Ordered`.  This shows priority in a potential string of resolvers.  We're going to setup our resolver for the specific case to be higher priority (lower number), remove the `AccessDeniedException` entry on `SimpleMappingExceptionResolver` and add an order property to it:

```xml
<bean class="org.springframework.web.servlet.handler.SimpleMappingExceptionResolver">
  <property name="exceptionMappings">
    <props>
      <prop key=".DataAccessException">errors/dataAccessFailure</prop>
      <prop key=".TypeMismatchException">errors/resourceNotFound</prop>
      <prop key=".NoSuchRequestHandlingMethodException">errors/resourceNotFound</prop>
      <prop key=".MissingServletRequestParameterException">errors/resourceNotFound</prop>
    </props>
  </property>
  <property name="defaultErrorView" value="errors/generalError"/>
  <property name="warnLogCategory" value="com.rockycode"/>
  <property name="order" value="1"/>
</bean>

<bean class="com.rockycode.AccessDeniedExceptionResolver">
  <property name="order" value="0"/>
</bean>
```

Slap that config in your app context and sing for joy.  Now you can create as many custom handlers as you'd like and just string em up like clean laundry on the line.

Our app throws all sorts of exceptions.  Well, it doesn't usually.  It shouldn't normally.  Er... But, when it does we want to put in some handling so that

Custom Exception Handling for AccessDeniedException

In addition to some sweet Inversion of Control injection action, Spring brings flowers and baby deer.  And it brings some nice database connection help.  Spring JdbcTemplate is a vanguard of strength and ease for connecting to your favorite RDBMS.  And it so happens that the DBA I'm working with right now digs the stored procs.  So, we'll meet in the middle with some more goodness born of Spring.



StoredProcedure
-----------------

Blessed Rod Johnson gives us the `org.springframework.jdbc.object.StoredProcedure`.  It's abstract, and you'll want to extend it and fully implement it in order to specify what stored proc in your database you're calling.  And here's a sample implementation:

```java
@Component
public class ItemInsert extends StoredProcedure {
  public static final String SPROC_NAME = "schema.oracle_pkg.proc_name";
  public static final String INPUT_PARAM = "input_prm_name";
  public static final String OUPUT_PARAM = "output_prm_name";

  @Inject
  public ItemInsert(DataSource ds) {
    super(ds, SPROC_NAME);
    declareParameter(new SqlParameter(INPUT_PARAM, Types.VARCHAR));
    declareParameter(new SqlOutParameter(OUTPUT_PARAM, Types.NUMERIC));
    compile();
  }
 
  public Item insert(Item item)
      throws DataAccessException {
    Map<String, Object> inputs = new HashMap<String, Object>();
    inputs.put(INPUT_PARAM, item.getSomething());
    Map<String, Object> output = super.execute(inputs);
    Object newId = output.get(OUTPUT_PARAM);
    if (newId != null) {
      item.setId(Long.parseLong(newId.toString()));
    }
    return item;
  }
}
```

Points to consider:

- `ItemInsert` is itself injectable as a Spring bean `@Component`.
- Input and output parameters are declared in the constructor
- `insert()` is where `super.execute()` is call, which is the function that really does the magic.

The only other interesting thing...

Execute()
-----------

From the JavaDoc:

  Execute the stored procedure. Subclasses should define a strongly typed execute method (with a meaningful name) that invokes this method, populating the input map and extracting typed values from the output map. Subclass execute methods will often take domain objects as arguments and return values.  Alternatively, they can return void.

Thusly, out method is called `insert()` because it's a meaningful name.  It takes our domain object, `Item` and pulls out the necessary fields inside the method, putting them into a map for the call `super.execute()`.

Call it from a service
----------------------

Now the only work left is just to call your awesome procedure and use the results for something wonderful.  Eg, 

```java
@Service
public class ItemServiceImpl implements ItemService {
      
  @Inject
  private ItemInsert itemInsert;

  public Item doWonderfulThingsWithItems(Item item) {
    return itemInsert.insert(item);
  }

}
```

Items are now stored procedurally and you can rest easy knowing that Oracle has all your data.

In addition to some sweet Inversion of Control injection action, Spring brings flowers and baby deer.  And it brings some nice database connection help.  Sp

Stored Procedures in Spring Jdbc

My first experience with [Spring Webflow](http://www.springsource.org/webflow) is on a project that uses Webflow 1.0.5.  So far, I'm impressed.  Apparently, Webflow 2 offers even more incredible awesomeness, but thusfar I would put my webflow experience over that of my previous couple years in Seam.  (I was just waiting for a chance to abandon that library anyway.)  



A few quick observations based on my limited Webflow exposure:  Conversation control seems more granular.  Starting subflows (sub-conversations) is very easy and clean up well after themselves.  Webflow keeps flow/nav all in related webflow xml, which are clearly hierarchical and separated.  Webflow also seems to have a clearer and easier-to-follow syntax in its xml.

In my 2 days on this project with Webflow, I saw what I thought looked like a fair amount of duplicate xml code in the *-flow.xml files.  This smell led me to perservere on a better solution.  Thus, recorded here, is my method for creating a reusable state that has behavior specific to the code that is using it.  Specifically, for a view-state that navs to an action-state, that action-state's back/error transition can know how to return to the state that just invoked it.

Here's the view-state:

```xml
<view-state id="startingView" view="/start.xhtml">
  <transition on="return" to="processReturn">
      <set attribute="returningFrom" value="${'startingView'}" scope="flash"></set>
  </transition>
</view-state>
```


And the action-state:

```xml
<action-state id="processReturn">
  <bean-action bean="service" method="saveAndReturn">
      <method-result name="saveSuccessful" scope="flash"></method>
  </bean-action>
  <transition on="${flashScope.saveSuccessful}" to="backToIndex"></transition>
  <transition on="${!flashScope.saveSuccessful}" to="${flashScope.returningFrom}"></transition>
</action-state>
```

So, when the transition in the view for "return" is hit, we save an attribute in the flash scope, which is maintained over redirects in the flow, the value being the id of the view-state from which we're coming.  When we get to the action-state, if we find that our action was unsuccessful, we grab the attribute from the flash scope and transition back to that view-state with the given id.  Thus, we don't have to have a separate action-state for each view-state that might want to use similar functionality because we have parameterized the specific data/functionality.

Note: I had to use the ${'literal'} syntax for the attribute value.  I'm not sure if this is a quirk of Webflow 1 or my project.

Viva la Webflow.  That, or just write SOUIT apps!

My first experience with Spring Webflow is on a project that uses Webflow 1.0.5.

Parameterized States in Webflow

In developing an email notification system recently, we became interested in code acting differently depending on what environment we were in.  A potentially good solution for this is environment-based dependency injection.  This means that different Spring beans, for instance, will be used depending on the environment, ie dev, test, etc.  This is useful for something like emailing, because we may not want real emails hitting the mail server in dev or test environments, but we do in prod.  With some Spring constructs, it's pretty easy.



If you have property files that Spring knows about, you could put entries in like this in `defaultContext-dev-test.properties`:

```text
mailProvider=devTestEmailServiceImpl
```

And in `defaultContext.properties`:

```text
mailProvider=emailServiceImpl
```

Then, in your Spring bean `serviceBeanContext.xml` file:

```xml
<alias alias="emailService" name="@{mailProvider}"/>
```

The `@{}` notation is for finding variables of that name in a properties file.  Finally, in your Java code, you can reference the alias that will be different depending on your environment:

```java
@Autowired
@Qualifier("emailService")
private EmailService emailService;
```

In developing an email notification system recently, we became interested in code acting differently depending on what environment we were in.  A potentiall

Environment-based Dependency Injection

Meet the new web.  The simpler the better. The cleaner the better.  The more pleasing the colors the better.  The fuzzier feelings the better.  The latest fuzzies have been brought on by a slew of modals.  Previously, we haven't used many modals in our layouts and designs, so here's the first working pattern on how to get this kind of stuff working.  

This solution allows content to appear in a modal, validation errors to post back to the modal, edits made in a modal to persist back to the database, and success messages to appear on parent page.



Meet the new web.  The simpler the better. The cleaner the better.  The more pleasing the colors the better.  The fuzzier feelings the better.  The latest fuzzies have been brought on by a slew of modals.  Previously, we haven't used many modals in our layouts and designs, so here's the first working pattern on how to get this kind of stuff working.  

This solution allows:
<ul>
<li>Content to appear in a modal</li>
<li>Validation errors post back to the modal</li>
<li>Edits made in a modal persist back to the database</li>
<li>Success messages appear on parent page</li>
</ul>

Example uses these technologies:
<ul>
<li>JSF/Facelets</li> 
<li>Spring 2.5</li> 
<li>JPA/Hibernate</li> 
<li>Hibernate validators</li> 
<li>Seam</li> 
<li>JQuery</li> 
</ul>

This includes these pieces:
<ul>
<li>Parent JSF</li> 
<li>JQuery for Modal - using <a href="">jQuery</a> and <a href="">jqModal</a></li> 
<li>Modal JSF</li> 
<li>Seam pages.xml for navigation</li> 
<li>View bean</li> 
<li>Model object</li> 
</ul>

Overall, the flow occurs as follows:
<ul>
<li>Nav to parent page</li> 
<li>Trigger modal with link</li> 
<li>Modal appears </li> 
<li>Content is loaded in modal</li> 
<li>Submissions occur via AJAX to the view bean</li> 
<li>View bean logic and Seam determine outcome</li> 
<li>If errors, AJAX re-renders in modal</li> 
<li>If save successful, parent page is re-rendered with message</li> 
</ul>

<br />
<h2>The Parent Page (person-info-personal.xhtml)</h2>

<h3>Javascript for Modal:</h3>
```javascript
<script type="text/javascript" src="#{request.contextPath}/scripts/jquery.pack.js"></script>
<script type="text/javascript" src="#{request.contextPath}/scripts/jqModal.pack.js"></script>
<script type="text/javascript">
    jQuery(document).ready(function() {
        jQuery('#modal-edit-personal').jqm({
            ajax: '#{request.contextPath}/person-info-personal-edit.jsf?personId=#{personDetailsBean.person.id}&amp;conversationId=#{conversation.id}&amp;time=#{personDetailsBean.currentMillis}',
            trigger: '#btn-edit-personal',
            modal: true
        });
    })
</script>
```

<strong>Note:</strong>
<ul>
<li>The Seam conversation object is just available.  No convenience method required to retrieve it.</li>
<li>Additional url parameter required to get around an IE caching issue.  We just need a unique value so that the AJAX request isn't assumed cached by IE.  In this case, I used the current time in milliseconds (Method on view bean).</li>
</ul>

<h3>Trigger for Modal:</h3>
```jsp
<a id="btn-edit-personal" class="edit-link-icon edit-link float-right" href="#">Edit</a>
```

<h3>Modal Container:</h3>
```jsp
<div id="modal-edit-personal" class="jqmWindow smallWindow"></div>
```
<strong>Note:</strong>
- Just include this right before the end of the html body.  

<h3>Style for Modal</h3>
```css
.smallWindow {components.css (line 105)
  margin-left:-250px;
  top:15%; 
  width:500px;
}
.jqmWindow {components.css (line 84)
  background-color:#FFFFFF;
  border:5px solid #DDDDD3;
  color:#333333;
  display:none;
  left:50%;
  margin-left:-375px;
  padding:5px;
  position:fixed;
  top:8%;
  width:750px;
  z-index:3000 !important;
}
```

<h3>Success Validation Message</h3>
```jsp
<h:panelGroup rendered="#{param['saveSuccess'] ne null}">
    <div id="edit-success" class="alert" style="display: block;">
        <p>Success: Changes saved for #{personDetailsBean.person.name.fullName}.</p>
    </div>
</h:panelGroup>
```
<strong>Note:</strong>
<ul>
<li>The parameter to determine ability to render is just a param[].  It's not bound to the bean, which means it disappears on subsequent requests, which is what we want.</li>
</ul>

<h2>Seam Navigation</h2>

<h3>pages.xml Entry for modal:</h3>
```xml
<page view-id="/person-info-personal-edit.xhtml">
    <begin-conversation join="true" flush-mode="MANUAL"></begin-conversation>
    <param name="personId" value="#{personDetailsBean.personId}"></param>
    <action execute="#{personDetailsBean.loadPerson}" if="#{personDetailsBean.person eq null}"></action>
    <navigation>
        <rule if-outcome="saved-person-edit">
            <redirect view-id="/person-info-personal.xhtml">
                <param name="personId" value="#{param['personId'] != null ? param['personId'] : personId}"></param>
                <param name="saveSuccess" value="true"></param>
            </redirect>
        </rule>
    </navigation>
</page>
```
<h3>pages.xml Entry for parent:</h3>
```xml
<page view-id="/person-info-personal.xhtml">
	<begin-conversation join="true" flush-mode="MANUAL"></begin-conversation>
	<param name="personId" value="#{personDetailsBean.personId}"></param>
	<action execute="#{personDetailsBean.loadPerson}" if="#{personDetailsBean.person eq null}"></action>
	
</page>
```
<strong>Note:</strong>
<ul>
<li>The "saveSuccess" parameter is the key to showing the success message on the parent page.</li>
</ul>

<h2>The Modal Page (person-info-personal-edit.xhtml)</h2>

<h3>Modal Markup:</h3>
```jsp
<a4j:form id="info-edit-form" ajaxSubmit="true" reRender="alerts">

    <a4j:outputPanel id="alerts">
        <ldsp:alerts />
    </a4j:outputPanel>

    <div class="target">
        <h2>Edit Personal Information</h2>

        <p>Please make the necessary changes and press "Save" when finished.</p>

        <div id="notes">
            <dl>
                <dt>Official Name</dt>
                <dd>
                    #{personDetailsBean.person.name.fullName}
                </dd>
            </dl>
            <dl class="short-inputs">
                <dt>Preferred Name</dt>
                <dd>
                    <h:inputText styleClass="input-text pref-name-field" value="#{personDetailsBean.person.preferredFirstName}" required="true" requiredMessage="Preferred first name required." />
                </dd>
                <dd>
                    <h:inputText styleClass="input-text pref-name-field" value="#{personDetailsBean.person.preferredMiddleName}" required="true" requiredMessage="Preferred first name required." />
                </dd>
                <dd>
                    <h:inputText styleClass="input-text pref-name-field" value="#{personDetailsBean.person.preferredLastName}" required="true" requiredMessage="Preferred first name required." />
                </dd>
            </dl>
            <dl>
                <dt>Blood Type</dt>
                <dd>
                    <h:selectOneMenu value="#{personDetailsBean.person.bloodType}">
                        <f:selectItem value="#{null}" itemLabel="None given" />
                        <f:selectItems value="#{personDetailsBean.bloodTypesList}" />
                    </h:selectOneMenu>
                </dd>
            </dl>

            

            <p class="buttons">
                <h:commandButton action="#{personDetailsBean.savePerson}" value="Save" styleClass="button-default" />
                <input type="button" class="button-nondefault jqmClose" value="Cancel" />
            </p>
        </div>
    </div>
</a4j:form>
```

<strong>Note:</strong>
<ul>
<li>&lt;ldsp:alerts /&gt; - custom component to display Alerts.</li>
<li>The ajaxSubmit attribute on the a4j:form must use a capital S for 'Submit'.  (My code renderer on this page is lowercasing that for some reason.)  Same with the 'r' on 'reRender'.</li>

<h2>Server-side Logic</h2>

<h3>Java Model:</h3>
```java
@Entity
public class Person implements Serializable {
    @Column(name = "PREF_FIRST")
    private String preferredFirstName;

    @Column(name = "PREF_MIDDLE")
    private String preferredMiddleName;

    @Column(name = "PREF_LAST")
    private String preferredLastName;

    @Column(name = "BLOOD_TYPE")
    private String bloodType;

    /** ... */
}
```

<h3>View Bean:</h3>
```java
@Controller
@Scope("conversation")
@SuppressWarnings("serial")
public class PersonDetailsBean implements Serializable {
   public String savePerson() {
       String retval = null;
       try {
            personDetailsService.modifiyPerson(getPerson()); // saves missionary
            retval = "saved-person-edit"; 
       } catch (OptimisticLockException e) {
            Alert.addErrorAlert("Optimistic Lock: The object was modified out from under you.");
       }
       return retval;
   }
   // Method to circumvent IE caching issue
   public long getCurrentMillis() {
       return new Date().getTime();
   }
   /* ... */
}
```

Meet the new web.  The simpler the better. The cleaner the better.  The more pleasing the colors the better.  The fuzzier feelings the better.  The latest f