A few months ago I wrote an entry about development frameworks and things to consider when making a framework decision called
Development Requirements and Business Value.
This discussion has been an ongoing struggle with me as I continue to learn, and discuss with others their experiences with difference approaches and different frameworks. A lot of my previous experience is from leading development teams through projects on consultant engagements, so I am aware of the struggles that team members and development leads go through in making these decisions. I don't believe that a project manager or "hands off" architect can make an arbitrary decision to use a framework without understanding the massive impact it may have on team members. Many things must be taken into account, skill level, training, project requirements and the time line for a project delivery.
Before going to far, I'll mention a few of my colleagues Skyler Thomas, Brad Bouldin, Tim Hanis, Svetlana Petrova , and my manager Ken Polleck. All of whom have spent time recently discussing this topic with me ad nauseam, helping me define some of the thoughts below.
Most folks agree that in some cases the portal API can be a bit limiting, especially with the move toward JSR 168. Many developers who come from a Struts background want to continue with some of the features such as validation and page navigation that Struts made so easy to handle. JSF continues with that good stuff and adds more in terms of reusable interface components that can be used to quickly build up an interface and bind data to back-end methods. As more development teams become familiar with JSF they become enamored with the idea of making developers more productive by allowing them to use the tooling, specifically in Rational Application Developer to quickly build up portlets that can do all sorts of cool things.
The obvious thing to say is that JSF is great and everyone should move to this framework, however I'm always a bit cautious about new things that are supposed to revolutionize the way we do things. I am devoting and will continue to devote some of my time to ensuring that JSF is used in a correct manner and not just because it is a new great thing.
Don't get me wrong. It's pretty cool and I expect that more and more folks will grow into these frameworks as they evolve more with WebSphere Portal. With that, I've come up with two rules around using JSF that have to be kept in mind as you move forward with your project. Actually as Tim Hanis pointed out to me, these rules are not specific to portal or even JSF in many ways. They can apply to any framework.
Rule 1: JSF allows you to quickly build portlets within a framework and using the components. BUT, using JSF implies restrictions. Mostly that you use the components as they are designed.
If you need new functionality, then you have the option of changing the component to include the additional functionality, or letting a developer figure out a work around. Both of these require more expertise, skill, and time. Sometimes more then if you did not use JSF in the first place. (IMHO) This also requires that your advanced developers need more training and are working on these enhancements.
Rule 2: The Tooling for JSF is not intelligent enough to always build a well designed application. Using this tooling to build a portlet may result in problems within your production environment if the design is not evaluated by more experienced folks.
Corollary to Rule 2: Tooling can't help a poor design. For example if you store data that a component uses (like a list box) in the session instead of taking another design approach. Less experienced developers may not even know there are other design approaches.
My favorite example of this is when folks build a portlet that uses the web services client. Inexperienced folks will not worry about the fact that this portlet will access the service for every user. In some cases this may be OK, but in many cases it could overtax your portal and may lead to performance issues.
JSF is pretty still pretty new and so the jury is still out in the portal world as to how effective and worthwhile it has been. One of my favorite questions to development teams is, "how did using Struts (now JSF) improve your effort"? and "Do you think you could have been more productive without it, using a plain portlet API?". The results are often interesting.
I (and I'm sure others) would love to hear and learn from your comments about which framework you are using, why you choose it, and what the outcome has been?
Is JSF the Right Choice for You?
JoeyBernal 1200007EAE Identificações:  best_practice design portlet_api 3 Comentários 1.598 Visitas