> From: Ted Husted [mailto:[EMAIL PROTECTED]]
>
> I think we are all onboard with view agnosticism now.
Great!
> Though, the Struts config file will accomodate any URI, and does not
> prefer JSPs in anyway whatsoever.
>
> Personally, I'm liking the model we're seeing in X2 and VelServlet,
> where other "helper" servlets are loaded to handle whatever
presentation
> devices someone might use.
Using a URI to invoke a servlet is great for simple documents like JSP
or Velocity pages, but it is far too limiting for more complicated
"views" like XSLT. With a simple URI, how would you configure these
things on a view-by-view basis:
* Define multiple transformations to iteratively run.
* Pass xslt params to the transformation process.
* Run transforms against XML generated from JSP or other views.
* Define custom uri-resolvers.
* Specify the name of the root element.
I've found that it makes sense to distinguish JSP, Velocity, et al as a
separate stage from XSLT and DVSL. The former are "view" types, the
latter are "transform" types; users should be able to arbitrarily apply
transforms to views, and there is a considerable amount of configuration
data needed to define a transform. Furthermore, the framework's
interface to a transform is not necessarily text; it is often much more
efficient to be able to pass a DOM, SAX events, or other parsed data
directly into the transform.
Side node: A really neat idea adapted from Turbine is the "document"
transform which simply takes the output from executing one document and
passes it as a String in the request attributes to a subsequent
document. This addresses 90% of what the struts-template taglibs are
used for, but in a templating-language-independent way and with far less
mess.
I'm trying to make a case for allowing much more configuration to be
specified in the Struts config file. Taking all the above points, the
Maverick config for a command might look like this:
<command name="signupSubmit">
<controller class="org.infohazard.friendbook.ctl.SignupSubmit"/>
<!-- JSP which generates XML which is then processed -->
<view name="success" type="document" path="hello.jsp">
<transform>
<path value="outside.xsl"/>
<path value="english.xsl">
<param name="dialect" value="uk"/>
</path>
</transform>
</view>
<!-- XML is automagically produced from the model -->
<view name="error" type="domify" node="signupElement">
<transform>
<path value="signup.xsl">
<uri-resolver value="org.foo.CustomURIResolver"/>
</path>
<path value="outside.xsl"/>
<path value="english.xsl"/>
<param name="dialect" value="uk"/>
</path>
</transform>
</view>
</command>
That should be pretty clear, although it's a lot more complicated than
most commands would be. I don't think there is any way to do this sort
of thing in the current Struts config schema. Do you think it's
reasonable to try to evolve some of the Struts schema in this direction?
> I think what we are moving towards is exposing the Struts controller
API
> as a standard object in the request that will be easy to use with any
> helper servlet or presentation system, including JSTL when it ships.
Will it allow arbitrary XML configuration data to be pulled from the
config file?
> Does this jive with where Maverick is going?
Well, in Maverick 2.0 we removed Velocity from the core and are using
the same JSP-like servlet that Struts is using, so I guess the answer is
"sort-of" :-)
> The ActionMapping object is pluggable. Would extending that provide
the
> support you need in the config to assist with the transformations?
I'm looking through the docs and javadocs, and I'm not sure. How do you
plug it? And is it free to interpret the XML? Can it read
(hypothetically) child elements of <forward> (under <action>)?
Jeff Schnitzer
[EMAIL PROTECTED]
http://mav.sourceforge.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
