[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.
