Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tigerstripe-dev] TAF update: Avoid Provider conflicts and resolve Annotable Objects ambiguousness

Hi Andrey,

Sorry for the delay in my response. To tell you the truth I have been
staring at your message for a few days and wanted to make sure I had a solid
enough understanding before adding my views :-). I don't think I have, but
here is what I *think* I understand know:

1. Removing "Iannotable" and consolidation of Adapter and Provider
 Ok, this seems to make sense. If I understand correctly the selection from
the UI will be run through the URI get(Object ...) method and will return
multiple URIs to the TAF. I would assume that the "scheme" used in each URI
would make them unique (note that if not, we are in trouble!).

This per say doesn't seem to remove the conflict issue, unless the TAF
considers *ALL* found URIs whereas it used to stop upon first Iannotable
adaptation (based on the order the extension points were registered).

2. Considering we now have a list of potential URIs...
Is that really what you had in mind?

It seems you want to attach information about the type of Object coming into
the TAF from the UI. Consider this example: in Tigerstripe a
IManagedEntityArtifact in the model appears as:
- a IJavaElement when selected from the Explorer (it is the Java Package
- a Iresource when selected from the Resource explorer, e.g.
- a IGraphicalEditPart when selected from a Class Diagram (GMF-based)

Yet, it is multiple representations of the *same* unique
IManagedEntityArtifact in the model. It seems the TAF *cannot* know that,
and it should be the responsibility of the provider-adapter to always
provide a single URI no-matter-what the UI selection presents.

So, maybe I miss understood the very reason why we were running into a
conflict in the first place (if so, my apologies :-() but it seems that TAF
should consider the list of URIs and use the "scheme" maybe to offer the
possible Annotations. Now, I've got the feeling that the Iannotable would
work the same way (i.e. TAF considering a list of Iannotables as opposed to
the first one found). The TAF would then do an "instanceof" based on what
the Annotation were defined to be applicable on.

3. So it seems...
That the solution is to:
- have TAF gather all possible URIs/Iannotables (Iannotable would allow the
client to attach additional references whereas use of URI would require an
additional lookup of the context from the URI)
- decide what Annotations are applicable based on additional info provided
when annotation are defined in Extension Point
- Present to UI only those that are applicable.

Of course, another option would be to have the provider-adapter method URI
getURI(Object..) return null if the object cannot be annotate, and live it
to the client to implement the logic. In fact, the client could perform a
simple "instanceof" but could also perform some more complex behavior (which
is highly likely to happen!).

So for example in the Tigerstripe Cisco use, client would provide:
- One single provider providing URIs/IAnnotable for all UI selections. This
would the client responsibility to "understand" the selection. If not,
return null e.g.
- multiple annotation definitions for the "tigerstripe" URI scheme or the
ITigerstripeAnnotable (which implements/extends Iannotable).
- When a UI selection occurs, the TAF gathers all URIs (the "tigerstripe:"
being part of the list). It builds a list of applicable Annotations
(including those as a result of "tigerstripe:") and present that to the

Hmmm... This seems too simple now... Which means I've probably missed
something. Help!


On 5/19/08 1:53 AM, "Andrey Platov" <andrey@xxxxxxxxx> wrote:

> Hi folks,
> Below is an update on annotation framework. I'm sending update in several
> message to separate problems (since some are well understandable, other may
> require additional discussions).
> During attempts to implement "Everything is EObject" POC, we understand that
> EObject approach do not addresses all the problems, so I'd like to raise
> discussion on best ways to finalize TAF architecture, to keep it simple and
> fulfilling all the requirements at the same time. Let me start from the
> beginning and comment according to past experience.
> Also let me fix terms, when I'm referring to implementations I will use:
> * Current - what we have in HEAD
> * New - attempts to solve existing problems with minimal architecture and API
> changes. This work has been started in CVS MULTIPLY_ANNOTATIONS branch.
> * POC - that's related to some experiments we did past days.
> Problems:
> I. Multiple providers conflict.
> Currently TAF is based on IAnnotable idea (we can annotate anything we can
> adapt to this class). That is bad due to
> A) Potential adapters conflict: "N vendors supply adapters from, say
> IJavaElement to IAnnotable".
> B) Responsibilty shared among AdapterFactory and AnnotationProvider: So one
> contributed stuff (Adapter) responsible to map POJOs to URIs, and another part
> (Provider) responsible for mapping URIs to POJO and everything else.
> This clearly signaling that IAnnotable is not good idea.
> So what we doing both in new implementation and I tried in POC is complete
> removal of IAnnotable and corresponding AdapterFactory.
> Instead we propose following approach (let's stay with URI for a while):
> First change in *new* code: IAnnotable removed, and String getURI(Object pojo)
> method added to the provider. This simple change resolves provider conflict
> problem and consolidate uri mapping code within provider boundaries. This
> change is done in the new code in the MULTIPLY_ANNOTATIONS branch.
> II. Annotable object ambiguousness for selection.
> Let's consider hypothetical situation when N providers claims to take control
> over some POJO. Such situation existence depends on how the framework will
> select provider for a POJO. Let's discuss several approaches to selecting
> provider:
> No-adapt approach: Provider specifies class for which it is registered. TAF
> performs simple instanceof check on a POJO to select provider (No Adapting
> here). 
> Pro: This aproach very likely will not result in any ambiguousness (IResource
> and IJavaElement are different POJOs, so selectin Java file in Java views will
> return JavaElement, other views will return Resource)
> Con: In this case Annotable object selection is UI driven, which is not OK for
> some cases... Sometimes when I see .java resource I may want to annotate it
> keeping corresponding Java class in mind. Following is also very implortant:
> consider I have some special resources or JavaElements (e.g. Tigerstripe
> ones). Java UI do not know anything about my special elements, and will return
> just plain old resources/elements. If we do not employ adaptable => we not
> able to attach annotations to our special elements.
> To eleminate cons, we need to add some intelligence when choosing providers.
> At first stage let's collect all interested providers by adapting POJO
> (selection) to each of provider class of interest. A few approaches possbile
> to select required annotable object among the set of classes to which POJO can
> be adapted:
> A) Explicitly selecting annotable object (either programmatically or with UI).
> If ambiguouse case occured TAF will show all possible annotable objects in UI,
> allowing user to choose correct annotable object.
> B) Adding knowledge to annotation classes: e.g. which Annotation object can be
> attached to which type of elements (uri). For example Stereotype annotation
> can be attached to TSElement only, Hibernate to JavaElement only, but there is
> no sense attaching them to Resource. At same time some licensing/authoring
> metadata may be attached to Resource and visible through dependency graph
> (Java and TS element must be interested to see this authoring data).
> So information about annotable classes to which practicualar annotation can be
> applied looks to be important, and both A & B approaches do not mutually
> exclusive: some POJO can be adapted to completely independent classes and if
> existing annotations do not express their preferences => we may ask user to
> choose correct target).
> (B) will also greatly help with "shorten list annotations type UI requirement"
> - only relevant annotation types will be listed into "Annotations -> Create"
> context menu according to this info.
> Both A & B is simply doable without breaking existing API, just with UI
> improvements and adding "target" attribute to AnnotationType definition, like
>   <extension point="org.eclipse.tigerstripe.annotation.core.annotationType">
>      <definition
>            id="org.eclipse.tigerstripe.annotation.example.person"
>            name="Person"
>            target="org.eclipse.resource.core.IResource"
> ...
> target is an optional attribute, if missed then annotation can be attached to
> any pojo (of course with provider for its type).
> C) This is questionable and we look forward for your comments on this:
> For example 3 providers expressing interest in annotating the pojo: IResource,
> IJavaElement, and ITSElement.
> In reality all these classes are not independent. For example Java
> CompilationUnit or High-level JavaType can't exist without corresponding
> resource. We can see some logical dependency among providers: Resource <-
> JavaElement <- TSElement.
> According to this "logical" inheritance we may want to see following behavior:
> If user query for Annotations of TSElement, annotations for JavaElement and
> Resource shall be returned as well. For example Resource may be annotated with
> Author data, etc.
> Do you think this is reasonable? If it is reasonable we propose to add new
> configuration attribute to provider ("base" or something like that), which
> will be used to specify dependencies between providers.
> Both I and II (A,B,C) changes have minimal impact on the API, at same time it
> resolves some conceptual TAF problems and fulfills some requests best way
> (showing only relevant annotation in the UI/Context Menu). This work has been
> started in MULTIPLY_ANNOTATIONS branch, and we'd be happy to hearing comments
> on proposed/implemented changes. If everything above is OK, we plan to
> finalize this in few days.
> I'll post separate emails on another aspects of the framework.
> Kind Regards,
> Andrey & Yuri
> _______________________________________________
> tigerstripe-dev mailing list
> tigerstripe-dev@xxxxxxxxxxx

Back to the top