[ecf-dev] Menu Contribution Conflicts...

["Remy Chi Jian Suen" <remy.suen@xxxxxxxxx>]

Hi everyone,

On this week's call, Scott talked briefly about how one would
contribute directly to a view via its ID without having to set a
Require-Bundle on said view's ID. In the context at hand, it would
allow us to add a 'Send File' action to the MultiRosterView's context
menu via writing the code in a provider's ui.

This looks great on paper but actually presents a flaw in the design
once you "scale up" in the number of supported protocols.

The idea here is that you would subclass CompoundContributionItem,
check the workbench's current selection, and pop it up.

In a scenario in which one protocol supports file transfer and the
other doesn't (like the current scenario of XMPP and MSN, yes, MSN
does support file transfers, I just haven't written the implementation
code), the popup menu will appear in either case even though MSN does
not support this. Thus, the standard sanity check of IRosterEntry
would not work, you would instead have to check its
implementation.This currently would still fail since XMPP actually
just uses the convenient implementation of RosterEntry, so if future
implementors uses it too, that will fail. Worse, if all protocols
supported file transfers, you would get an n number of menu items that
stated 'Send File'!

One alternative to this would be to trash the default implementations
and have everyone write their own and then they can do their own
little check. This would have to be documented so that no one does a
check with IRosterEntry. One issue with this is that implementors that
are not aware of other implementations may all use different strings
for their labels. So what I end up getting is a 'Send File to User'
menu item in an XMPP context menu whereas I might just get a 'Send
File' if I"m trying to send a file to someone on MSN (again this is
unsupported and I am only using it for illustrative purposes).

Regards,
Rem