RE: [Springframework-developer] custom XML config files

[Mason, R. <ros...@vi...>]

This would be really useful.  For applications that are constucted by =
spring it is much eaiser, quicker and less error prone to be working =
with a domain-specific config file with a dtd/xsd to describe/validate =
as you go.

+1

>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of jas...@ma...
>Sent: Thursday, 24 June 2004 1:32 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] custom XML config files
>
>
>
>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=3D"..." timeout=3D"2000"/>
>> |
>> | into
>> |
>> |     <bean class=3D"MyConnectorBean">
>> |     <property name=3D"url"><value>...</value></property>
>> |     <property name=3D"timeout"><value>2000</value></property>
>> |     </bean>
>> |
>> | This could be a trivial optional transformation step written in a=20
>> little
>> | Java code, where the ActiveMQXmlBeanFactory could derive from the=20
>> Spring
>> | XmlBeanFactory and install a custom transformer into the
>> | XmlBeanDefinitionReader so that any XML notation the=20
>ActiveMQ factory
>> | knew about could be transformed into normal Spring XML ready for=20
>> Spring
>> | to do its thing.
>>
>> One way to do that would be XSLT.  I've often considered doing just=20
>> that
>> type of thing.  For instance, our views.xml file is getting=20
>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=3D"/WEB-INF/jsp/foo.jsp" />
>>
>> than:
>>
>> <bean class=3D"org.springframework.servlet.view.JstlView">
>> ~  <property name=3D"url">
>> ~    <value>/WEB-INF/jsp/foo.jsp</value>
>> ~  </property>
>> </bean>
>>
>> Other nice things about this is a DTD can be created for the=20
>shortened
>> version, to allow for validating and smoother XSLT.  Also, if others
>> need to extend the shorted form, they can either edit the=20
>XSLT file, or
>> better yet, just start writing spring BEANS elements.  The XSLT file
>> should just recognize the native spring beans elements and transfer=20
>> 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=20
>reduced somehow.
>
>XSLT is certainly one way of doing it. Either way, whether its some=20
>Java code that does the transformation, or XSLT the effect is the same=20
>- we get a shortened XML file (along with a custom DTD / XSD) for=20
>easier editing.
>
>Personally I find XSLT to be a PITA so would rather a little=20
>simple bit=20
>of Java code to navigate over a DOM tree and turn elements into normal=20
>Spring XML but each to their own. So long as the hooks are there to=20
>easily modify the DOM before Spring starts to process it, folks could=20
>use Java code or XSLT to transform the DOM.
>
>James
>-------
>http://radio.weblogs.com/0112098/
>
>
>
>-------------------------------------------------------
>This SF.Net email sponsored by Black Hat Briefings & Training.
>Attend Black Hat Briefings & Training, Las Vegas July 24-29 -=20
>digital self defense, top technical experts, no vendor pitches,=20
>unmatched networking opportunities. Visit www.blackhat.com
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>