Re: [ecf-dev] Menu Contribution Conflicts...

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

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