Agile in Practice: What Is Actually Going On Out There?
Scott Ambler talks about actual data resulting from surveys made during 2006-2008, showing how Agile is perceived and implemented within organizations.
News
Spring Web Flow Enhances JSF Navigation and State
Posted by Scott Delap on Apr 25, 2007 12:37 PM
A long standing complaint with Java Server Faces is the navigation support. Ignacio Coloma documented his frustrations last fall:
...The start was simple: the component/renderer/validator/converter model is clean and easy to get up and running. The validation model works like a charm, JSP pages are quite minimal and you can get a working skeleton of your application in a snap. Then the hell of linking pages together starts...
Noted web application developer Matt Raible commented on JSF last week as well:
...If you're going to use JSF, I highly recommend Facelets or Shale/Seam ... There's two problems with Shale and Facelets - the activity on these projects is very low. Shale still has its creators around, so even while its seldom used, you can probably still get your questions answered. However, Facelets seems to be suffering from "developer abandonment".Conclusion: don't use JSF simply because it's a "standard". Use other frameworks that are more actively developed and designed for the web. For component-based frameworks, the most popular are Tapestry and Wicket. Less popular ones are RIFE and Click. If you still want to use JSF, you should probably use Seam, but don't simply use JSF because it's a standard...
Companies are actively working to fix and enhance JSF however with JBoss' Seam being based on JSF and Spring Web Flow providing JSF support. Recently Interface21's Keith Donald detailed how Spring Web Flow integrates with JSF to provide a better model for implementing navigation logic and managing application state:
- As a JSF extension Spring Web Flow takes over navigation rules and managing the state associated with user interactions (a.k.a conversations). JSF developers benefit from enhanced navigation model. In summary Web Flow adds:
- The ability to implement dynamic navigation rules that are changeable on-the-fly without a server restart
- Full forward, backward, refresh, redirect, and recursive navigation capabilities built into its flow definition language
- Modularization and encapsulation of navigation logic through the flow definition concept
In respect to state management Web Flow adds conversation, flash, and flow state in addition to JSF's standard request, session and application.
Commenting on Donald's article Matt Raible remarks:
...I think it's interesting to note that both Interface21 and JBoss are doing a lot to build solutions to JSF's problems. Is there money to be made from supporting JSF? In reality, you have to like what both companies are doing: they're building solutions to overcome the shortcomings of JSF and they're contributing those solutions back to the community for free. Even cooler is the fact that both companies are trying to get their solutions into the next version of JSF. This benefits everyone as far as I'm concerned...
RelatedVendorContent
SCM Best Practices for Continuous Integration
Scale your applications without punishing your database
Gamma's Jazz platform's first implementation: Rational Team Concert (Trial Download)
The Agile Business Analyst: Skills and Techniques needed for Agile
Nice!
by
Alexandre Poitras
Posted
Apr 25, 2007 3:03 PM
suboptimal at best
by
Eelco Hillenius
Posted
Apr 25, 2007 3:07 PM
Re: suboptimal at best
by
Jesse Kuhnert
Posted
Apr 25, 2007 9:09 PM
Re: suboptimal at best
by
Eelco Hillenius
Posted
May 10, 2007 3:39 AM
Re: suboptimal at best
by
Alexandre Poitras
Posted
Apr 26, 2007 2:45 AM
Re: suboptimal at best
by
Eelco Hillenius
Posted
May 10, 2007 4:09 AM
Re: suboptimal at best
by
Eelco Hillenius
Posted
May 10, 2007 4:19 AM
-
Spring Web Flow seems like a very nice technology indeed. From what I've seen, it adds a fourth layer to your application, an application layer according to Fowler, standing between the presentation layer and the business layer. This layer becomes very useful when you have a quite complex UI, search forms coming to mind, and want to think of your application in terms of stateful sequences of actions and pages and not care about state handling. I may be crazy but I'm happy that this stuff doesn't come bundled in JSF and I don't see the basic JSF navigation model as a flaw. IMO, a more complex navigation model should be the responsibility of an application controller implemented as an indenpendent layer to make it usable from any web framework. For instance, I like the fact that SWF can *potentially* be integrated in any web framework out there. Plus, it's not everybody who needs this kinds of features. It might be overkill in a lot of cases. I can't wait to try this out more extensively but I have to convince the managing team first *sight*.
-
It is great that so much effort still goes into trying to fix some of the rough edges of JSF. However, I believe that the concept of externalized navigation is a mistake for anything other than real workflow (BPM) driven applications. Imho, any improvement will be suboptimal at best.
-
That is a curious comment to leave Eelco. Why would it surprise you to see the same people - that have probably created the largest positive impact on java enterprise development since well...java - continue to work around the same problems that their innovations were created to work around to begin with? (Speaking of IoC via Spring && whatever Hibernate is supposed to be called nowadays of course) I guess I've been guilty of being this way in the past but I've grown up some since then and can see that they are just people trying to make other peoples lives better by dropping their academic hangups and just solving the problems at hand. Sometimes some of you wicket devs appear to be operating in a context so far removed from reality - wrt your skills vs. that of the people you share your opinions with - that I am compelled to feel embarrassed for you. Well here's a useless comment opinion for you. Instead of doing all the gabbing and comment posts as you do so well - why don't you create your own headlines from some of your own technical achievements? How would that be for you eh? You'll probably not be able to see past your anger in my comments to find the truth but I hope you do.
-
It is great that so much effort still goes into trying to fix some of the rough edges of JSF. However, I believe that the concept of externalized navigation is a mistake for anything other than real workflow (BPM) driven applications. Imho, any improvement will be suboptimal at best.
I'm not following you on the fact that flow is like thinking in a procedural way. We are not talking about programming here and implementation but domain concepts, the domain being navigation. When you think about navigation, how do you think about it naturally. Personnaly it's not far from a flow. -
Helpful as ever Jesse.
-
Alexandre, Imho, if you are solving a workflow problem, and let your application design reflect that, the workflow drives the UI, in which case externalized flow might be a good idea. If you follow that approach, I believe the workflow engine should be in charge all the way, and an intermediate layer (SWF?) should just be there as a translator between the workflow layer and UI. But how many people are actually creating applications that are centered around workflow? I think most applications build today (please feel free to slap me with some hard data if you find that) primairy have a domain centric design. The UI in such applications mainly exist to expose the domain model, and workflow is typically baked in in the domain model and limited to some very specific cases. Like I state in my blog, I believe externalized flow in such applications is a bad idea. It's another driver for sticking people to a documented oriented conception of applications. If you are truly working with pages that represent one function, and from each function there is a clear path to the next page representing another function, then fine, consider my remarks redundant. I just don't think that's the case often, and I believe that stressing flow as a major conceptual part of a framework puts people in the wrong mind set.
-
When you think about navigation, how do you think about it naturally. Personnaly it's not far from a flow.
I think a natural way of thinking about navigation is not to think in page based flows. Take any desktop application; whether buttons pop up a panel, replace part of the window or maybe the window altogether, 'flow' is much more localized compared to how people view web applications. But imho, there is no compelling reason for that, other than that the document oriented beginnings of the web.
7 comments
Reply