springframework-developer

[Springframework-developer] xsl transforms

[David B. <viv...@gm...>]

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

Re: [Springframework-developer] xsl transforms

[Seth L. <set...@gm...>]

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>

We have often wanted to do this.  We have split our context files into
domain specific contexts.  Each domain is specific (DAO, web,
security, etc).  If each had their own format (internal to our needs)
it would make reading these files much easier.  Merely transforming
them into Spring's bean DTD at runtime makes sense sometimes.

Seth

-- 
<a href="http://www.picklematrix.net/foaf.rdf">Seth Ladd's FOAF</a>
<a href="http://www.foaf-project.org/">What is FOAF?</a>

Re: [Springframework-developer] xsl transforms

[Rob R. <rob...@ur...>]

I think this is a very good idea. I think it would be attractive to 
those who are turned off by the amount of XML in the Spring config 
files. Another example would be the Hibernate config from the petclinic 
sample app, which could have some of its config shrunk into something 
like this:

<sessionFactory dataSource="dataSource">
  <mappings>petclinic.hbm.xml</mappings>
  <property key="hibernate.dialect">${hibernate.dialect}</property>
</sessionFactory>

<dataSource type="driverManager"
  className="${jdbc.driverClassName}"
  url="${jdbc.url}"
  etc..
/>

I'm rusty on my XSL, but I think you could still use regular <bean> 
definitions and just have templates for "special" elements.

Rob

Seth Ladd wrote:

>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>
>>    
>>
>
>We have often wanted to do this.  We have split our context files into
>domain specific contexts.  Each domain is specific (DAO, web,
>security, etc).  If each had their own format (internal to our needs)
>it would make reading these files much easier.  Merely transforming
>them into Spring's bean DTD at runtime makes sense sometimes.
>
>Seth
>
>  
>

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

Re: [Springframework-developer] xsl transforms

[David B. <viv...@gm...>]

I do like that idea, but let me mention a few downsides.

One place where it might not be as flexible is in specifying where the
resource is.  For example, you couldn't do:
<?xml-stylesheet href="classpath:/transform.xsl" type="text/xml"?>

If we plugged in a new javax.xml.transform.URIResolver, we might be
able to still resolve paths using  Spring specific URI prefixes.

Along these same lines, it seems like it would be more desirable to
specify an xsl transform outside the XML file.  If I'm using the same
xml context file for both production and for a unit test, I can easily
specify the same file using different paths.  For example, in a
running web app, the path would be /WEB-INF/appContext.xml, but if I'm
running a UnitTest using FileSystemXMLApplicationContext, I might want
to specify an absolute path to create my context.  By this same token,
it would be nice to be able to specify the location of the XSL
transform from outside the spring context file itself.

So my preference would be a syntax like this:
transform:/(customContext.xml, customTransform.xsl). 

We could recurse through the "parameters" to the URI-type
specification, so if someone .really wanted to hang themselves, they
could put a file through multiple transforms, using sources from the
classpath or normal URL.

Maybe support of inline xsl should be supported in addition.

/David Bowers


On Fri, 18 Feb 2005 18:48:46 +0200, Juha Komulainen
<juh...@gm...> wrote:
> 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?