Hi everyone,
I'm still comming up to speed on the other projects but I thought I'd through my
2cents in anyway coming from the perspective of what is done in attrib4j.
I see different approaches of what the @tag should contain and how it should be
interpreted by doclet processing. One approach would give the raw @tag text at
runtime and probably is very useful to people who are already using xdoclet. The
other mimics what the approach in .NET, that is, the @tag specifies the creation of an
associated attribute class what contains both data/methods. At doclet processing time
in one case the raw text is associated with the annotated class and in the other case
other classes are assoicated with annotated class.
With the raw text available at runtime I suppose that one could create the associated
attribute classes on the fly. Alternatively one could have a 'standard'
TextAttribute/XMLAttribute class which contains the textual data in wrapped inside a
class.
Coming from the xdoclet side I can see how preserving the format of
@simple we like to program
is preferable to
@attribute TextAttribute("we like to program")
but both can achieve the same results.
Anyway, I'll have to mull this over a bit more and I have to run to catch a plane now.
I hope this wasn't too much off base from the direction you guys seem to be headed
in. Either way I'm interested to help out. Maybe some thoughts on the use-cases
would help clarify the approach.
Cheers,
Mark
On 19 Nov 2002,
=?iso-8859-1?Q?Jon_Tirs=E9n?= wrote:
>
>
> > -----Original Message----- From:
> > [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]] Sent: den 19
> > november 2002 14:56 To: [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED];
> > [EMAIL PROTECTED];
> > [EMAIL PROTECTED] 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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
