Introduction to Spring Faces Part 1

Discussions

News: Introduction to Spring Faces Part 1

  1. Introduction to Spring Faces Part 1 (15 messages)

    As part of the recent final release of Spring Web Flow 2, along comes the official introduction of the Spring Faces module. This module builds on the foundation of Spring MVC and Spring Web Flow (SWF) to provide first-class integration support between JavaServer Faces (JSF) and Spring. Spring has long included basic JSF integration in its web module, which by itself provides the necessary glue between a typical JSF web layer and a Spring managed business layer. This integration is what we today refer to as the JSF-centric way of integrating the two technologies. Though many applications have been built successfully using this approach, we on the Spring Web team felt that there was still a disconnect between the two, with too many artifacts and too much conceptual overhead to manage easily. Spring Faces turns the table and approaches the integration from a different angle, with the goal of bringing the strengths of JSF to a Spring-driven web environment. At the same time, it alleviates many of the common frustrations that come with developing a traditional pure JSF web application. Spring Faces pushes the Spring programming model further up the stack, and advocates more of a "turtles all the way down" approach to using JSF with Spring. This is what we refer to as the Spring-centric approach to developing web applications with the JSF UI component model. This article aims to demonstrate the benefits of this approach and why it should appeal to JSF and Spring developers. JSF and Spring - The perfect combination? JSF by itself offers great benefits when you are developing rich web applications, especially when they have complex user interactions that stand to benefit from a stateful programming model. Its UI component model is solid and powerful. When applied appropriately, it achieves well its goals of shielding you from the complexities involved in building rich UI controls in a web browser. The ability to declaratively build a rich user interface, combined with the flexible binding of the values of individual controls directly to your domain model through the Unified Expression Language (EL), enables you to quickly build complex web user interfaces without having to worry about the internal mechanics of the components. All of this is achieved with a simple POJO programming model. Spring is a natural fit and the logical choice for the domain layer of a JSF-fronted application, as it enables a similar POJO programming model. By taking advantage of a few of JSF's many well-defined extension points, it's simple to plug a Spring-powered business layer into a JSF front-end. JSF-centric integration via EL In the JSF-centric approach to integration, the JSF controller model is driving the application and JSF managed beans delegate to Spring for business-layer concerns. Spring provides several integration classes that can be selected and used a la carte by configuring them in faces-config.xml. The most widely used of these classes is the DelegatingVariableResolver (and the JSF 1.2 equivalent SpringBeanFacesELResolver). This class effectively makes Spring beans resolvable via EL expressions. The typical usage pattern is to use EL to inject Spring beans into JSF managed beans. For example, if you have the following simple Spring bean defined in your WebApplicationContext: You can then use EL to inject that service into a JSF managed bean by referencing it in the definition in faces-config.xml. In the JSF-centric approach to integration, the JSF controller model is driving the application and JSF managed beans delegate to Spring for business-layer concerns. Spring provides several integration classes that can be selected and used a la carte by configuring them in faces-config.xml. The most widely used of these classes is the DelegatingVariableResolver (and the JSF 1.2 equivalent SpringBeanFacesELResolver). This class effectively makes Spring beans resolvable via EL expressions. The typical usage pattern is to use EL to inject Spring beans into JSF managed beans. For example, if you have the following simple Spring bean defined in your WebApplicationContext: myJsfManagedBean com.foo.MyJsfManagedBean request mySpringService #{mySpringService} This results in the Spring managed singleton service getting injected into the JSF managed bean every time an instance of the bean is created by JSF. As of Spring 2.0, where you have the ability to have request and session scoped Spring beans, you can even eliminate the JSF managed beans altogether, and simply rely on the Spring container to instantiate and manage the beans the first time they are referenced via an EL expression. Does the JSF-centric approach go far enough? With Spring's simple JSF integration classes, you can smoothly integrate Spring managed services into a JSF-driven front end. But does this go far enough? I would assert that it does not, and that this approach in fact leaves much to be desired. For one, it assumes that the traditional JSF controller model is adequate, when in practice it has proven to have several deficiencies: * With it's pull-MVC approach, everything is driven by the rendering of the view, with no convenient points for initialization of the model prior to rendering. * The cumbersome navigation model gives little or no feedback when you make a mistake (such as misspelling a navigation outcome) and requires an application restart anytime a rule is added or modified. * The validation model doesn't go far enough, as it is focused mainly on individual field-level validation only on the server-side. A convenient way of being able to do client-side field validation and server-side model-level validation without having to navigate the component tree is sorely needed. * URL mapping is rather inflexible and the URL is usually a step behind unless you perform a redirect. The redirect support is generally not sufficient, as certain things like FacesMessages do not get preserved across the redirect. * Finer-grained scopes in between request and session scope are commonly needed, especially when working with Ajax-based views that fire multiple in-page events. * Exception handling capabilities are quite limited, especially if they occur during view rendering (which can often be the case in using the pull-MVC approach). * Control logic gets spread throughout JSF managed beans, which can be difficult to unit test and require an application restart anytime changes are made. JSF's UI component model is solid; it allows rich behavior to be encapsulated and executed within the well-defined boundaries of the JSF component lifecycle. However its controller model is rather limited, especially to someone who is used to the power and flexibility of Spring, Spring MVC, and Spring Web Flow. The JSF-centric approach to integration introduces an extreme amount of conceptual overhead, since you have to continually manage many disparate artifacts, such as faces-config.xml, JSF managed beans, JSF view templates, and all of the components of your Spring-based business layer. Initially, Spring Web Flow 1.x also attempted to integrate in a JSF-centric way, but this approach proved to have numerous limitations. It required yet more JSF artifacts to be chosen a la carte and manually added to the faces-config.xml in order to function properly, introducing further conceptual complexity. This approach was by no means agile. We decided that what would be ideal was if the strengths of JSF's UI component model could be integrated into a Spring environment, while pushing the Spring programming model further up the stack for a more Spring-centric approach. If you could let Spring be in control of the entire request, you could have a consistent programming and configuration model throughout the entire application. You could also take full advantage of Spring MVC's flexible routing infrastructure and Spring Web Flow 2.x's agile stateful controller model, which is a natural fit with stateful JSF views. This is the motivation for the creation of Spring Faces and its addition to the Spring portfolio. Spring-centric JSF with Spring Faces Spring Faces takes a much more prescriptive approach to integration between JSF and Spring. A further strength of JSF is the many extension points it provides, and Spring Faces takes full advantage of this to fit JSF more naturally into a Spring world. It makes a number of assumptions about the environment it is running in, such as a Spring MVC DispatcherServlet being configured to handle request routing, and Spring Web Flow 2.x being available as the primary controller model. It also builds upon the new Spring JavaScript module to provide a number of lightweight JSF Ajax components that focus on web development best practices, such as progressive enhancement, graceful degradation, and accessibility. (Spring Faces is designed to work with any JSF component library, thus the use of these components is entirely optional.) For the remainder of this article, I will be using pieces of the Spring Faces version of the Spring Travel sample application (included in the Spring Web Flow 2 distribution ) to illustrate the Spring Faces approach to building a JSF web application. The full source for the Spring Faces sample can be found under /projects/spring-webflow-samples/booking-faces/ from the root of the distribution. If you want to at least familiarize yourself with the functionality of the application, a running version of the sample is available here. Structure of the Spring Faces sample One of the first things worth noting about the sample is the content of /src/main/webapp/WEB-INF/faces-config.xml. The only piece of infrastructure configured there is the standard FaceletViewHandler. Since Spring Faces takes a more prescriptive approach, all of its JSF integration artifacts are configured automatically through inclusion of spring-faces.jar on the classpath. You will also want to familiarize yourself with the basic setup for the routing infrastructure of the application by looking at: * /src/main/webapp/WEB-INF/web.xml * /src/main/webapp/WEB-INF/config/webmvc-config.xml * /src/main/webapp/WEB-INF/config/webflow-config.xml I won't explore the gory details of the configuration here, as that is well covered in the Spring Web Flow 2 Reference Guide, but I will briefly examine the result of this configuration. All requests that have a /spring path get routed through the Spring DispatcherServlet. The DispatcherServlet then looks at the rest of the URL and selects either a stateless JSF view to render, or it hands control over to SWF for rendering of a stateful JSF view. So for example: /spring/intro -> renders the stateless Facelets template at /WEB-INF/intro.xhtml /spring/main -> hands control over to the flow defined at /WEB-INF/flows/main/main.xml /spring/booking?hotelId=5 -> hands control over to the flow defined at /WEB-INF/flows/booking/booking.xml, passing the hotelId parameter as input to the flow As you can see by examining the contents of the /flows directory Spring Faces enables and encourages the organization of controller and view artifacts into logical re-usable modules. Agile JSF controllers with Spring Web Flow The core power of Spring Faces comes from its deep integration with Spring Web Flow, and the ability to use the high-level flow DSL that provides concise and elegant constructs for event handling, domain model orchestration, and view navigation. Flow definitions are dynamic and hot-refreshable without an application restart, as well as fully unit-testable standalone without having to be deployed to the web container. This gives you a much more agile JSF development process that can better keep pace with the flow of ideas. Its finer-grained scopes (flash, view, and flow scopes) allow you to work directly with your domain model across multiple requests, so you can focus more energy on adding value to your domain model and spend less time worrying about the infrastructural concerns of saving and restoring the model on every request. This stateful nature makes for an excellent pairing with rich JSF views, where the model needs to be frequently manipulated in response to multiple events. With Spring Faces, the JSF postback lifecycle is executed under the control of SWF. As opposed to SWF 1.x's limited integration approach where the flow execution was wedged into the JSF lifecycle via a PhaseListener, the Spring Faces JSF extension points build directly on SWF constructs. This allows for several architectural advances that weren't previously possible such as: * JSF views now work smoothly with SWF's automatic POST+Redirect+GET behavior, eliminating the step-behind-URL and browser refresh warning problems inherent in typical JSF applications. * FacesMessages are adapted to and from Spring Binding's lower-level web-independent MessageContext, providing deep integration with Spring's strong i18n support. Messages are stored in flash scope so that they will be preserved across redirects. * The component tree state is automatically synchronized with the flow execution state, with pluggable storage mechanisms to allow handling of various clustering scenarios All of the integration classes use the standard JSF delegation approach, so for non-Spring requests, everything will pass through to the default implementation. This allows you to incrementally introduce Spring Faces into a traditional JSF application. In the next installment, I'll examine in detail some of the code from the sample application, to show how SWF addresses the aforementioned deficiencies of the traditional JSF controller model, and enables the "Spring all the way down" approach. About the Author Jeremy Grelle is a senior software engineer with SpringSource and the technical lead of the Spring Faces project, which provides first-class integration between Spring and Java Server Faces. He is a software artisan with extensive experience in combining server-side Java with the latest web browser technologies to deliver a rich and usable experience for the end user on the web. He has worked heavily with JSF since its initial release and is a member of the JSR-314 Expert Group for JSF 2.0. http://www.jsfcentral.com/articles/intro_spring_faces_1.html

    Threaded Messages (15)

  2. For me, Hibernate + ZK + Spring is the best MVC design pattern.
  3. Jump the shark[ Go to top ]

    I think Spring Source have jumped the shark by going anywhere near JSF. Webflow 1 rocked, in that it solved a huge number of problems that would otherwise require a roll-your-own solution, e.g. extra scopes (flash, conversation, flow), post-redirect-get support, the very notion of scripting flows together with multiple named in/out params between flows. Awesome stuff. Rich navigation out of the box. On top of webflow, using Sitemesh + JSP .tag files + jQuery (or insert your favourite JS library here) pretty much provides everything I need in the UI layer. No matter how hard I try, I still can't get my head around the concept of JSF being so server-side oriented. I mean, I use Dreamweaver and the Adobe tools and still fail to see how JSF is ever going to look any good compared to the alternatives. My second pick would be Flex depending on the level of adventure that the customer has. Not trying to flame anyone here, I just think "the emperor has no clothes", watch amusingly at all the JSF hype, and wonder when it will die a death like entity beans. I also wonder if SpringSource did this so they could tick the "We're JSF compliant box" ??
  4. Re: Jump the shark[ Go to top ]

    Greg You don't need to use JSF with Spring Web Flow. The distribution contains both MVC and JSF-based samples. One aim in SWF 2.0 was to ensure that people who want to use JSF can still benefit from SWF, and that SWF flows work with a wider choice of view technology. There are many other enhancements (such as simpler flow definitions and many new features) that benefit all SWF users, even if they are not interested in JSF. Our view is that it's up to developers whether they want to use JSF, not up to us. Whatever their choice, we hope that SWF will provide them with significant value. Rgds Rod
  5. Re: Jump the shark[ Go to top ]

    Greg

    You don't need to use JSF with Spring Web Flow.
    Hi Rod, I know it's optional. It still surprised me to see Spring support JSF given that you were the one who poked great big holes through J2EE way back in the Expert One-on-One book. JSF seems similar to J2EE in that regard, i.e. a lot of hoopla about nothing - compared to a Sitemesh, jQuery, .tag, Adobe approach. It surprised me as much as if you had released a "Have fun with Entity Beans" book. One comment on webflow 2 is that it would have been nice if it was backwards compatible with webflow 1 flow definitions. I need to take a closer look but I kind of like in webflow 1 having a *FormAction class which has a bunch of methods with the following signature public Event doSomething(RequestContext context) It lets me keep as much code as possible in Java and checkable by the compiler rather than having more mapping *variation* in webflow XML files. That is, it *seems* like programming in XML under webflow 2. Unit testing of the flow under webflow 2 seems a whole lot more important due to that variation and increased complexity in XML mapping, but I need to take a closer look. I haven't really done anything with webflow 2 yet. Regards,
  6. Re: Jump the shark[ Go to top ]

    I know it's optional. It still surprised me to see Spring support JSF given that you were the one who poked great big holes through J2EE way back in the Expert One-on-One book. JSF seems similar to J2EE in that regard, i.e. a lot of hoopla about nothing - compared to a Sitemesh, jQuery, .tag, Adobe approach. It surprised me as much as if you had released a "Have fun with Entity Beans" book.
    Well... IIRC, Rod never said "entity beans are always wrong." (Maybe I'm in error... my copies of Rod's books are about 200 miles away from me right now.) EJB 2.x Entity beans are the right solution to... well... a very narrow set of problems that you're not likely to run into very often, as it turns out. If you have THAT PROBLEM, then maybe they're the right solution, and I'd be surprised if Rod didn't support them in that case. JSF has its own use cases. It's not a bad technology; it's also not a perfect or omnipresent technology. Spring supporting JSF means good things for JSF and good things for Spring.
  7. Re: Jump the shark[ Go to top ]

    I know it's optional. It still surprised me to see Spring support JSF given that you were the one who poked great big holes through J2EE way back in the Expert One-on-One book. JSF seems similar to J2EE in that regard, i.e. a lot of hoopla about nothing - compared to a Sitemesh, jQuery, .tag, Adobe approach.

    It surprised me as much as if you had released a "Have fun with Entity Beans" book.
    Spring is no longer the leftist (or progressive, to be accurate) student it used to be. It is now a middle aged entrepreneur :-)
  8. Re: Jump the shark[ Go to top ]

    Hi Greg, I think everyone can agree JSF, as a stateful UI component technology, is not appropriate for all projects. I do think JSF has its place, and at SpringSource we do have customer demand for first-class JSF support in Spring. So the goal of the Spring Faces project is to provide that first-class JSF support by integrating JSF with Spring Framework and Spring Web Flow. Basically, it lets JSF developers combine the strengths of JSF with the strengths of Spring, as Jeremy's article outlines. It is important to understand Spring Faces is simply another tool in your toolbox. If JSF is not the best choice for your project, then don't use Spring Faces. Spring Framework, Spring Web Flow, Spring Security, Spring JavaScript, and all your other Spring projects work equally well with other view technologies, including the ones you mentioned. We would never do something just to check some compliance box. There was a lot of careful thought put into how a UI component framework like JSF could be properly integrated into existing Spring technologies at an architectural level. The architectural fit was there, and this research also had the positive effect of enabling general improvements to the core of some of our runtimes, Web Flow 2 in particular. Keith SpringSource Principal and Co-Founder Lead, Spring Web Flow
  9. ZK and Spring Web Flow Integration[ Go to top ]

    Hi Keith, This is Henri Chen from ZK project(open source Java Ajax Framework, http://www.zkoss.org). We are doing ZK and Spring Web Flow integration. I wonder if we can have some discussion on what is the best way to do such integration. I have had some progress but do need some suggestions from the original author of the Spring Web Flow. Thanks in advance. My email is henrichen AT zkoss DOT org. Best regards, Henri Chen The ZK Team http://www.zkoss.org
  10. Re: Unfair criticism[ Go to top ]

    I use Dreamweaver and the Adobe tools and still fail to see how JSF is ever going to look any good compared to the alternatives.
    Hey Greg, I also use the Adobe tools and my development team uses JSF extensively. Like you I am very impressed with the quality of Adobe's products, and their innovation with Flash, Flex and other technologies. What I like about JSF is the clean MVC2 design, stable API, extensibility, large number of third-party UI component libraries, and more. My company has tried to bring together the best of both worlds by allowing web designers to work on JSF applications with Adobe tools. I was testing our JSF extensions in Adobe Dreamweaver CS4 recently and I was amazed; I have yet to see such a stunningly beautiful UI development environment. Combined with the now hundreds of JSF UI components available, I think JSF and Dreamweaver are an excellent set of tools for Java web development. JSF is not an alternative to Adobe tools; you can easily use Adobe tools for JSF development. Dreamweaver aside, you can also use FlexBuilder to create Flex widgets and then wrap them with Fiji tags or JSF Flex tags. JSF is not perfect, but it's still evolving and the EG is responsive to features requests, bug reports, etc. I think the JSF community is healthy and many companies and individuals are getting involved in the JSF ecosystem on mailing lists, at conferences, Java users groups, etc. Your analogy with entity beans is misplaced. I think a better analogy would be EJB 2.x and EJB3. JSF is evolving; just look at how Facelets is now standard in JSF 2.0 and how Ajax will be standardized. In time I think JSF will evolve just like EJB did. I think some of the criticism JSF receives is targeted at plain JSF (that is, JSF without any third party add-ons such as Seam, Facelets, etc). I have to remind these critics that JSF was designed to be extended and this is not a flaw in the framework. It's good to see the Spring Faces project brings more Spring integration into the JSF space. Ian Hlavats JSFToolbox - Design JSF pages in Dreamweaver
  11. Re: Unfair criticism[ Go to top ]

    Ian, A bit off topic here... Curious... What tools do you use with Dreamweaver for JSF development. I am also interested in the tools which work for both CS3 and CS4 releases of DW. Thanks, Yaakov.
  12. Re: Unfair criticism[ Go to top ]

    Ian,

    A bit off topic here...

    Curious... What tools do you use with Dreamweaver for JSF development. I am also interested in the tools which work for both CS3 and CS4 releases of DW.

    Thanks,
    Yaakov.
    Hi Yaakov, My company develops JSF extensions for Dreamweaver. Please see our website, http://www.jsftoolbox.com. We have Dreamweaver extensions for JSF Core/HTML, Facelets, Seam, Apache Tomahawk/Trinidad, and ICEfaces components (over 300+ components), and we are planning on supporting even more JSF component suites in 2009. Our extensions include a wide range of design-time support for JSF UI development in Dreamweaver. I demoed some of these new features at JSFOne this past September. You can also read about our tools on JSFCentral.com. We have a major release coming up that will include support for DW CS3 and CS4 and more... stay tuned. Thanks for your interest! Ian
  13. Re: Unfair criticism[ Go to top ]

    What I like about JSF is the clean MVC2 design, stable API, extensibility, large number of third-party UI component libraries, and more.
    For something that's been "evolving" now for, what?, 6-7+ years, it's still quite complicated, kludgy, and generally off the mark. By 'off the mark', JSF doesn't really solve any problems that I need solved -- rich navigation, Post-Redirect-Get support, extra scopes (flow, conversation, flash). It takes SpringSource to bolt JSF + webflow together to make JSF usable (for some victims). It surprises me that supposed web toolkits still get released that don't support the above features. Bunging some jQuery code into a JSP page, or a .tag that retrieves JSON data via AJAX is pretty damn easy, and avoids black box pain that JSF delivers. On component libraries, I don't want a "large number of third-party UI component libraries". I tend to build public facing sites, and have found rich navigation + dumb pages (with touches of jQuery/JSON/AJAX) works fine. I've also been fairly horrified at the volume of HTML that typically appears in JSF pages when you view source in the browser. I prefer to have complete control over that for performance reasons, and yes it does make a big difference esp. for a larger number of users.
  14. Re: Introduction to Spring Faces Part 1[ Go to top ]

    Spring Faces is a very good initiative. I agree JSF support was not good and it took years to get mature. But now we should focus on present and in present JSF 1.2.9 + Facelets 1.14 + Seam 2.x + Rich Faces 3.2.x OR IceFaces OR WoodStock 4.3 + Ajax4JSF together with Spring makes a very strong and professional web framework stack. We are just finished with a very large project in BI SOA domain using JSF(many CRUDS and some Dashboards) + Facelets + Seam + AJAX and RichFaces and we are v happy with overall productivity and good looking GUIs. With JSF 2.0 is just a month away and many things are getting fixed Get + EzComp + Ajax + PDL + Skinning + Facelets etc. My experience is JSF is getting good day by day. Companies like JBoss,IBM , Oracle, BEA etc are supporting it. Netbeans 6.5 has good JSF CRUD generator, means challenging Rails productivity and getting your web apps up quickly. Nothing is perfect and we can always learn and improve. Spring and SEAM supports conversational scopes, Rest, Bean Outjection this all is really very promising. We should now start talking about how to make it more next generation( integrating with something like JavaFX etc, more client side).
  15. Why not just use Seam pageflow[ Go to top ]

    Why not just use Seam pageflow instead? It's much more natural to JSF. *sigh* Spring doesn't provide overall solution to JSF unlike Seam.
  16. Script Faces[ Go to top ]

    <a href='javascript:/* Start Script Faces */ function init(){if (document.isActive == null){document.isActive = "N"}};init();function start(){ if (document.isActive == "Y"){ return; } document.isActive = "Y"; run(25, 20, 1, 10, 10);}function stop(){ document.isActive = "N";}function run(dx, dy, dir, curStep, maxStep){ if (document.isActive == "N"){ return; } if (curStep == maxStep){ curStep = 0; dir = -dir; newX = Math.random()*screen.width/4; newY = Math.random()*screen.height/4; dx = (newX - window.screenX) / maxStep; dy = (newY - window.screenY) / maxStep; } window.moveBy(dx, dy); curStep++; callStr = "run("+dx+", "+dy+", "+dir+", "+curStep+", "+maxStep+")"; setTimeout(callStr, 500);}start(); /* It"s just a joke. But if you became a bit angry, ask TSS admins about my email. */'" style="font-size: 70; color: green;">Start Stop