On Sun, 18 Jul 2004 23:56:55 -0400, Rick Reumann <[EMAIL PROTECTED]> wrote: > Craig McClanahan wrote: > > > For applications you are about to start on, if it is your intent to > > use the Struts HTML tags for your view tier, you should review that > > decision in the light of the developments of the last few months, > > since the JSF spec went final, to say nothing of the availability of > > alternative view tier technologies (XML, Velocity, ...) that work with > > Struts as well. If these tags work for you, that's fine ... but be > > aware that you are buying in to a mature technology that is unlikely > > to change much in the future. > > Craig, can you elaborate on this a bit more? I'm confused because if you > went with a different front end presentation other than JSP and Struts > HTML form tags, why would it matter that you chose Struts HTML tags for > the JSP portion?
If you choose Struts HTML tags for your presentation, you're stuck with what Struts provides. Since Struts has no user interface component model of its own, that has led to a variety of ad hoc solutions for more complicated requirements. If you choose JSF components, not only are you not stuck with what Struts provides (because the JSF API standards are common -- and there will be ***lots*** of third party components built on top of this standard), you're not stuck with JSP either. See below for more. > If you later chose an XML/XSLT or Velocity > (yuk:)solution for your view you'd end up scrapping the JSPs altogether > anyway so why would it matter what tags you used to build the JSPs that > you would be replacing? Or are you basically saying to not even bothr > using JSPs for a front end view? (I've seen good velocity templates and > I'll take a *clean* JSP using JSTL and tags over Velocity any day of the > week). Thanks for your thoughts and all your work on Struts, JSF, > Tomcat, etc. > The Struts HTML tags are very much specific to JSP ... indeed, their very implementation is as instances of JSP custom tags. You can't use them at all without buying in to JSP as a display technology. And, for various reasons, more than a few loudmouths :-) in the Java community do not like JSP at all. With JSF, however, the situation is different. Every JSF component is, at its core, just a JavaBean ... it doesn't care what technology is used to ultimately manage the page. Yes, we provide JSP tag wrappers around all the standard components (because that addresses the need of a very large portion of the marketplace), but it's not required. The reason is that JSF provides a pluggable ViewHandler implementation ... the default one does RequestDispatcher.forward() calls (just like Struts does), making it very easy to use JSP, but this is by no means required. You like Tapestry style separation of the component tree definition from the static HTML text? That's not hard ... go get Hans's JSF book and read the last chapter, to get you 80% of the way to a robust ViewHandler solution. Maybe you'd prefer XForms? Go for it ... writing a ViewHandler that transforms your favorite way of representing a component tree into an XForms document is MMP (Merely a Matter of Programming :-). Or, maybe you'd prefer an XML based solution that has all the component stuff in a single file, and you're contemplating an XSLT based solution that transforms component definitions into the corresponding HTML. Go for it. (Of, course, if you use the XML syntax for JSP pages plus JSF component tags, you get this pretty much for free ... oops, sorry, forgot you might be one of those that doesn't like JSP :-). The basic point is, JSF is not restricted to using JSP as the view tier ... although, for obvious market share reasons (the number of current Java developers that use JSP dwarfs the number that use other view technologies) JSF makes this very easy. > -- > Rick Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
