[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Menu Contribution Conflicts...

A little more time now to make another comment

Scott Lewis wrote:
Remy Chi Jian Suen wrote:


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'!

Here's what I do as a sanity check with the Skype ui contribution (in SkypeActionContributionItems)...I'm not saying this is the best/only approach, but it does work.


if (selectedModel != null && selectedModel instanceof IRosterEntry) {
IRosterEntry rosterEntry = (IRosterEntry) selectedModel;
IContainer container = (IContainer) rosterEntry.getRoster()
.getPresenceContainerAdapter().getAdapter(IContainer.class);
IAction[] actions = new IAction[1];
// Here's what limits it to adding menu entries only for Skype
// this is kind of ugly though...admittedly
if (container instanceof SkypeContainer) {
actions[0] = new SkypeCallAction(
....fill out action


The tricky bits here are the 'if (container instanceof SkypeContainer)'. Although this works fine, it would be better to have alternatives.

One more thought about this.


I've sort of been anticipating (but not yet implementing) that we could produce an abstract super class of CompoundContributionItem to help out with this...e.g.

(in org.eclipse.ecf.presence.ui plugin)

public abstract RosterEntryContributionItem extends CompoundContributionItem {

protected Object getSelection() {
...appropriate code here to get the currently selected model object...e.g. IRosterEntry
}


protected IRosterEntry getSelectedRosterEntry() {
return (IRosterEntry) getSelection();
}
protected IContainer getSelectedContainer(IRosterEntry entry) {
if (entry == null) return null;
IPresenceContainerAdapter pca = (IPresenceContainerAdapter) entry
.getRoster().getPresenceContainerAdapter();
if (pca != null)
return (IContainer) pca.getAdapter(IContainer.class);
return null;
}
}


and then subclasses of RosterEntryContributionItem could use these methods like this for the menu contribution 'sanity check'

IRosterEntry entry = getSelectedEntry();
if (entry != null) {
   IContainer container = getSelectedContainer(entry);
   if (container != null && container instanceof SkypeContainer) {
        ...we create and return contribution items
   }
}
//else we return no contribution to menu

So then we people were creating menu contributions that are for the roster view, they could simply use the getSelectedEntry() and getSelectedContainer() methods from super class to save them the extra work of getting the selected object, checking to see whether it's an IRosterEntry, getting the IContainer for that entry, etc.

If this seems reasonable we could add a super class to org.eclipse.ecf.presence.ui.

Scott