|
Can’t say that I disagree with all of the comments here, but some are pretty biased. As far as JSP and Tags being a “big ugly kludge” and a mistake, I would agree there are some issues but someone might want to inform the thousands of applications built and running using these technologies; successfully I might add. I know, I know, there are also many applications implemented with CGI, or Active Server Pages, or other non-perfect technologies. My argument doesn’t necessarily make JSP good. But read on.
Here’s the problem as I see it. I want a UI technology where I can describe a UI separately from other aspects of the architecture, like business objects or data access layer. Have the UI architecture work for multiple channels, Web, Rich Client, Handheld, etc. and provide all of the typical features that as developers, we’ve come to expect (localization, session management, security, validation, etc). And I want a consistent, portable approach. Note that I didn’t say a standards-based approach. Although I think that inevitably an approach based on standards is beneficial, it doesn’t bother me that if in the beginning there are no official standards if this helps to move the innovation along. Look at Struts and its popularity. There were no standards for its Tags for example until JSTL came along. This is fine with me.
However, we have to solve the problems I mentioned above. Just as people are tired of trying to decide what persistence mechanism to use for every new project, choosing a UI framework shouldn’t be so difficult. However, I’m perfectly ok with letting the market settle that question. Regardless, I haven’t seen a solution that’s perfect; each one comes with it’s own scripting language or framework oddities. Why is choosing the best of all and combining into a single approach bad if it simplifies development and gets product to market faster?
So, whether it’s JSF or some other technology or whether Sun and company develops it or it comes out of the Apache birthing ground, I don’t care. The important thing is that we keep the innovation moving forward and don’t settle on where we are currently at as an industry. It’s just not enough for large, multi-channel, enterprise-class applications.
|
I've found this to be anything but the case; these different interfaces are funamentally different applications ... new use cases, new storyboards, different functionality. Trying to leverage reuse in the UI is a terrible idea; the end result (whether using JSF, XML/XSLT or something else) is to increase unwanted interdependencies between these fundamentally different applications ... it's programming inside a big case statement and will simply not scale.
Reuse is best reserved for the application layer (EJBs and beyond).
Main point:
"Why is choosing the best of all and combining into a single approach bad if it simplifies development and gets product to market faster?"
Where did this statement come from? Under what circumstances is JSF an integrating approach? JSF is anything but ... it locks you into a very specific event cycle and requires extensive tools support. Additionally, each vendor is likely to provide vendor-specific JSF components; it's the only lockin they have left.
More importantly, there's no evidence that JSF is capable of being the kind of integration technology that would allow developers to choose the best. It is something of a least-common denominator choice, partly because it is bound to JSPs, a limited and problematic technology.
You are right that no Technology will address every need but I feel that Tapestry is better positioned than JSF to address real developer's issues. Tapestry works very well as an integration platform for varied technologies because so much of it is based on JavaBeans properties (and OGNL, a vastly superior expression language).