Eclipse Community Forums: Eclipse Platform » Creating own Selection Events? (Converting selected Objects first)

Home » Eclipse Projects » Eclipse Platform » Creating own Selection Events? (Converting selected Objects first)

Creating own Selection Events? (Converting selected Objects first) [message #293032]

Sat, 15 October 2005 20:43

Eclipse User

Originally posted by: bobruney.gmx.net

Hi,

i got pretty specialised objects within each view (for example "TreeBook").
When a user clicks on such an item and selects it, i want to "transform"
the clicked class to another class type first (for example into "Book"),
before i send the selected type (the transformed type) as selection
towards the workspace.

I implemented it with a regular TreeSelectionProvider (View 1) and a
SelectionListener (View 2) at the moment. But all i get in the
"selectionChanged" mehtod in the View 2 are classes of type "TreeBook".

But I need to transform them first before sending, so that "Book" objects
are sent.
I guess the transformation has to be done in View1 but i donŽt know how.

Has anybody a hint how i can do this?
Sorry, but i have found no examples and also looking up the literature i
have here brought no results.

sorry to bother you,
Andreas

Re: Creating own Selection Events? (Converting selected Objects first) [message #293038 is a reply to message #293032]

Sun, 16 October 2005 08:52

Eclipse User

At the my current project we developed a large application UI with Eclipse 3.0 RCP. We have a advanced selection system that connect to selection from one view to multiple others.

Each view that want's to use this system should set it's selection provider (ie. a JFace TableViewer) on the view site (getViewSite().setSelectionProvider(ISelectionProvider)).

Our 'global selection' implementation is loosely coupled between the views, since no view listens to the selection of one explicit view. Instead we listen to a global selection provider that broadcasts selection changes to a registers views.

To convert the elements inside the selection from local (view specific) to global type and vice versa we created the view selection converter interface that can be registered.

In your case it might me the quickest to create a TransformedSelectionProvider that wraps around a selection provider and allows you to set and get a selection with the global type (not the view specific type).

Design of the Software Architecture (best pracitce for Event Handling) [message #293043 is a reply to message #293038]

Sun, 16 October 2005 14:26

Eclipse User

Originally posted by: bobruney.gmx.net

Emil van Galen wrote:

> At the my current project we developed a large application UI with Eclipse
3.0 RCP. We have a advanced selection system that connect to selection from
one view to multiple others.

> Each view that want's to use this system should set it's selection provider
(ie. a JFace TableViewer) on the view site
(getViewSite().setSelectionProvider(ISelectionProvider)).

> Our 'global selection' implementation is loosely coupled between the views,
since no view listens to the selection of one explicit view. Instead we listen
to a global selection provider that broadcasts selection changes to a
registers views.

> To convert the elements inside the selection from local (view specific) to
global type and vice versa we created the view selection converter interface
that can be registered.

> In your case it might me the quickest to create a
TransformedSelectionProvider that wraps around a selection provider and allows
you to set and get a selection with the global type (not the view specific
type).

Emil,

thanks a lot for your answer. The wrapper approach seems like a good idea!

Your project sounds very interesting, we are currently in the early stages
of developing a big RCP, too.

One more thing, you wrote:
> Our 'global selection' implementation is loosely coupled between the views,
> since no view listens to the selection of one explicit view. Instead we
> listen to a global selection provider that broadcasts selection changes to a
> registers views.

I want to implement it in a similar way. I have a central "model" object
to which i want to register all views to listen to "selection" events (MVC
like).
So when a selection happens wihtin one view, the other views should not be
listening to the view selection, instead they should listen to the central
model object, to which the selection within the view is propagated to and
then fired.
In my opinion this is a more modular design, than when i listen to
selection in views directly in other views. I would be glad if you could
provide me with your opinon on that (whehter this is good or not good,
Software Design wise), when you have the time to post.

For my code, this would mean, that i would implement the
"ISelectionProvider" and "SelectionListener" interface in this central
model class.

But now i donŽt know whatŽs the best way to register the views.
Should i register the views as Selection Providers in the workspace (like
you did (judging from the sample code you posted), for "outgoing events".
And then register them as listeners onto the central model for "incoming
events"?

Or should i forget about registerin them at the Workspace and simply
register every view directly with the model?
IŽm a littel bit confused at the moment on what is the cleanes solution to
that.

Maybe you, Emil or somebody else wants to contribute to my thoughts.
IŽm looking for the most appropriate Event Handling Design and donŽt know
whatŽs best at the moment.

Thanks for your input
Andreas

Re: Design of the Software Architecture (best pracitce for Event Handling) [message #293045 is a reply to message #293043]

Sun, 16 October 2005 15:18

Eclipse User

The generic 'global selection' support in our application is developed in two major parts:
<ul>
<li>one part that is a support class of our view part base class; is listeners to:
<ul>
<li>changes in the 'global selection provider'; the incoming selection will be converted to a view specific selection elements (optional) and is set to the selectionProvider of the view site.</li>
<li>changes in the view selection provider that was not triggered by a global selection provider selection change; the view specific selection element types will be converted to global types (optional) and the view selection is used to create a StructuredSelectionChangedEvent (a type we created ourselves). The previous selection of the global selection provider is also used to created the StructuredSelectionChangedEvent. This allows us to see what the changes we between the selection changes. The event we created is then used to update the global selection. One of the issues we tackled was that the view will most often not contain the full selection. For example one view will only contain orders. And if the selection is changed in the orders view the existing selection of the other element types should not be affected in the global selection provider</li>
</ul>
<li>one part that acts as the global selection provider:
this selection provder has no fysical SWT control attached to it and uses IStructedSelection's.
</li>
</ul>
I hope this helps your in make your design.

Re: Design of the Software Architecture (best pracitce for Event Handling) [message #293088 is a reply to message #293045]

Mon, 17 October 2005 20:06

Eclipse User

Originally posted by: bobruney.gmx.net

Emil,

thanks for your answer.
IŽll take some of your ideas/design and incorporate it into my design.

Greetings
Andreas

Previous Topic:	How to create a project outside the workspace?
Next Topic:	How to parse ant build output to detect errors/warnings in build?

Goto Forum:

-=] Back to Top [=-

Current Time: Mon May 12 08:39:36 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter