commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Tirsén <...@tirsen.com>
Subject RE: runtime attributes
Date Tue, 19 Nov 2002 18:58:59 GMT


> -----Original Message-----
> From: aslak.hellesoy@bekk.no [mailto:aslak.hellesoy@bekk.no] 
> Sent: den 19 november 2002 14:56
> To: ara_e_w@yahoo.com
> Cc: mpollack@speakeasy.net; james_strachan@yahoo.co.uk; jon@tirsen.com
> Subject: RE: runtime attributes
> 
> 
>  
> Hi!
> 
> (Sorry for sending HTML mail, I have a lame webmail client for Lotus >
Notes).
> 
> I'm delighted to hear that you have all decided to join forces on
this! I 
> 
> haven't read all messages in detail, but I still have some comments:
> 
> Consider the following @tags:
> 
> /**
>  * @simple we like to program
>  * @complex we="like" to="program" 
>  */
> 
> These are the two "legal" @tag formats in XDoclet/XJavadoc. It's
analog to 
> XML:
> 
> <simple>we like to program</simple>
> <complex we="like" to="program"/>
> 
> The complex format is used more by XDoclet plugins than the simple
format.
> The XJavadoc API supports both formats though.
> 
> Because of this similarity with XML, the XDocleteers say that 'we' and
> 'to' > > are "tag attributes" (aka tag parameters, but attributes is a
better name), just > like in XML. It is not the same as "attributes" in
the .Net terminology. In .Net > terminology you could think of them as
"attribute attributes" ;-).
> 
> The main reason that XDoclet is using tag attributes is to be able to
group
> related data. For example, an EJB might have several @ejb.finder tags,
and it's
> handy to be able to group all data related to one finder in the same
tag, 
> separated as tag attributes.
> 
> The question is: How fine-grained should the commons-attributes API
be? If you 
> specify a tag with tag attributes as above, what would the
commons-attributes 
> API give you?
> 
> I think that it should give back the raw text, and not try to deal
with internal 
> semantics of the @tag content. That should be the responsibility of a
layer that 
> sits on top of commons-attributes (and these layers should not be
maintained by 
> jakarta, but by applications using the commons-attributes API).

Okay, this is basically the Nanning-approach. Commons-attributes is a
low-level API, higher-level APIs are built on top of it. Well, it's okay
with me, but I don't think Ara would agree... This is not really what
we've been discussing so far.

> This way people can define their own @tag semantics. Who knows, maybe
someone 
> wants:
> 
> /**
>  * @foo <hip hop="wont">stop</hip>
>  */
> 
> It should be possible. The commons-attributes API should (the way I
see it) only 
> be an API to access the raw text in @tags at runtime. Then people can
treat that 
> raw text the way they want. XDoclet will parse it into key="value"
pairs.

Regardless of wheather we will build a higher level API or a lower-level
one we must support this. We should not mandate the actual formats of
the raw text.

> Further we need to define:
> 
> o An SPI API (interfaces only) for the attributes compilers
(XDoclet/XJavadoc,
> QDox).
> o A contract that defines attribute inheritance semantics.

Couldn't this also be built on top of the low-level API? If we have a
low-level API we shouldn't be doing any of this either, since it really
is implementable on top of a low-level API.

> o A test suite for the SPIs.
> 
> Aslak
> 
> What are your thoughts on this?

The biggest problem I can see with this is that it will be much harder
to implement runtime-validation. If we can have some kind of pluggable
mechanism to the compiler that might work anyway. But it will be much
less object-oriented. With attribute-objects validation will be much
more natural.

Once, again. We need to agree on this. If we want a low-level API I
think we should use the Nanning-approach which is the simplest possible
low-level API there is. A higher-level API will mandate a lot of things
that all users of such an API may agree with. This will create other
implementations and we still don't have the unified API that we were
looking for in the beginning.

For me, at the moment, I'm leaning more towards a lower-level API that's
open for adding higher-level support in later releases (such as
compile-time validation and so on).


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message