[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [tigerstripe-dev] Re: FW: "Set" Interface for Annotations
|
Thanks Andrey,
That sounds good
Cheers,
JohNW
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