This post originated from an RSS feed registered with Java Buzz
by Steve Conover.
Original Post: XML vs Java config discussion
Feed Title: Steve Conover's Weblog
Feed URL: http://www.sonic.net/~conover/index.rdf
Feed Description: Mostly java-related.
After dealing with AOP and especially MVC config for a while now, I've been doing some thinking about where config stuff ought to happen. (I was going to wait to post about this, but it seems to be on-topic in the wake of Jon and Rickard's entries). Rickard says: However, as the Java configuration grew it at some point became too unwieldy and hard to read, especially since we have two parallel configurations: one for the server and one for the client, and some is shared and some is not shared. Expressing that in Java code became a true burden. I'd be interested to hear more about the reasons why. To me this is the central problem of putting config into something external to java - you miss out on the power of an OO language to factor out duplication. For instance if I have 20 entity classes that are configured similarly (but let's say, not exactly the same), I have to have 20 different entries in XML, vs very few lines of code in java (using simple functional programming, or even polymorphism). I'd be interested to see a code example where doing config in Java (with well-factored code!) is more complex than in XML. Plus, why put things outside of Java that are changed exclusively by engineers? There will never be a separate role on a project for a non-engineer who adds an interceptor, or some action->view mapping (or even a form field, probably). If I keep these things in the code, I have my string constants are all in one place, my IDE can easily do refactorings, and as mentioned, I have all of the possibilities the Java language gives me to remove duplication. Comments welcome....
Previous Topic
