[list: we're moving this onto mav-user for obvious reasons :-) Included below is a brief comparison of Maverick to Struts & WebWork]
> From: Anthony W. Marino [mailto:[EMAIL PROTECTED]] > > Hi Jeff, > What do you think of the Struts opensource layer "stxx" ( > http://www.openroad.ca/opencode/ )? How does this compare with Maverick's > xml/xsl functionality? Meagerly :-) It looks like a crude first pass at providing the facilities that Maverick supports. Things missing from stxx that Maverick supports: . Multiple transformations. Not only does Maverick offer multiple transforms, but you can go between XML-based and text-based transformations seamlessly. . SAX input. Stxx only takes a (DOM or JDOM) Document as input. Maverick transforms can take text, DOM, or (most importantly) SAX as input. And XML-based transforms are hooked together with SAX events. Much more efficient than passing DOM trees around. . View independence. Using XSL with Maverick is no different, Java-wise, than using any other view. Our primary sample application comes in three flavors; JSP (with JSTL), Velocity, and XSL. They all use the same Controllers (Struts calls them Actions), so you can easily switch view technology method-by-method. With Stxx, your Actions have to be extend ActionStxx and call a number of special methods. . Automatic domification. Maverick will automatically convert your JavaBean model to a form that can be operated on by XSL; Stxx expects you to come up with a Document yourself (another reason their Actions are not view-independant. You could use our code (http://domify.sourceforge.net) with Stxx, but you'd have to set it up yourself. Struts was not designed from the beginning to provide transformation pipelines, so retrofitting the architecture is problematic. Jeff Schnitzer [EMAIL PROTECTED] For the list's benefit, the original conversation: > > I'm not very familiar with Tapestry, but all the others I have used > > fairly extensively: > > > > Velocity - this is not a competing framework but a templating language > > that works exceedingly well with Maverick. Personally, this is my > > favorite way to write web applications, although Maverick lets you use > > JSP, XSL, DVSL, or conceivably any other templating language as well > > (it's pluggable). > > > > Regarding WW and Struts, I'll go over it by topic: > > > > Templating technology independence > > ---------------------------------- > > WW and Struts have traditionally been tied to JSP, relying on custom tag > > libraries for data access. They're trying to claw their way out of this > > situation, but it's rough. WW, for example relies on an exotic concept > > called the "ValueStack" which does not map well onto anything other than > > their tags. You have to fight the system to use JSTL with WebWork. > > > > Maverick was templating language independent from the beginning, and I'm > > pretty sure that most Maverick users are using something other than JSP. > > We don't provide a custom tag library because the JSTL standard tag > > library works great with Maverick, if JSP is your taste. > > > > For both WW and Struts, rendering a view is simply a question of > > RequestDispatcher.forward()ing to a named document, be that blah.jsp, > > blah.vm, or blah.xsl. This works ok (but not great) for jsp and > > velocity, but is hopelessly inadequate for XSL. How do you set params? > > What if you want multiple transformations? How do you set custom URI > > resolvers? Maverick handles all of this elegantly in the sitemap file, > > where it belongs. > > > > And we really mean templating language independent. We provide three > > different versions of one of our sample applications; a JSP version, a > > Velocity version, and an XSL version. The java code (Controllers) are > > unchanged for each - only the templates and the Maverick config file > > change. > > > > Transformation > > -------------- > > The most dramatic feature that Maverick offers that WW and Struts have > > not even considered is the ability to hook up Cocoon-style pipelines of > > transformation to view rendering. Out of the box, Maverick can do stuff > > like this: > > > > Render the model to XML with a JSP > > Transform the XML with a common look-and-feel with XSL > > Convert to Formatting Objects with XSL > > Render the document to PDF with Apache FOP > > > > And you can even eliminate the rendering of XML with JSP by using a > > special view type called "domify" which automagically adapts a JavaBean > > graph to a DOM interface so that XSL (or DVSL) can be applied to it > > directly. > > > > Transformations do not have to be XML-based, they can be simple text > > transformations like wrapping the output of a previous step with another > > template (providing the data as a String in the context). This is > > really useful for basic look-and-feel templating in a JSP or Velocity > > world. You could easily build a regex text substitution transformation > > if you wanted to. > > > > Oh, another neat thing is that you can stop the transformation process > > midstream to obtain intermediate output. Very useful for debugging or > > offline development. > > > > Internationalization > > -------------------- > > Maverick can automatically pick between different view options (and thus > > different transformation pipelines) based on Language or any other > > characteristic of the request, allowing for some very sophisticated > > internationalization or browser customization options. By comparison, > > i18n in WW or Struts is just a question of getting the right > > messagebundle. Imagine trying to build an application where designers > > have to get all text from a messagebundle rather than putting it in the > > template. Yuck. > > > > Controller/Action paradigm > > -------------------------- > > Struts and WW differ on how Controllers (they call them Actions) are > > built and populated with request properties. Struts requires a separate > > form bean which becomes the model. WW uses the Action itself as both > > the populated bean and the model. Maverick lets you choose between > > either of these paradigms, or even create new ones yourself. Also, the > > model is not tied so closely to the Controller, so it can be something > > completely different. > > > > To be honest, if you really wanted, it would be easy to make real Struts > > Actions work with Maverick. We're that flexible :-) > > > > > > There's probably a lot more, but those are the biggies. I think you'll > > find that in general, Maverick and Struts and WebWork are all fairly > > similar in concept. If you understand one you pretty much understand > > them all. However, despite the fact that Maverick is a "minimalist" > > framework, I think we significantly exceed the feature set of either > > Struts or WebWork. We don't try to be *everything* in a webapp > > framework; there is no database pooling, tag libraries, or anything in > > Maverick that is not essential to MVC logic. All those things are > > well-provided by other sources. > > > > If this sounds good, take a look at the documentation at > > http://mav.sourceforge.net. We provide quite a few very comprehensive > > sample applications, too. > > > > Good luck in your research, > > Jeff Schnitzer > > [EMAIL PROTECTED] > > > > > -----Original Message----- > > > From: Anthony W. Marino [mailto:[EMAIL PROTECTED]] > > > Sent: Friday, June 14, 2002 11:22 AM > > > To: Jeff Schnitzer > > > Subject: Fwd: Re: One More Thing, Please > > > > > > > > Webwork > > > > > Struts > > > > > Velocity > > > > > Tapestry > > > > _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas - http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink _______________________________________________ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/
