Xmlifying everything is a pain?


General J2EE: Xmlifying everything is a pain?

  1. Xmlifying everything is a pain? (4 messages)


    I would just like to get a bit of feedback into something I have been experiencing, namely, the xmlification of java tools...

    I have extensively used things like, hibernate, ibatis, xforms, struts, etc etc...

    These tools are all based on xml configuration files, which everyone seems to agree are great.

    Does everyone agree? The problem I have is that anything in an xml file is not subject to compile time checking. For example, if I have a ibatis query that maps the query results to a property in a javabean, and I get one of the javabean property wrong, I can only find out when that query is run.

    Now, I could get round this, sort of, with autogeneration, but this still seems to be a pain in the ass.

    I like compile time checking! Why are we heading away from this?

    any and all opinions encouraged!


    Threaded Messages (4)

  2. Re: Xmlifying everything is a pain?[ Go to top ]

    No you should take advantages of this decoupling of components. Since you have all your components sepperated you can also test them sepperately.

    I agree that you can make mistakes in your xml when you are glueing everything together, but consistent naming and a good editor which understand dtd's/schemes usually does the trick.
  3. Re: Xmlifying everything is a pain?[ Go to top ]

    I agree with the advantages, decoupling etc., but... are they enough to outweigh the loss of compile time checking?

    Especially when dealing with ORM tools, it seems to be a massive pain to find out I have made a typo at runtime, or even later.

    are we sure the advantages of decoupling outweigh the advantages of compile time checking? I am not sure. Is there a way we can still decouple without losing compile time checking? Or should the tools, ibatis, hibernate etc, be able to do this sort of check for us? (actually, that doesnt sound very hard...)

  4. Try unit testing?[ Go to top ]

    Another form of checking can be done by unit testing.

    Admittedly, compiler found errors are useful, but limited.

  5. Try unit testing?[ Go to top ]

    Thanks for the comment. I do unit test comprehensively, but I think its a solution to another problem, not one that should be taken care of by compile time checking.

    I am just not certain that sticking everything in an xml file for... dubious? reasons, and giving up compile time checking makes sense.

    Compile time checking is far and away the most efficient method of picking up errors. I am of the opinion that any error that could be picked up at compile time should be, and this move towards xmlifying everything worries me.

    I am just not sure that the benefits of xml (which appear pretty minor in terms of ibatis, hibernate et. al. am I wrong here? ) outweigh the costs...