JSF Central - Jeremy Grelle digs into JSF, Spring Faces, and Spring Web Flow
JSF Central

 
 Home 
 
 Products 
 
 Articles & Books 
 
 Resources 
Community Chat
 
Jeremy Grelle digs into JSF, Spring Faces, and Spring Web Flow
by Kito Mann
20 Dec 2009 23:00 EST

In this podcast, JSFCentral editor-in-chief Kito D. Mann talks with Jeremy Grelle about Spring Web Flow and Spring Faces.


Podcast (MP3)
Welcome to the JSFCentral podcast #18 for the week of December 14th. This series of podcasts features interviews, news, and commentary for those working with JavaServer Faces technology. This interview was recorded in March of 2009 at The Server Side Symposium in Las Vegas, NV.
Kito Hello, my name is Kito Mann. I am here at TheServerSide Java Symposium 2009, once again in sunny Las Vegas. I am here with Jeremy Grelle, who is a Senior Software Engineer - is that your title?
Jeremy That is my official title.
Kito At SpringSource, but you can think of him as the Spring Web Flow, Spring Faces, Spring anything web guy.
Jeremy Basically anything on the Spring web tier I have got my hands on.
Kito Anything else you want to add in terms of your bio?
Jeremy I am on the JSF expert group as well -- because of all my other Spring projects, not as active as I would like to be. I have just been doing this awhile, trying to improve Java web development. That is essentially the sole function of my job.
Kito And talking at conferences. Jeremy did a great session on Spring 3.0 today. You can always find him at random conferences. So how did you get involved with SpringSource?
Jeremy Basically I had been doing a lot of Web Flow with my previous company with JSF, with Web Flow 1.0 actually. I found that Web Flow greatly improved what we were trying to do with some pretty complex JSF applications and this was back in JSF 1.1 days. The whole problem there with not having a finer grain scope than session scope -- that whole canonical JSF problem -- we found that Web Flow fit really well in there, but the JSF integration in Web Flow at first was not 100% perfect. We had to do a good bit of extension of it. That is how I really got involved with the project. I started feeding back a number of contributions to keep Donald -- who is the lead of the project -- feeding things back through the forms and JIRA and everything. So that is how Keith and I got to know each other and around the time that they started expanding the R and D department, he called me up and said "hey do you want to come work for us?" And the original intention was to focus on Web Flow 2, which he was just about to start working on, and really re-think the way Web Flow integrates with JSF.
Kito Okay.
Jeremy That's how I started but my broad knowledge of all things in the browser/JavaScript/CSS and other specs have kind of allowed me to get my hands on other things as well. I have branched out beyond the JSF stuff but that is how it all started.
Kito Okay, That explains a lot. I had seen Keith around then all of a sudden I started seeing you and Spring Faces and so it started to make a little bit more sense. Why dont you explain to people what Spring Web Flow is and what Spring Faces is?
Jeremy Spring Web Flow is essentially at its core it is a state machine. It allows you to maintain conversational state for web applications so you can have extended user conversations that take place over multiple steps, whether they be multiple steps between separate views, or even just multiple steps within the same view. This becomes pertinent doing heavy Ajax in a view. You generally want to have at least in the JSF world it makes it easier to have your model there available when you are doing an Ajax request to update the page instead of having to reload everything from the database again or using session scopes. That is really the core proposition of Web Flow is managing state for you, the state of your object model, in a way that is much more controlled or finer-grained than just stuffing things in session scope and having to manually clean them up. It allows you to do directed navigation through your site; it has an XML based flow definition language where you transition between view states. It is somewhat like a more advanced version of what you have in the JSF navigation rules. It allows you to transition between states, but the thing that sets it apart is that you can actually execute your business logic during and around those transitions -- there are various execution points, different kinds of events that you can latch onto to execute your business logic. You have different events for, say, preloading a model data for a particular view or for cleaning up data. Most of the cleanup, it does for you automatically when things go out of scope so that is really a primary concern.
Kito Before we go to Spring Faces let's just talk about this a little bit more. So conceptually Spring Web Flow kind of does what some other frameworks do to some degree, so in some ways it is similar to Shale Dialogues which never really took off.
Jeremy Right.
Kito In terms of the scope it is similar to something like MyFaces Orchestra, which has just a conversation scope but no kind of flow definition or anything, right?
Jeremy Right.
Kito Also, similar in some ways to some of the features that Seam has with the conversation scope and its page flow like language, right?
Jeremy Right, definitely. Its more rigid -- a little bit -- than Seam's conversations. With Seam you can kind of ad hoc start and begin conversations when you want. It is a little more directed than it is in Seam, but other than that the functionality is very comparable to what is there in Seam. The other thing I always like to mention -- my favorite part of it -- is that the flow definitions are completely dynamic and refreshable, so you can make the changes and be actually prototyping live while your server is running.
Kito Nice.
Jeremy Refresh the browser and everything just works, with the exception of maybe if you had some states stored. That would get recreated fresh, but the actual business execution and your transitions between states, you can do all of that live and just hit refresh and its there.
Kito That's a good thing. That is one of the things I was glad to see they added to Mojarra, just for basic JSF configuration. Finally it will reload those things. But it is one of those things you think that every application should always be able to reload.
Jeremy Yes.
Kito So that is a really nice feature. Another thing, you said that you can execute business logic inside of the flow definitions, right? So that means that in terms of JSF you get around some issues, like in JSF 1.2 where there is no hook to execute logic before a page is displayed and stuff like that, right?
Jeremy Exactly, and that is one of the key things that really enables it to simplify JSF, because you have those hooks already, and it is nice because it is using EL its using the extended version that does method execution, but it is using unified EL. It is the same expression language that you are used to if you have been doing JSF for a while. You can use it all right there in the flow definition.
Kito What would you say to people that dont like writing lots of XML for navigation? Can they write it in another language?
Jeremy You will see in Spring 3.0, we are going to introduce Java based flows.
Kito Interesting.
Jeremy I should say in Spring Web Flow 3.0, which will follow Spring 3.0 pretty closely. There are those who just no matter the benefits, the dynamic parts of it and things like that some who just dont want to touch the XML. This is kind of an answer for them, you will be able to writeinstead of an XML flow definition you can write it as a Java class, so you will have a class that actually extends some base flow class. Basically the local variables in your flow class become the flow scope to variables for your flow definition. Then you do view states with kind of the inner class style, similar to the things that you do in Spring with templates with implementing interfaces right there in line. It will look similar to that. That is the Java option. There has also been for a while a Groovy option. I think it is part of Grails or a plug-in to Grails. There is a Groovy flow builder that has been around since the Web Flow 1.0 days and I think they recently have updated it to work with Web Flow 2. That is the other option if you refuse to touch the XML. There are other options out there. I have to say, really when I came on and started working with Keith that was one of our primary goals, to kind of cut down on the XML you have to write. It is really pretty minimal now. Most of the important things in the flow are done in expressions.
Kito Okay, and if I was using Spring IDE, do I get a cute little flow editor?
Jeremy Yes, you do.
Kito Cool.
Jeremy It is pretty cool. I think the nicest part of it is the visual representation that you get -- even if you are just writing it in XML -- it will map out the graph of your site based on the view states. But I personally still prefer I think it is actually faster to just write the XML. There is actually full code completion support in there for developing with the XML, with the exception of the expressions. Actually I think we have some ideas for maybe incorporating that too.
Kito Cool. I think they are doing some of that in the WTP project.
Jeremy I think they are trying. There is actually a new Facelets project that is incubating. I dont know how much progress they have made. I am interested to watch that. It is like they are still just figuring out the Facelets 1.0 problem. I hope they are just going to skip that and go to JSF 2.
Kito They are. I spoke to someone at a conference last year and they said I think we will just wait for JSF 2. It is probably a good thing.
Jeremy Hopefully support will come there, because we definitely encourage the use of Facelets even with JSF 1 of course. Across the board that is the first thing we will recommend to anybody that is using it.
Kito Yes and that is definitely the consensus. So, moving along, we talked about what Spring Web Flow is. With Spring Web Flow, you can use just with the normal Spring stack or Spring MVC or use it even without Spring MVC, couldnt you?
Jeremy You can. It doesnt have all the adaptors that 1.0 had. You would have to actually write an adaptor specific to the technology you are using. For example we had Struts 1 support in 1.0 but for the most part we found that wasnt getting used as much so we decided not to keep up with that, at the moment. But you can certainly write an adaptor to make it work with other technologies. I think Struts 2 -- at one point they had in their community a plug-in for it.
Kito Oh okay.
Jeremy I am not sure what the status of that is.
Kito Okay, so right now the two main technologies are Spring MVC and JSF?
Jeremy Right.
Kito So that leads us to Spring Faces.
Jeremy Basically Spring Faces is our integration between JSF and Web Flow, but it is really approaching it from the perspective that you can do almost everything for your JSF application in Web Flow. You generally end up replacing managed beans almost completely with your flow definitions..
Kito Managed beans or navigation?
Jeremy Managed beans and navigation.
Kito Interesting.
Jeremy If you are doing managed beans in the traditional way, they are just glue code thats invoking your service layer.
Kito Oh, I see.
Jeremy We are essentially able to get rid of that, and instead invoke Spring services with the EL and get pretty far with that. You can plug in Java helpers where you need to, but for the most part that is the way we advocate doing it. People have been pretty successful with that. The key thing here is that we actually execute the JSF lifecycle under the control of Web Flow. It is a bit different; we are not going through theFacesServlet. Because Web Flow is designed to handle requests, they are dispatched to it from the Spring dispatcher servlet. We wanted to keep that architecture. Essentially we have this layer in Spring Faces that actually executes the JSF lifecycle when you enter a view state, as we call it. So when the flow is refreshed or when you create a new flow, that is the point we actually start the execution of the lifecycle. The nice benefit that we got from that is one of the patterns that is enabled by default with Spring Web Flow is always redirect on pause, as we call it, so basically the post redirect get pattern. We have this state machine, so every time you advance through the state machine, you are taking a snapshot of the model state, and at that point we redirect before we actually render the view. So even when you are doing posts all the time, the actual view that gets rendered is rendered as the result of a get.

The reason was we needed to drive the JSF lifecycle inside there to really make that work well, so that we can actually execute phases 1 through 5 of the lifecycle: restore view through invoke application. We execute on the post request, and then we do the redirect, and then we execute the render phase at that point after the redirect, when Web Flow essentially asks the view to be rendered. That is really the big architectural choice we made there that we found had a lot of benefits over the way it was done. In Web Flow 1, it was with a phase listener approach that didnt mesh as well with what Web Flow wanted to do. We are pretty careful to still adhere to the proper semantics of the lifecycle and make sure that we execute that to the letter of the spec, as it would be just under the normal FacesServlet.

Then we provide some other interesting integration points. For example Faces messages are actually a faade over this independent message abstraction that we have in Spring Web Flow that is actually getting moved into part of Spring 3. It is just this nice API that you can use for messages that has no dependence at all on any web tier constructs, so you can potentially be using this to add messages down in your business layer without worrying about depending on web-specific classes. Whats nice about that is we can do one of the things I always thought was pretty sorely missing from JSF is the ability to effectively do model level validation. It does field level validation pretty well but as soon as you start getting into more complex business rules where you have interdependent fields, it starts to break down. Most of the time, you end up doing that in an action listener or something like that.

Kito Right, and then you are kind of defeating the whole purpose.
Jeremy Exactly, so we still do the model validation on the other side of the update model values, because I think it is just easier to work with your model when you are running those complex rules, but we do it in such a way that you can actually have the validation down in your model and be able to add messages that then get propagated back up if there are validation failures.
Kito This brings me to a question. I just did a podcast with Emmanuel Bernard about the bean validation JSR and the integration with JSF 2. Is Spring 3 going to be doing any of the bean validation JSR stuff?
Jeremy Actually they are planned in Spring 3 core, to support bean validation in there.
Kito Excellent.
Jeremy So you will have it available both in just plain Spring MVC, but also it will plug right in to Web Flow as well, and by way of that, JSF as well. We actually have some ideas along those lines to actually interspect the validation metadata, and perhaps generate proper client side validation from that. One of the things we provide with Spring Faces, we do have a very small set of components that we provide, that basically wrap Spring JavaScript, so you can apply Dojo widgets to your JSF controls.
Kito Just to clarify, Spring JavaScript is another project, right?
Jeremy Right, so Spring JavaScript is a pretty thin layer to make it easier to use JavaScript in a typical Java enterprise environment. Particularly we build on Dojo. The Spring Faces components are essentially just rendering out the proper Spring JavaScript decorations so that you can get some nice little client side validation on your JSF components for simple things that you dont have to round trip to the server. We have thought about potentially being able to actually generate the proper components without even having to add those decorators to your JSF template.
Kito That would be nice.
Jeremy We are definitely going to investigate that. I can see it working pretty well. I have actually had conversations with the Dojo guys where they are actually thinking about revamping their widget API to be able to -- if you have, say, a form -- you can actually specify JSON schema that would then apply validation rules for the whole form.
Kito Fascinating.
Jeremy They are thinking about doing some stuff along those lines. If they do that we would definitely take advantage of it. I think even if they dont do it themselves, that is probably the route we will end up going, taking the bean validation metadata and translating it to JSON schema and then somehow consume that on the client side, and then actually dynamically apply the validators. Most of what Spring Faces is, is small components. They are similar to what you have in RichFaces, so Ajax command buttons and Ajax links. Of course our command link actually degrades if you dont have JavaScript on.
Kito That is one of the main features of Spring JavaScript -- that it actually degrades.
Jeremy So that is the style that we actually encourage, using JavaScript on such a way that you are just applying these decorations to already functioning HTML, a sound base structure. You kind of get that for free by the fact that it builds on that. The thing that we show frequently is that you can actually controlin your Web Flow definition, you can mark a view state as being a pop-up view. It will automatically get rendered in a Dojo modal dialog. In the flow definition you can actually specify the parts of the JSF component that you want rendered so you can do partial rendering, but actually controlled from there in your controller level, instead of being controlled by some special attribute on the client side.

I always thought it was a little weird that you were sometimes specifying the parts of the tree that you want rendered from the client side. It always seemed like a server side concern. You would potentially want to render different things depending on different parts of the tree, depending on what happened on the server. It has not always been as easy to do with some of the JSF libraries. We move that part to the server to the flow definitions, so you can have for exampleyou mark a view state as a pop-up and say render just the main form and not all the decoration, header, and things like that. You render that and the pop-up is there if you have JavaScript enabled, but then if JavaScript is disabled, all of that stuff gets ignored in the flow definition, and it will just render out the whole view when you click on that particular link. Essentially everything on both the client side and the server side just work the same whether JavaScript is enabled or not. That is one of the nice benefits that you get from building on top of that foundation.

Kito Do you allow people to still do it on the client if they want to, if they are more familiar with doing it that way?
Jeremy We dont with our components. I actually had that in the first version and we took it out before it went final. You are certainly free to use RichFaces or ICEfaces well of course with ICEfaces you dont have to specify the IDs at all.
Kito Right, which is nice.
Jeremy It is pretty nice. We have actually worked with the ICEfaces team to make sure that Web Flow plays well with it, because there were some different requirements there because of their model where they have their own separate servlet for doing the push and everything. They essentially made sure that it all works well behind there. They kind of wrote their own adaptor for Web Flow to make sure that worked. Then the other one we test pretty thoroughly most of the time is RichFaces, because that is the more popular one that we have seen in the community. You can certainly use RichFaces with it. RichFaces has the most interesting integration because you can also use those render attributes in the flow definition. Those will actually work with RichFaces because their model is so similar to ours. In most cases you can specify the IDs in the flow definition. The difference is I think you end up having to specify the fully qualified ID, but other than that I think it works in most cases.
Kito Do you find that a lot of the people you know that are using Spring Web Flow, do they tend to only use JSF or do they mix JSF with Spring MVC?
Jeremy Right now they tend to only use JSF if they are using JSF. I think it is just because the skill sets are different enough; the people doing JSF tend to not be heavy JavaScript/CSS type of people. When you are doing just plain JSPs with Spring MVC you tend to be more focused on writing JavaScript and CSS and more traditional web content, which JSF tries to abstract away from using as much as possible.
Kito Right.
Jeremy So you can mix and match the two. You cant do it in the same flow but you can have separate flows that use both, or you can also have part of your application be stateless MVC and then part be JSF with Web Flow. The one thing that we are interested in exploring further is using JSF in a stateless way. I think that is certainly going to be more possible, or we can get closer to it with JSF 2.
Kito Yeah, definitely.
Jeremy We actually have a stateless JSF view that can be rendered from Spring MVC, its just not a whole lot of use, because rendering the components and then throwing away the component tree, you lose a lot of what JSF expects to be there so you cant do post backs. You would have to treat it as a truly stateless page and do traditional links if you want it to go anywhere from there. If you just wanted to use the JSF components to just render out your page, and not have a post back for that particular page, you can do it.
Kito Okay.
Jeremy We do have that option available, where we basically set the UI viewer to transient and everything and let it just go away.
Kito Okay, so Spring 3.0 is coming out in a few months, and Spring Web Flow 3.0, right? Tell us a little bit about it.
Jeremy The main theme, at least on the web side of Spring 3.0 and Spring MVC, is REST support. We are essentially taking the annotated controller model that we introduced in Spring 2.5 and introducing true RESTful URLs, content negotiation, support for the four verbs of HTTP -- get, post, put, and delete -- the typical things you see talked about when you talk about real REST. More than just pretty URLs. Being able to render different representations of the same resource but from a single controller method. That is really the core thing that we are focused on in Spring MVC. As for the core framework there is some pretty interesting things going on there. First of all, Java 5 is going to be a base requirement. So the entire API has actually been gone through heavily and made to use generics where it makes sense, using all of the typical things you would expect from a library that has Java 5 as its base. So as you go through and look at the general core framework, there are some pretty interesting benefits to that. It makes certain things like the JDBC template and things like that simpler. There was already a simple JDBC template which was a Java 5 version in Spring 2.5. So now the basic JDBC template looks closer to that. That is just one example. Basically throughout the entire core framework you will see those changes throughout. We are introducing the ability to use expression language in your Spring bean definitions
Kito Oh nice.
Jeremy So you can actually set properties on beans .... and it is actually our own EL implementation, called Spring EL. It is not a direct implementation of the unified EL API-wise. It is, in terms of syntax but then it has some features that go further. My understanding is that there are plans to make sure that you can adapt it to use the unified EL API. What that really enables is some nice things that you couldnt do before in Spring configuration, for example the way with JSF managed beans, how you can have a managed bean that you injected with some other property that is dynamically resolved at the time that the bean is created. You can use those expressions in the JSF managed bean.
Kito Right.
Jeremy Now you can do that same sort of thing in Spring configuration. Then we expose some kind of well known variables like you see in JSF but things like system properties, so it will be easier to get at those things. We do plan on supporting JSF 2 in the core framework. I believe there was talk of actually supporting the new JSF view scope as a scope that you can define a Spring bean to be.
Kito Okay.
Jeremy We are generally going to make sure that the basic support for JSF in Spring continues, aside from whats in Spring Faces. I have talked about this before, where I call the Web Flow approach the Spring centric approach and the other approach where you are just using those adaptor classes in Spring as more of the JSF centric approach. You will still be able to do both with JSF 2.
Kito Where does Grails fit into the whole picture now that you guys own Grails, essentially?
Jeremy It is really interesting, what I like about it is even before they became part of SpringSource, there has always been this continual feedback loop between Spring MVC and Grails. It is all Spring MVC underneath; all of the controller stuff in Grails is actually implemented on top of Spring MVC. There have been some things in Grails that definitely inspired what we are doing in Spring MVC; it even inspired some of the things in 2.5 but also the REST support in 3.0. Now we are going to have some things in Spring MVC that they can build on top of now, and maybe make their implementation simpler. It is this kind of continuous loop. It is a big part of our stack now. For those who are willing to go down the dynamic language route and use Groovy and have the right use cases for it, then it is certainly a viable option. We have already got support customers for it. There are some pretty big customers who are adopting it, you would probably be surprised.
Kito Nice.
Jeremy Its great to see. I mentioned before they have the flow builder so there is going to be that kind of continuous feedback, where we can make sure they upgrade to Spring Web Flow 3 sooner than they did last time. We just see it as part of the general ecosystem for Spring.
Kito So you are involved in the JSF expert group, right? And I know you have been very busy lately but I know you have seen some of the emails that have come along. If you could pick, what would be your favorite feature in JSF 2?
Jeremy Mine is definitely the template based components. We have already prototyped this feature for Spring Faces 3.0, where we provide this tag that is basically just a generic Spring JavaScript element decoration, so that you can pull in essentially any Dojo widget that you want to and very quickly build a template based component from that. What allows this to happen is -- in the old Spring Faces 2.0 components we just have a limited sub-set of the widgets that are available in Dojo, because we actually generate the proper Spring JavaScript element decoration for that particular widget, and we map that to whatever one of the tags that you are using. It is kind of cumbersome with the JSF 1 style to develop those components, so it is somewhat limited which ones we have decided to include. The core construct in Spring JavaScript is what we call an element decoration, and it is just the same JavaScript object that you use over and over or the same API that you use over and over -- and you can use it to pull any Dojo widget and apply it as a decoration to a basic DOM node.

The new tag that we are going to be introducing specifically with an eye towards using it in the template based components, is an equivalent of that basic JavaScript statement, the element decoration. So you can specify any Dojo widget that you want to pull in and build a component out of just using that basic tag, and it should apply it to your basic DOM structure that you have specified in the template for the component. That is definitely one of the coolest things I am looking forward to playing with.

I think beyond that my other one would be the improvements to state saving. That's a big one for us. I think seeing that, the state ended up being a good bit smaller, is definitely beneficial. In Spring Web Flow 2 we actually store the JSF component state; we actually manage it with Spring Web Flow's state. It ends up using potentially less than the base implementations because they do the same thing; they snapshot the component state so that when you use the back button everything is still there. The nice thing about storing it with your Web Flow is that you know when that stuff has gone out of scope, so when those pages in your flow have gone out of scope, it makes sense for us to throw out the component state as well. We have already taken some measures to reduce the amount of state being stored by doing that, but this will reduce it even further so I am definitely looking forward to seeing that.

Kito Alright Jeremy, I think that is about it in terms of the questions I had. Is there anything else you want to add?
Jeremy No, I don't think so. I think the main thing I would say is, I encourage anyone who hasn't tried it out yet to take a look at Spring Faces, especially if you are struggling a bit with JSF development. I really think it does simplify things a good bit. I encourage everyone to get involved. I and the rest of the team monitor our forums constantly and interact with the community that way. That is our general way of getting feedback and improving the project. I definitely encourage everyone to give it a try.
Kito Okay. I guess you are flying back tonight, right?
Jeremy Yeah actually taking the red eye.
Kito The joy of the red eye. I am going to hang out in Vegas for another day or two with a couple of friends. It has been a good conference and I appreciate you taking some time to chat with us.
Jeremy Absolutely, thanks for having me.
Announcer That's it for this edition of the JSFCentral podcast. The music for this podcast was composed and performed by Kito Mann.


RSS feed(all feeds)

The Editor's Desk
Podcasts
Inside Facelets
In the Trenches

Site version 1.83  Report web site problems

Copyright (C) 2003-2015 Virtua, Inc. All Rights Reserved. Java, JavaServer Faces, and all Java-based marks are trademarks or registered trademarks of Oracle Corporation. in the United States and other countries. Virtua, Inc. is independent of Oracle Corporation. All other trademarks are the sole property of their respective owners.