You can implement the 3 checkboxes without any kind of state management. You hook the checkboxes to 3 boolean properties in a request scoped bean and have the bean fetch the data based on the 3 boolean values. Each time you post the form back the values are put into the bean, used to generate the sql, and the 3 values are rendered back to the page. So the values are held client side, posted back, validation is performed and the boolean values and error messages are sent back down to the client. While Ajax may only update part of the page, you would need to post back the whole form (all 3 boolean values) to be able to generate the sql. On the plus side, it would be completely stateless since the state is stored on the client.

Could you advise to me for these problems:
I’m using Trinidad components and just those, ’cause I have to. There is a form with some input components
(combobox, inputtext etc.) and a send button. I have to enforce some form constraints without rerender the whole page like Ajax do I guess, but I must not use Ajax just Trinidad. It’s like booking-faces sample application’s client side validators for credit card number and name but it’s more complicated ’cause it’s server side and context aware if you know what I try to mean (e.g. input fields’ readonly value depends on another input fields’ values). As I see my only options are the value change listeners.

If I have 3 single checkbox on the page that change for example a SQL selection should I make a stateful backing bean to store these 3 values or may I just store them in scope variables?

You seem to be focused on using event listeners to handle form interaction when you really just need to worry about it when the form is posted. With spring web flow, the form is posted with an action string <h:commandButton action=”doSomething”/>, and any processing is invoked by the spring web flow in response to the “doSomething” action.

Take a look at my Seam versus Spring Web Flow / Wicket articles :

http://www.andygibson.net/blog/index.php/2009/08/01/seam-versus-spring-web-flow-versus-wicket/

It includes a whole chapter on using Spring Web Flow in an application that lets you view/edit/list items and it uses JSF. That should give you an idea.

Cheers,

Andy

First I’m glad you answered me so soon. I guess my comments would be right place in your “Creating A Spring Web Flow JSF Project From Scratch” post.

If I can reach the model layer from Spring JSF backing beans through injected service layer or DAO layer then what’s the purpose of flow definition and the whole SWF? I think it breaks the Spring MVC concept. The Spring JSF Beans assume the responsibility or role of Spring controllers . Wouldn’t be simplier to use just Spring JSF Beans which delegate to service layer etc. like before the SWF was. Nowadays it’s simplier thanks to the fact now Spring has the ability to manage the JSF backing beans in it’s container. It’s not clear for me yet what SWF can do for me. It looks awesome theoretically but in practice there are problems without a clear answer given by SWF. I don’t like mixing technologies this way.

Here is another simple task. What if I have two inputtext component on a page and when I write into the first one some text such as “blue” the other one changes its color to blue. I think it’s a too fine-grained problem, so the flow can’t handle this. I have to put this code into a backing bean. How did you solve this with just the good old Spring MVC? What did you write into the controller to handle this task?

Regards,
Arnold

Typically, value change listeners would go on the backing bean, which in Seams case is the EJB/Seam POJO and for Spring it would be a spring bean. Since you mention Spring Web Flow, you could make it reference a backing bean that is part of the web flow and it would be a stateful backing bean. You would access data the same way you do in beans in other places.

With Spring, you should be putting your data access code into a service layer or a DAO layer that is injected into your spring JSF backing beans or Spring MVC controllers so they can use the data access features of those beans.

Hope this helps,

Cheers,

Andy Gibson