XML Config: viewpoints
I'm looking for some constructive thoughts on use and/or over-use of xml configuration within struts. The idea has been in my head for a while after blowing up application's numerous times with that small typo in a config file! Some thoughts... - Is it such a good idea to pour much of fundamental application design into xml files? - Should config files be confined to things such as database parameters? - Tendency for xml config to become a mini programming language in itself - Lacks type safety, syntax checking (ide / compiler) - Ultimately gets parsed back into application config classes The struts-config provides low-coupling, but could this be achieved more easily and efficiently another way e.g. static initialisation of core classes? XML gives language independence - but struts is basically a homogenous java environment, so I've lost sight of why I am designing my config in XML. With the struts-config, you can easily swap new classes, and change application parameters without recompiling, but this may actually hinder the real burden of ensuring application integrity, regression testing etc. I'm interested in different views on this to sway me one way or the other... Regards Paul Kelly -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: XML Config: viewpoints
At 5:05 PM +1000 2002/07/30, Paul Kelly wrote:
I'm looking for some constructive thoughts on use and/or over-use of xml
configuration within struts. The idea has been in my head for a while after
blowing up application's numerous times with that small typo in a config
file!
Paul:
You make some good points: XML syntax can be very burdensome for
programming -- I've had cases where it was horrible to try to
implement logic control with a set of nested logic custom tags, for
example, where the only real solution was to write my own custom tag
libraries. (Of course, custom tags are different than XML, but the
complexity of using tags is comparable.) And, of course, you don't
get any type checking and syntax checking in the XML.
However, given the regularity with which clients change their mind,
it has repeatedly proven worthwhile to externalize as much as
possible. This simply has to be done judiciously, with awareness of
the problems you cite. In general, I'd suggest that the Struts
framework provides some good examples of how to do this well.
Note that the swapping of classes in struts-config still requires
that the classes which get swapped adhere to common APIs -- this kind
of pluggability will save your life when you want to adapt something
you've done for one client to serve the next, who seemed to want the
same thing at first, but turns out to have a very loose definition of
same. But if you're coding to APIs and just using XML to specify
an implementation class, then you've still got the compiler covering
your for syntax checking by definition.
If you have some good tests, you can catch type-errors in XML data by
running the tests on your scripts before you introduce them into a
running system. Type and syntax errors are set-up problems, not
runtime problems (usually), so generally you find those problems
during development, long before anything gets deployed to production.
Another benefit of plugging in implementation classes of an API is
that it can make it easier to test your components independently,
using mock implementations, and it can let you work ahead of
integration partners (internal or client) because you can write a
development-phase implementation which feeds you usable data, and
then later just drop in an alternative implementation class which
actually does the real work. This was hugely valuable to me in my
first major Struts app, where we had a couple of integration points
with the client. They didn't deliver their web services until about
six weeks into the project, but when they did, I just swapped out
classes I had written which parsed test XML from the file system and
replaced them with classes which pulled that XML from their service.
Finally, having external configuration files opens up the possibility
that non-programmers can do simple adjustments to the system, which
means that you get to stay focused on the interesting stuff. (I'm
beginning to consider even allowing them to do some simple
programming in some of our systems with Jython or JavaScript w/Rhino
embedded in a configuration file.)
Hope that helps,
Joe
--
--
* Joe Germuska{ [EMAIL PROTECTED] }
It's pitiful, sometimes, if they've got it bad. Their eyes get
glazed, they go white, their hands tremble As I watch them I
often feel that a dope peddler is a gentleman compared with the man
who sells records.
--Sam Goody, 1956
tune in posse radio: http://www.live365.com/stations/289268
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: XML Config: viewpoints
On Tue, 30 Jul 2002, Paul Kelly wrote: Date: Tue, 30 Jul 2002 17:05:43 +1000 From: Paul Kelly [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED] To: 'Struts Developers List' [EMAIL PROTECTED] Subject: XML Config: viewpoints I'm looking for some constructive thoughts on use and/or over-use of xml configuration within struts. The idea has been in my head for a while after blowing up application's numerous times with that small typo in a config file! IMHO, it makes little or no difference that we're using XML syntax here. The key issue is that, in order to achieve the low coupling, *you* (the developer) are going to have to do things like define the mapping between action paths and the corresponding classes. There is not any way that Struts can infer this. Doing it in an XML file, in a properties file, or any other way that you have to type the names gives you equal chances to screw it up. Some thoughts... - Is it such a good idea to pour much of fundamental application design into xml files? - Should config files be confined to things such as database parameters? - Tendency for xml config to become a mini programming language in itself - Lacks type safety, syntax checking (ide / compiler) - Ultimately gets parsed back into application config classes The struts-config provides low-coupling, but could this be achieved more easily and efficiently another way e.g. static initialisation of core classes? XML gives language independence - but struts is basically a homogenous java environment, so I've lost sight of why I am designing my config in XML. With the struts-config, you can easily swap new classes, and change application parameters without recompiling, but this may actually hinder the real burden of ensuring application integrity, regression testing etc. I'm interested in different views on this to sway me one way or the other... The important benefits that using XML brings to Struts: * The data is naturally organized in a hierarchical manner, which is utilized to good effect when it matches the nature of the things being configured. This is miserably difficult in a flat file format like properties files. * The data format is amenable to being generated by tools instead of people. Things like Struts Console already do the grunt work of getting the XML syntax right -- extending this concept to automatically scanning a JAR file and building you a select box of all the classes that implement Action (so that you can point and click instead of type a class name) is the next logical step. Regards Paul Kelly Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: XML Config: viewpoints
Some thoughts... - Is it such a good idea to pour much of fundamental application design into xml files? - Should config files be confined to things such as database parameters? - Tendency for xml config to become a mini programming language in itself - Lacks type safety, syntax checking (ide / compiler) - Ultimately gets parsed back into application config classes The struts-config provides low-coupling, but could this be achieved more easily and efficiently another way e.g. static initialisation of core classes? I agree with the approach of consolidating configuration information into XML files whereever appropriate. The alternatives of embedding configuration in Java classes is just as error prone - in fact potentially more so. By using XML you present the opportunity for configuration validation via DTD or XML Schema. You also can consolidate most of your config information into a single place - rather than spread it out among a variety of Java files which is what generally happens. Another advantage is that using XML allows the configuration to be changed dynamically and then saved without having to recompile. Embedding constants in java files requires recompilation to alter the configuration. Struts doesn't yet (to my knoweldge) allow the struts-config to change on the fly and then be saved, but this feature may be desireable some day. The one thing I'll add is that once the XML gets beyond a basic level, there should be a tool provided that allows the user to manage the configuration without editing the xml directly. I believe that Struts is approaching this level FOR BEGINNING USERS. Those that have been using it for a while could probably edit the struts-config in their sleep, but for new people and entry-level developers the number of elements can be confusing at first. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: XML Config: viewpoints
Corrected link: http://www.objectventure.com/products/objectassembler.html -- Martin Cooper -Original Message- From: Bill Willis [mailto:[EMAIL PROTECTED]] Sent: Tuesday, July 30, 2002 11:20 AM To: Struts Developers List Subject: RE: XML Config: viewpoints Some thoughts... - Is it such a good idea to pour much of fundamental application design into xml files? - Should config files be confined to things such as database parameters? - Tendency for xml config to become a mini programming language in itself - Lacks type safety, syntax checking (ide / compiler) - Ultimately gets parsed back into application config classes The struts-config provides low-coupling, but could this be achieved more easily and efficiently another way e.g. static initialisation of core classes? XML gives language independence - but struts is basically a homogenous java environment, so I've lost sight of why I am designing my config in XML. With the struts-config, you can easily swap new classes, and change application parameters without recompiling, but this may actually hinder the real burden of ensuring application integrity, regression testing etc. I'm interested in different views on this to sway me one way or the other... The important benefits that using XML brings to Struts: * The data is naturally organized in a hierarchical manner, which is utilized to good effect when it matches the nature of the things being configured. This is miserably difficult in a flat file format like properties files. * The data format is amenable to being generated by tools instead of people. Things like Struts Console already do the grunt work of getting the XML syntax right -- extending this concept to automatically scanning a JAR file and building you a select box of all the classes that implement Action (so that you can point and click instead of type a class name) is the next logical step. I agree that tools are perfectly suited for this. ObjectAssembler (http://www.objectventure.com/objectassembler.html) not only generates and maintains the XML configuration file, but it gives you the next logical step that Craig is referring to. You are still free to type in, say, what action component is used in an action mapping, but OA provides a drop-down that gives you a list of all available fully qualified action components. Same goes for ActionForms and other components. In addition, OA provides real-time validation of all Struts components and configurations, which goes beyond pointing out compilation problems. What about deployment issues? Good programming practice? Tools like OA take much of the grunt work out of building these configuration files, packaging your stuff in a WAR, and deploying while avoiding common mistakes. And with the popularity of Struts, tool support for it will continue to improve. Regards Paul Kelly Craig Regards, Bill -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
