yozzeff thinks

musings about programming

Sonntag, Oktober 09, 2005

xml backlash

code monkey is wondering why there is such a backlash
against xml in the java community recently and he asks
some questions at:
http://jroller.com/comments/coderant?anchor=another_xml_monster

to answer the easiest question first: no!
nobody expects you to code all those declarative things in java.
that be complete madness.

but fact is that xml is and has been abused way
to much in the last few years.
often this is not necessarily an issue of xml but an
issue of the api design that exposed thru the xml.
ejb and its host of xml files are certainly the showcase for it.

poor api design


usually the real issue is that those APIs are created with
no simple and useful default settings. so one has to specifiy
a host of xml elements and attributes.
that is certainly a reason why ruby on rails is gaining so much
traction: usefull defaults where RoR tries to deduct from context
a lot of information and of course that ruby is an
extremly nice language too :-)

it is a difference if i can specify a simple persisten class as

class Foo < ActiveRecord
end

and be done or if i have to write

<hibernate-mapping import="false">
<class name="Foo" table="FOO" schema="myschema">
<id name="id" column="id" type="string">
<generator class="uuid.hex">
</generator>
</id>
<property name="bar" column="BAR">
<property name="baz" column="BAZ">
</class>
</hibernate-mapping>

actually there is nothing that forbids hibernate (or any
other project) to have a set of well defined and
documented defaults that in the end would allow
for something like this

someHibernateManager.registerSchema("myschema");
someHibernateManager.addClass(Foo.class);

no hbm files what so ever.
if you for example now refactor the property "foo" to
"foobar" there is exactly one place to go. thats it!
alas this is no blog entry about hibernate - so lets
move on.

no breaking up of config files


the second issue is intrinsic to xml (or has been at
least until only very recently):
there where no defined ways to break up ones configuration
files into small and easy to handle packages. that usually
lead to having to build some sort of pipe designs
in order to merge the small config files into one before
being able to consume it.
all of this is of course doable. and i have done it more
than once .
finally this year XInclude has arrived. but of course only
very fresh and new libraries like XOM 1.1 support it.

no escape from the "declarative way"


sometimes (often?) defining something declarative
is simply not enough. not only once in my projects
the need arose to have for exaple a simple "IF"
contruct (and belive me where an IF lurks a WHILE
is hiding very closely).
lets see the hibernate conf file again

<hibernate-mapping import="false">
<class name="Foo" table="FOO" schema="myschema">
<id name="id" column="id" type="string">
<generator class="uuid.hex">
</generator>
</id>
<property name="bar" column="BAR">
<if expression="deployment_server.name == 'TEST'">
<property name="baz" column="BAZ">
</if>
</class>
</hibernate-mapping>


so you suddenly have to implement more or less a
fullblown programming language on top of your own
mini configuration language.
aah, i could use XSLT! sure! even more infrastructure i
have to build so that every config file is first
correctly preprocessed before being read and interpreted.
besides that writing an reading XSLT templates is
not exactly fun.

use a scription language for the JVM


so if you dont want to do your configuration in java
why dont you use a scripting language instead of XML.
i have written a bit about choosing one at:
http://yozzeff.blogspot.com/2004/12/choosing-scripting-language-for-jvm.html

your infrastructure needs will be far smaller and you
can concentrate more on the business task at hand.

of course a scripting language wont help you if your
api sucks and you expose it via jruby or groovy. then your
users will have to write loads of jruby config code and
you will experience a jruby backlash.

0 Comments:

Kommentar veröffentlichen

Links to this post:

Link erstellen

<< Home