> -----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]>
