On Sat, 7 Jun 2003, David Graham wrote:
> Date: Sat, 07 Jun 2003 17:30:36 -0600 > From: David Graham <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: What's next for Struts? > > To be honest, I haven't had much time to actually use JSF in a test app. I > have read about it and looked at how it works and submitted some feedback to > Craig and the rest of the JSF team. I think it's great that there is now a > standard view layer toolkit. I intend to replace the Struts html taglibs > in my own apps when JSF goes final (I've already replaced the other Struts > tags with JSTL). > That's a pretty smart idea (of course, you can't do it for production apps until JavaServer Faces 1.0 goes final, which won't be for a while yet, but it's important to go through the learning experience now ...). In the mean time, I suggest that Struts developers complete an experiment I finished just last week -- convert struts-example to be a pure JSF based application. There is still an important acknowledged hole in JSF (we don't have a DataGrid component yet, so you need some sort of dispatching servlet to deal with the "create subscription", "edit subscription", and "delete subscription" links off of the registration.jsp page -- but I can guarantee you that's going to get fixed, which will also deal with a lot of general master-detail requirements that people have. The results are pretty sobering. With the EA4 release of JavaServer Faces, you can now *easily* create a "business object bean" (what Microsoft calls a code-behind class) that is essentially (in Struts terms) a form bean plus an action, which is instantiated and configured on demand (i.e. you can put it in request scope or session scope). This is also similar in spirit to the WebWorks approach to what we call Actions, which (as I have acknowledged before) I would have implemented in Struts if I'd thought of it before Rickard did. Coupled with the new navigation rules capabilities, it is very easy to achieve the same sorts of MVC-oriented separation of concerns that we are so proud of supporting in Struts. That means that we, the Struts developer community, have our work cut out for us on *future* versions of Struts, in order to provide value above and beyond what anyone who implements the standard APIs will be able to provide out of the box. The "bean" and "logic" tag libraries that originated in Struts had a *hugely* positive impact on the evolution of JSTL 1.0. In particular, the existence of the expression language is, in no small measure, due to my insistance that no JSTL library would be of much use to application developers familiar with Struts unless it provided a more powerful expression evaluation capability than what Struts already had :-). The result? Not only did JSTL 1.0 create a very powerful and useful expression language syntax, it got adopted into JSP 2.0 so you will now be able to use it *everywhere* in a page -- not just in the attribute values of particular tags that know what to do. That's a powerful testament to the influence that Struts has had on web tier Java technologies. Now, the same thing is happening with the "html" tag library, and the emergence of UI oriented tags (JavaServer Faces is very much more agnostic about the actual markup language than Struts has ever been, but the standard renderkit that comes with Faces is still HTML oriented). Again, we set the bar pretty high -- to succeed, any UI framework needs to deal with all the issues that the Struts tags take care of for you. In that respect, though, JavaServer Faces has been *much* more aggressive -- it wants to help you encapsulate layout things (what tags like <h:panel_list> and <h:panel_grid> do), and the general concept of nested UI components so that you can build things like a tree control without componsing them by hand. That, plus all of the other capabilities of the JavaServer Faces model, owe no small part of their sophistication to the fact that Struts already existed -- but the standard had to dramatically exceed it's capabilities in order to be successful in the marketplace. And it will. > I am a big proponent of using standard technologies wherever possible. This > leads to much faster app development because we don't have to learn new > frameworks and support is built into IDEs. I'm also a proponent of OSS > projects because they push the standards to be even better (Struts has > obviously made a big impact on JSTL and JSF). The JSTL, JSF, and Struts > toolkits have made building Java webapps extremely easy without giving up > maintainability. Struts has won support by almost the entire population of big time development tools for web applications. Stay tuned next week (JavaOne) for some interesting stories about support for JavaServer Faces as well. > Struts is by no means dead because the JSF doesn't have all the > functionality that Struts supports. No, Struts is definitely not dead. In fact, there is continual innovation towards allowing people who have invested in understanding Struts to leverage the latest and greatest web application technologies that are available. And the efforts to support those who have already committed to Struts will definitely continue. In fact, this is exactly why I went to the extra effort to make sure that JavaServer Faces components can be used by people who have developed existing Struts-based applications -- the people who have done this have had a faith that their investment in Struts will not be wasted. And it has not! That being said, it will be pretty clear to people who do some serious experimenting with JavaServer Faces EA4 that the emerging standard has raised the bar for what any existing web application framework (not based on the standard) needs to deal with in order to be competitive in the future. At the present time, for Struts, that comes down to our integrated support for Tiles (and I'm sure that is a solvable problem, since Tiles is already usable outside of the Struts environment). It's not just a couple of our tag libraries being standardized -- it's the HTML tag library (which many people consider a key value add of Struts) plus the core MVC capabilities (which is what I've always considered to be the most important Struts feature) that is being standardized. Here, as with the bean and logic tags, Struts has set the bar for a standard to be successful pretty high. Here, as with the bean and html tags, the emerging standard is going to exceed the capabilities supported by frameworks like Struts -- but this time, it is not going to be just a replacement tag library. It's going to encompass the entire reason that I created Struts in the first place. I have been in the fortunate personal position of getting paid (this time around) to create a compelling architecture for web application development on the Java platform. The experience I have gained building Struts (and working with the Struts developer and user communities) has been *invaluable* in achieving that goal. JavaServer Faces never would have happened in the way it has, without all of you demonstrating the demand for high quality frameworks and APIs. But, as a Struts developer, I have to be wondering what we can do for an encore, now that a standard is usurping our primary sphere of expertise. One of our options, obviously, is to actually implement the JavaServer Faces standard itself (and provide value add capabilities around it). That is a very feasible model, and not particularly hard to implement (achieving compliance with the JavaServer Faces specification is engineering, not rocket science; although there are plenty of opportunities to innovate on improving performance). But that's not the only avenue we have available. I've got some ideas about what else we can do that I haven't had a chance to formalize yet -- ask me after JavaOne (I'm still not done with my last slides and demo, and it starts on Tuesday :-) and I'll have a chance to tell you about them. But, fortunately, I'm not the only bright person involved in this effort ... > David Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
