Well, that is not a very representative example and I'm sure that you
or I could come up with a better one that does make it look much more
like code, but whether the web beans schema does or does not look like
code, or even whether it requires knowledge of the Java class in the
presence of a schema generator, was not the point, really. My point
was that it is a different way of writing XML. If you want to argue that
the existing JEE descriptor style is more like code, then go ahead, but
the more that you argue how different the two are (no matter which side
of the "more like code" side each falls on) the more you are supporting
the fact that they are different and require different thought processes
to write. In fact, if they were not different enough then you wouldn't
even be bothering to argue that the web beans style was worth keeping :-)
-----Original Message-----
From: Gavin King [mailto:gavin@hibernate.org]
Sent: Wednesday, December 24, 2008 8:09 PM
To: Michael Keith
Cc: Scott Ferguson; Java Community Process JSR #299 Expert List; Jim
Knutson; Matt Drees; WebBeans
Subject: Re: XML configuration format
On Thu, Dec 25, 2008 at 12:01 PM, Gavin King
<gavin(a)hibernate.org> wrote:
> On Wed, Dec 24, 2008 at 12:23 PM, Michael Keith
> <MICHAEL.KEITH(a)oracle.com> wrote:
>> I would say that writing web beans XML, which is more
>> like code, requires a rather different mindset than what
is applied when
>> writing traditional Java EE descriptors.
>
> Again, I disagree. For a developer configuring a
pre-packaged library,
> the "traditional" XML style requires a lot more knowledge
of the code
> (Java class, method names, etc) than the "web beans" style
does. With
> the web beans style, the configuration author doesn't see anything
> about Java - everything they need to know is completely encapsulated
> in the schema for the library.
I want to reiterate this, because it's an important point:
<web-bean>
<class>org.jboss.jbpm.Jbpm</class>
<field>
<name>datasource</name>
<value>java:comp/env/datasource</value>
</field>
</web-bean>
is a *much* more Java-code-centric approach, and requires much more
knowledge of the underlying Java classes, than:
<jbpm:Jbpm>
<jbpm:datasource>java:comp/env/datasource</jbpm:datasource>
</jbpm:Jbpm>
I really don't agree that the second example is "more like code", in
fact I think it's less like code.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org