On 2011-12-14 16:13, Behnil wrote:
> Hello,
>
> let's say I have a model plugin containing model classes. Then I have
> two UI plugins. The first one show the model in a table, the second one
> show the model in a list.
>
> How can I add "show model in a list" to the first plugin and "show model
> in a table" to the second plugin??

Simple: Don't do that.

> They should be completely independent, so they can't add itself as dependencies.

Yes, so why doesn't the first and second UI plugin provide the
corresponding "show model in a ..." contribution?

Alternatively your model plugin could provide an extension point that
allows other plugins to contribute a "show model in ..." extension. Both
UI plugins would register correspondingly.

It depends much on how you specify what requirements are imposed on
"show model in ...".

Well, my client needs it. I used Table and List for simplicity, but in fact the first UI plugin visualizes the model in graph and the second UI plugin visualizes model in Table.

> Yes, so why doesn't the first and second UI plugin provide the
> corresponding "show model in a ..." contribution?

I don't understand. Those two plugins are independent each other. But I think its regular requirement from users to see the model in the table and then to open the same model in List (or graph, or something else...).

The situation:

You are looking at a table showing a model. The table is within an dialog which is from UI plugin A.

Now you would like to see this model in graph (or list in this simplified example)

So you, as a user, expect a context menu item "show this model in graph (list)" which would open an dialog with graph (list). This dialog is from UI plugin B.

This one side contribution is easy, because I can create an extension point in UI plugin A and let other plugins (B) to contribute theirs actions. There would be an interface which contributor would implement in theirs contributions. So all plugins contributing to the UI plugin A would be depended on that plugin.

But I also need "show this model in table" in context menu of the graph. The graph (list) is shown in a dialog which is from UI plugin B. And this is problem.
Because I can't create the same extension like in plugin A and let plugin A contribute to it. It would mean the plugin A is depended on plugin B
and it's forbidden to have cycle dependencies.

> Alternatively your model plugin could provide an extension point that
> allows other plugins to contribute a "show model in ..." extension. Both
> UI plugins would register correspondingly.

I think that model plugin should be just a "stupid"" container for model classes. It shouldn't have any UI.

On 2011-12-14 17:32, Behnil wrote:
>> Simple: Don't do that.
>
> Well, my client needs it. I used Table and List for simplicity, but in
> fact the first UI plugin visualizes the model in graph and the second UI
> plugin visualizes model in Table.

I just recognize that I misunderstood the sentence to which I replied
that way. You might have noticed that, because both solutions were
intended to realize what you wanted to do.

>> Yes, so why doesn't the first and second UI plugin provide the
>> corresponding "show model in a ..." contribution?
>
> I don't understand. Those two plugins are independent each other. But I
> think its regular requirement from users to see the model in the table
> and then to open the same model in List (or graph, or something else...).

Well you have not given much context information to us: It was
completely unclear in which way the model plugin would have any
opportunity to provide these "show model in a ..." presentations,
contributions, what ever you meant.

> The situation:

Yeah, would have been great if you would have described the situation in
the first place ;-)

> You are looking at a table showing a model. The table is within an
> dialog which is from UI plugin A. Now you would like to see this model
> in graph (or list in this simplified example)

So UI plugin A has a table with a context menu, and other UI plugins can
extend this - what is the problem with such an approach?

> So you, as a user, expect a context menu item "show this model in graph
> (list)" which would open an dialog with graph (list). This dialog is
> from UI plugin B.
> This one side contribution is easy, because I can create an extension
> point in UI plugin A and let other plugins (B) to contribute theirs
> actions.

Exactly.

> There would be an interface which contributor would implement
> in theirs contributions.

Here the fuzziness factor increases again: What interface are you
talking about? Why isn't it sufficient to depend here on types from the
model plugin?

> So all plugins contributing to the UI plugin A
> would be depended on that plugin.

I would expect that this is the model plugin, so what is the problem? If
it isn't you should move this dependency to a "base UI plugin" that all
real UI plugins depend on.

> But I also need "show this model in table" in context menu of the graph.
> The graph (list) is shown in a dialog which is from UI plugin B. And
> this is problem.

This shouldn't be a problem, if the mystical interface that you
mentioned above is part of the model plugin. If that doesn't work, it
should be part of a very base UI plugin that you need to supply.

> Because I can't create the same extension like in plugin A and let
> plugin A contribute to it. It would mean the plugin A is depended on
> plugin B and it's forbidden to have cycle dependencies.

Not only forbidden, but just plain bad design, because for non-obvious
reasons UI plugin A has some preferences over UI plugin B.

>> Alternatively your model plugin could provide an extension point that
>> allows other plugins to contribute a "show model in ..." extension. Both
>> UI plugins would register correspondingly.
>
> I think that model plugin should be just a "stupid"" container for model
> classes. It shouldn't have any UI.

Well, you didn't really explain what you mean in the first place. I
understood your explanation that the model plugin has the responsibility
to show these texts.

Hi Behnil,
> They are shown unfortunately in dialog. I know the way to contribute to
> menu using the org.eclipse.ui.menu extension point. But this is not the
> situation.

In my understanding this would mean that there is a third UI plugin
which provides the dialog? Let's call this third plugin C. Why don't you
provide an extension point in C which A and B will extend? Then I
wouldn't do so much trouble with popup menus in plugins A and B. No, I
would provide tabs. In each tab one extension is displayed having the
name "table" or "graph" and the respective visualization of your model.

>> You are looking at a table showing a model. The table is within an
>> dialog which is from UI plugin A. Now you would like to see this model
>> in graph (or list in this simplified example)

>> There would be an interface which contributor would implement
>> in theirs contributions.

> Here the fuzziness factor increases again: What interface are you
> talking about? Why isn't it sufficient to depend here on types from the
> model plugin?

Forget about the context menu and the activeMenuSelection variable (which is the way how can I easily
get the table's selection and do with that in another plugin whatever I want).

Imagine you have to work with entire table and not only with one selected row as a model.
And imagine you can't use context menu. Instead there must be buttons at the bottom of the dialog.
The dialog is from UI plugin A. The buttons are the contributions from other plugins,
one of them could be UI plugin B. So one of the buttons would be "Show this model in graph".

I can easily create extension point in the UI plugin A where other plugins contribute for example a JFace Action class.
This Action class then represents the button. The problem with that solution is how can I pass the model representing
the table to this contributed action classes?
There is where the mystical interface come from. I could create it in the UI plugin A

and let contributed plugins to contribute implementation of this interface instead of the JFace Action.
There would be an icon and text element for the button in extension point of course.
This way I can easily create all buttons in the UI plugin A dialog for all contribution and when clicked,
call doWithModel() on them appropriately.

But, this means that all plugins which would like to contribute to the UI plugin A, would have declared direct
dependency on that plugin because they would need to access to the interface.

> In my understanding this would mean that there is a third UI plugin
> which provides the dialog? Let's call this third plugin C. Why don't you
> provide an extension point in C which A and B will extend? Then I
> wouldn't do so much trouble with popup menus in plugins A and B. No, I
> would provide tabs. In each tab one extension is displayed having the
> name "table" or "graph" and the respective visualization of your model.