> > /**
> > * @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.
It's easy to support @simple attributes. Just add a getAttributeText
method, like xjavadoc's XTag.getAttributeValue() method. Not a big deal
at all imho.
> > 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?
Well we don't mandate any syntax. Some might prefer @blabla a="a"
syntax, someone might prefer @blabla ("a") or @blabla a("a"). The
runtime api doesn't deal with the syntax. The contract is simple: a
class meta data, with attributes, and attributes have properties, we can
query the attribute and its properties. The syntax is irrelevant.
> > 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).
I don't think we need layer for this simple task! It's just a get/set.
> > 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.
Well then let's see what happens if someone serializes a ClassMetaData
with Nanning, and reads it with an Xdoclet-based runtime api. Assume
Nanning uses a different syntax than xdoclet and we just store the raw
text. Now the Xdoclet runtime reads it and can't understand it! It can
happen quite easily, maybe a third party uses Nanning and not Xdoclet
like you do? So the lowest denominator is getProperty/setProperty and no
raw text, no syntax, just the api.
So we can have different parsers, different syntaxs, but as far as the
api is concerned there's no difference for the user of the api.
> > o An SPI API (interfaces only) for the attributes compilers
> (XDoclet/XJavadoc,
> > QDox).
> > o A contract that defines attribute inheritance semantics.
I think what we already have in xrai is ok. Commons-attributes will have
some test cases for attribute inheritance for example, qdox or xjavadoc
based runtimes will be tested against those test cases.
> > o A test suite for the SPIs.
Yes!
Ara.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
