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

[Andrey Platov <andrey@xxxxxxxxx>]

Hi John,

Original idea of unique IDs, which are *not* derived from namespace/class pair was to add another level of flexibility and use single EMF class as a storage for different Annotation Types: each type has own name/description, label providers etc, while sharing same EMF class for data.

I agree it looks useless and increase complexity without any benefits, so Yuri is going to get rid of IDs in favor of namespace/class pairs as you suggest.

Thank you very much, and
Kind Regards,
Andrey

----- Original Message -----
From: "John Worrell (jworrell)" <jworrell@xxxxxxxxx>
To: "Tigerstripe developers list" <tigerstripe-dev@xxxxxxxxxxx>, "Eric Dillon (erdillon)" <erdillon@xxxxxxxxx>
Sent: Monday, July 7, 2008 6:04:25 PM GMT +06:00 Almaty, Novosibirsk
Subject: RE: [tigerstripe-dev] Re: FW: "Set" Interface for Annotations

Hi Yuri / Eric,

The human readable name certainly makes sense. The idea of a unique ID
makes sense to me: I just think that the unique id should be derived
from epackage and eclass, rather than set independently - does that make
sense?

Cheers,

JohnW

-----Original Message-----
From: tigerstripe-dev-bounces@xxxxxxxxxxx
[mailto:tigerstripe-dev-bounces@xxxxxxxxxxx] On Behalf Of Yuri Strot
Sent: 07 July 2008 10:34
To: Eric Dillon (erdillon)
Cc: Tigerstripe Developers
Subject: [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

_______________________________________________
tigerstripe-dev mailing list
tigerstripe-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tigerstripe-dev
_______________________________________________
tigerstripe-dev mailing list
tigerstripe-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/tigerstripe-dev