Push or Pull for selections?

[Marek Jasovsky]

Hi

I would vote for push strategy. (better listener strategy)

2008/8/24, Andreas Pakulat <apaku at gmx.de>:
> Hi,
>
> after comitting the proxy-selection-model last night I couldn't really
> sleep and thought about how to allow plugins to know the selections in
> other plugins. Or rather, they want to know the selections in the
> toolviews and views.
>
> Now I'm a bit undecided wether to use a push or a pull strategy to make
> the information available. The push strategy would mean a new virtual on
> IPlugin and a public method on IPluginController to notify all plugins
> of changes in the selection. So each plugin interested in knowing the
> "last" selection in the GUI would need to re-implement the virtual

what do you mean "last selection" ? My question aims here: do all
plugins, views, everything that can select anything imaginable, have
common interface?

> method and then read the data about the selection (I was going to re-use
> the Context class as it really already has all the needed data).
>
> Pull would mean we provide access to the currently focused view/toolview
> and have a "current selection" method there that retrieves a Context.
> I'm not sure yet how to best map that to the toolview factory though,
> but this might get easier if/when Alexander is finished with his
> shell/sublime re-design.
>
> Thoughts? Comments?
>
> Andreas
>

(Eclipse has ISelectionService interface and rest is implemented
through listeners. plugin interested in selection would register
handler and then the handler could decide, based on type of selected
object (all such objects would then have to implement same interface)
what to do with the selection.

Marek