Re: [Springframework-developer] custom XML config files

[<jas...@ma...>]

On 23 Jun 2004, at 19:08, Seth Ladd wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> | Using the example above we could use a simple macro which turns
> |
> |     <connector url="..." timeout="2000"/>
> |
> | into
> |
> |     <bean class="MyConnectorBean">
> |     <property name="url"><value>...</value></property>
> |     <property name="timeout"><value>2000</value></property>
> |     </bean>
> |
> | This could be a trivial optional transformation step written in a 
> little
> | Java code, where the ActiveMQXmlBeanFactory could derive from the 
> Spring
> | XmlBeanFactory and install a custom transformer into the
> | XmlBeanDefinitionReader so that any XML notation the ActiveMQ factory
> | knew about could be transformed into normal Spring XML ready for 
> Spring
> | to do its thing.
>
> One way to do that would be XSLT.  I've often considered doing just 
> that
> type of thing.  For instance, our views.xml file is getting huge.  That
> type of file really lends itself to a shortened version.  Then, using
> XSLT at runtime, we can transform the views optimized XML into a full
> Spring BEANS xml file.
>
> I'd rather see this:
>
> <jstl url="/WEB-INF/jsp/foo.jsp" />
>
> than:
>
> <bean class="org.springframework.servlet.view.JstlView">
> ~  <property name="url">
> ~    <value>/WEB-INF/jsp/foo.jsp</value>
> ~  </property>
> </bean>
>
> Other nice things about this is a DTD can be created for the shortened
> version, to allow for validating and smoother XSLT.  Also, if others
> need to extend the shorted form, they can either edit the XSLT file, or
> better yet, just start writing spring BEANS elements.  The XSLT file
> should just recognize the native spring beans elements and transfer 
> them
> over.
>
> A XstlBeanFactory would do the trick there.  Given an XML file, and a
> XSLT file, it should transform then delegate to XmlBeanFactory.
>
> Ideas?  Thoughts?  This might be a good middle ground for those that
> like XML and those that want to see the XML verbosity reduced somehow.

XSLT is certainly one way of doing it. Either way, whether its some 
Java code that does the transformation, or XSLT the effect is the same 
- we get a shortened XML file (along with a custom DTD / XSD) for 
easier editing.

Personally I find XSLT to be a PITA so would rather a little simple bit 
of Java code to navigate over a DOM tree and turn elements into normal 
Spring XML but each to their own. So long as the hooks are there to 
easily modify the DOM before Spring starts to process it, folks could 
use Java code or XSLT to transform the DOM.

James
-------
http://radio.weblogs.com/0112098/