The Two Faces of JSF on WLP
With a JSF JSP in focus, the Design Palette will list all of the available tag libraries for drag-and-drop style development. If you are new to JSF, it sometimes will be more productive to write your first tag calls by hand to gain the understanding of what values to use for which options. Once you understand how the libraries work, the DP will save you a great deal of typing.
Having updated faces-config.xml with the proper references to your JSF page and backing bean, follow the steps described under Creating a JSF Portlet and you are done.
When to Use What
I want to start off by saying there are almost definitely considerations not covered here. These are things I have thought of while commuting or have heard people discuss around a single project where they were evaluating the options of using JSF in WLP.
The Beehive Page Flow Approach
The two main reasons to take the Beehive path is to provide a faster path for developers already familiar with Workshop but new to JSF and to take advantage of the rapid development tools that Page Flows offer. You also can use many of the NetUI libraries on the JSP, another productivity boost.
If you are already familiar with JSF, some of the API differences will take getting used to. The backing bean APIs are similar but different from the standard JSF backing APIs.
Standard JSF Development
Towards the start of this article, it was mentioned that while early adoption is cool, your early successes may not fit into the standardized future. Even though the Beehive approach does follow standards and uses open source rather than proprietary libraries, it is likely the tools will change and possibly the APIs will, too. Where the Beehive approach is the better choice for developers well-schooled in WLP development, if you are already proficient in JSF development there is nothing in WLP preventing you from using the skills you already have, and a few tools to allow you to be more productive with that experience.
Wait for the New Standards
There are two mutually exclusive and equally valid philosophies about what to do when you are uncertain. One is to do anything different, expecting to change your outcome and gain additional feedback. The other is to do nothing and let the situation work itself out. JSF is a break-out technology because it is based on standard tools available in J2EE. The servlet/JSP architecture gained its popularity the same way (ready to feel old?) back at the turn of the century. The servlet/JSP approach is still going strong, though very few developers use the base APIs anymore. Most of us use frameworks that extend those APIs for rapid development, and most of those frameworks are mature enough where they are portable. Even when standards are complete, the tools to implement those standards take some time to mature. JSR 168 promised portable portlets, although portlets that implement that standard are only now becoming truly portable.
JSF is mature enough to have some good frameworks available, some of which are even fairly portable (proof that the industry does learn from its mistakes). But, JSF portlets are still in their Wild West stage, and may not support your requirements. Not all JSF frameworks can be used in portals, and those that do seldom work in all portals, even the FOSS frameworks. Sure, a good developer can almost always find a way to make it work, but it will take time away from delivering on requirements and most likely have to be changed once the standards are commonly implemented.
My crystal ball has always been cloudy, and when it is clear it is just as likely to show the future of a parallel universe as the one this article is in. Odds are good that the future of JSF portlets will come to pass. The only question is if it is worth acting on that future today. That is a decision that is best based on the needs of today.
About the Author
Scott Nelson is a Senior Principal Consultant with 12 years of experience designing, developing, and maintaining web-based applications for manufacturing, pharmaceutical, financial services, non-profit organizations, and real estate agencies for use by employees, customers, vendors, franchisees, executive management, and others who use a browser. He also blogs all of the funny emails forwarded to him at Frequently Unasked Questions.
Page 3 of 3