commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Tirsén <>
Subject [attributes] Jakarta Commons Attributes, Nanning & XRAI
Date Fri, 15 Nov 2002 14:56:25 GMT
I'm CC:ing commons-dev for this. The background for
the list is:
James and Jon started commons-attributes a couple of
days ago.
Ara joined the effort today.
Commons-attributes will be a unified lightweight
runtime-API for accessing attributes. XRAI will be one
runtime-implementation and an extensive
We're discussing how to design a good lightweight
commons-attributes-API that will not be a hindrance to
XRAIs additional features.

Ok, here's my opinions :-)

> Well, lets see how we can provide a good api, a
> forward looking one but
> one which does what it does now perfectly without
> any for-future
> sacrifices. So I propose a hierarchy of attributes:

Agreed. YAGNI. :-)

> - At the top we have the Attribute interface,
> nothing interesting there.
> - Then we have SimpleAttribute derived from it, it
> has "String
> getProperty(...)" methods. They return String so
> it's the getText you're
> talking about.

I propose adding getText() to the Attribute-interface
to make things more simple. That means all Attributes
has to be able to retrieve the original textual value.
I think that's pretty reasonable. If we do this all
trivial usages will be able to access the strings.
When things needs to be more complex (support
compile-time-validation, strong typing and so on) they
can add that support in those places and still have
other trivial code left that uses strings. In that way
we can easily support a wide range of use-cases.
Seems reasonable?

> - Then we'll let user define
> EjbAttribute/custom-attribute derived from
> the new CustomAttribute class, CustomAttribute
> derived from
> SimpleAttribute. C#/jsr175 style. What it does is it
> responds to
> getProperty (overridden from SimpleAttribute) by
> doing getMethod() for
> the attribute property and fulfill that request.

Yep, but this goes into XRAI, right?

> - We'll add "SimpleAttribute
> getSimpleAttribute(...)" to ClassMetaData
> so if you want to use the simple attribute interface
> you just call it
> and no need to cast it from Attribute to
> SimpleAttribute. So a client
> which doesn't know that an EjbAttribute class exists
> or wants to deal
> with attributes with the common SimpleAttribute
> interface can use this
> method. A client who knows the @ejb.bean is actually
> the type safe
> EjbAttribute class can call "Attribute
> getAttribute(..)" method and cast
> it (C# style again).

Agreed in principal. If we add getText/getProperty to
Attribute-interface a trivial client can *always* use
the Strings. A non-trivial client can cast it to the
strongly-type (C#-style) Attribute-class.

> - We can add xdoclet xtags style attributes too,
> later. So you define an
> attributes.xml class, where you define @ejb.bean/etc
> attributes
> according to the dtd, then the serializer app looks
> at the @tags and
> according to dtd validate the @tags user put in the
> code, and finally
> serialize the XmlAttribute class.

Yup. Goes into XRAI too, right?

> Anyway I push the ClassMetaData and Attribute
> classes of xrai. It's more
> flexible than the Nanning approach. Just imagine the
> possibilities of
> this approach:
> - you can serialize them.
> - you can pass the whole metadata/attributes on the
> wire.
> - you can modify attributes at runtime, they are not
> readonly.
> - ...!

Okay, you've got a point. So let's add one more
interface: ClassMetaData/ClassAttributes (I think
ClassAttributes is better because there's a lot of
different MetaData, but we're doing Attributes here).
But we should really try hard to minimize the API

Re modify attributes at runtime. I'm really having
troubles understanding the semantics of this. Does it
update the source-code? I'm opting for read-only
attributes in common-attributes and XRAI may add

> I would like to hear Jon's ideas too. And Aslak's
> too.
> PS: I might sound a bit pushy here, bear with me.
> Trust me; it's based
> on my 2 year experience with @attributes and hearing
> all those
> complaints and struggles of xdoclet users. For
> example supporting
> validation of @tags is *very* important, ppl have
> real struggle with
> tags. The system should help them. That's why I
> don't believe in that
> String-only based approach of getting attribute
> parameters.

Gratis e-mail resten av livet på

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message