Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[tigerstripe-dev] Re: FW: "Set" Interface for Annotations

Hi Eric, John,

Our initial intention to use id for annotation type was to allow several annotation types to be defined with the same EClass (having different label providers, descriptions and so on). If this feature is unnecessary we will remove it in favor of pair <epackage, eclass>. I'll add method for looking up AnnotationType by <epackage, eclass>, which is definitely useful.

As for annotation type name, it's a human-readable name which we show in the GUI because sometimes EClass didn't look user friendly.

--
Yuri Strot

Eric Dillon wrote:
> 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
>      
>
>
> ------ End of Forwarded Message



Back to the top