[
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