personaly i like the jsf-guys for tables (<h:dataTable>, <h:panelGrid>)
there is NO need for adding table-specific-html (eg. <tr><td>) during the loop, like <html:iterate....> <tr><td><bean:write .../></td>...</tr> </html:iterat> see http://www.exadel.com/tutorial/jsf/jsftags-guide.html#column and http://www.exadel.com/tutorial/jsf/jsftags-guide.html#panel same with display-tag (http://displaytag.sf.net) on using struts/jsp, regards, matthias > -----Original Message----- > From: Jeff Stewart [mailto:[EMAIL PROTECTED] > Sent: Monday, July 19, 2004 7:40 AM > To: Struts Users Mailing List > Subject: Re: JSF vs Struts > > > I've been monitoring this discussion. I for one like using the struts > html tags over the JSTL/JSF semantically strange tags. > For one thing, feedback from the HTML developers I work with, prefer > html:interate this over the {c:jstl } garboono. > I mean, isn't this a big motivation why Struts was created. > > Craig McClanahan wrote: > > >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] > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
