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]>
