[tigerstripe-dev] FW: "Set" Interface for Annotations

[Eric Dillon <erdillon@xxxxxxxxx>]

Title: FW: "Set" Interface for Annotations

Hi John,

First of all I’m forwarding to the Dev list, as I think this relevant :-).

Maybe Andrey or Yuri could add a little here... As I have to admit I’m a bit lost, and didn’t take the time to dig as deep as you did in the code..

Eric
------ Forwarded Message
> From: "John Worrell (jworrell)" <jworrell@xxxxxxxxx>
> Date: Thu, 3 Jul 2008 04:40:50 -0700
> To: Eric Dillon <erdillon@xxxxxxxxx>, "Richard Craddock (rcraddoc)" <rcraddoc@xxxxxxxxx>, "Jim Strawn (jistrawn)" <jistrawn@xxxxxxxxx>
> Subject: "Set" Interface for Annotations

hi Eric et al.,

I have been looking at what I need to do to implement the "set" interface for annotations on IModelComponent.

I think the interface I want is:

Object IModelComponent.addAnnotation(String schema, String namespace, String annotationName)
throws NoSuchAnnotationException, IllegalAnnotationTargetException

where the method returns the new annotation content if one was created, and 'null' if one were not because either the unique constraint prevents it (though we could have an exception here also).

Also, a method:
boolean IModelComponent.isAnnotationApplicable(String schema, String namespace, String annotationName)
throws NoSuchAnnotationException
 
which returns true if the annotation can be created and false otherwise.
 
Now there are some problems here...
I would expect to find the information I need to create an annotation in the annotationType extension, and what I have there is:
* name
* epackage-uri
* eclass
* id
 
now which of these do I need to use to identify the annotation? Which does the user have in mind? Seems like too much information and redundancy. I assume that name and eclass (usually the same) are de-coupled to allow name to be changed in the GUI, but then we have the id, which I suppose is the unique id for the annotation-type. The epackage-uri looks a little spooky to use as part of the information to look up the AnnotationType in the AnnotationManager, so I wonder if we should not replace id with 'namespace' and then construct the id from the 'namespace' and 'eclass' name. We can then pass these to the addAnnotation method.
 
I think some caching in the AnnotationManager would be handy as well as a method for looking up the AnnotationType for a given namespace / name(or eclass) pair. The API on AnnotationManager looks to have holes also. I assume I should get all AnnotationTypes as array and then iterate looking for those that match the namespace and name... though it would be better just to get the annotation-types for a specified namespace, and then pull only those annotations. I see myself changing annotation.core.* to address these inconveniences.
 
Any comments?
 
Cheers,
 
JohnW
 

  
    
 
  John  Worrell
Technical  Leader

jworrell@xxxxxxxxx
Phone:  +44 208824 9410
Mobile: +44 7789  922290
 Cisco  Systems Limited
250 Longwater Avenue
Reading
RG2  6GB
United Kingdom
Cisco home  page <http://www.cisco.com/global/UK/>

    
    
   Think before you print.
 This  e-mail may contain confidential and privileged material for the sole  use of the intended recipient. Any review, use, distribution or  disclosure by others is strictly prohibited. If you are not the  intended recipient (or authorized to receive for the recipient),  please contact the sender by reply e-mail and delete all copies of  this message.   
  

 

------ End of Forwarded Message

Attachment: spacer.gif
Description: Binary data

Attachment: footerHead.gif
Description: Binary data

Attachment: green.gif
Description: Binary data

Attachment: footer.gif
Description: Binary data