Re: [Springframework-developer] xsl transforms

[Juha K. <juh...@gm...>]

Actually the XML-file itself can specify the used XSL-stylesheet by
having a processing instruction like:

  <?xml-stylesheet href="transform.xsl" type="text/xml"?>

(See http://www.w3.org/TR/xml-stylesheet/ for details.)

Unfortunately, by default XML-parsers (or at least Xerces) won't try
to apply the specified XSLT-stylesheets when parsing. Still, it's easy
enough by loading the document with a transformer:

    Source source = new StreamSource(file);
    TransformerFactory tf = TransformerFactory.newInstance();

    // Extract the stylesheet from document, if there is one
    Source stylesheet = tf.getAssociatedStylesheet(source, null, null, null);
    
    // If document had stylesheet, use it. Otherwise use identity transform.
    Transformer transformer = stylesheet != null 
                            ? tf.newTransformer(stylesheet)
                            : tf.newTransformer();
        
    DOMResult result = new DOMResult();
    transformer.transform(source, result);
    Document document = (Document) result.getNode();

So if Spring would load the context-files using this strategy it would
be possible to get XSL-transforms for free.

Are there any problems with this solution?

On Thu, 17 Feb 2005 10:18:36 -0500, David Bowers <viv...@gm...> wrote:
> I've been thinking about an extension to the mechanism for specifying
> XML sources for Spring beans, where you specify an XML source and an
> XSL transform.   Something like this:
> 
>   <context-param>
>       <param-name>contextConfigLocation</param-name>
>       <param-value>
>          WEB-INF/normalContext.xml,
>          WEB-INF/cusomtContext.xml | WEB-INF/transformCustomContext.xsl
>     </param-value>
> 
> In the example above, the new ResourcePatternResolver would look for a
> | "operator", and "pipe" the first xml file through the second xsl
> transform, and use the result to build the BeanFactory..
> 
> And to be more ambitious, maybe someone could do something like this
> when using the Struts plugin.  If you turned validation off on the
> struts parsing, you could mix in certain spring document elements, and
> transform the struts-config into a spring context file, possibly
> eliminating the need for an additional action-servlet.xml file.
>   <plug-in className="org.springframework.web.struts.ContextLoaderPlugIn">
>     <set-property property="contextConfigLocation"
>       value="/WEB-INF/struts-config.xml | /WEB-INF/struts-transform.xsl"/>
>   </plug-in>
> 
> Another benefit of this is it could make it easier for someone to
> define common beans.  Instead of
> 
> <bean class="com.abc.domain.Entry">
>     <constructor-arg index="0"><value>someKey</value></constructor-arg>
>     <constructor-arg index="1"><value>someValue</value></constructor-arg>
> </bean>
> 
> which is very wordy if you specify 10 or 15 of those objects, you
> could write an xsl transform that would produce the above output from
> this:
> 
> <entry key="someKey" value="someValue"/>
> 
> I haven't researched exactly where in the Spring code this would have
> to be extended (it looks like it would just involve extending some of
> the implementations of ResourcePatternResolver).   Before I work on it
> (and no promises), I'm curious if this interests anyone else?  If so,
> any thoughts on what the XSL transform "operator" should be?   "|" is
> quite intuitive to me, but it could be any of the following:
> custom.xml * transform.xsl
> transform(custom.xml, transform.xsl)   // If very ambitious, allow a
> user to "plug-in" implementations of the function
> transform:/(custom.xml, transform.xsl)  //Looks more like a URI
> 
> /David Bowers
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 


-- 
Any clod can have facts, but having opinions is an art. --Charles McCabe