Description John Arthorne 2001-10-10 22:21:31 EDT

In the popupMenu extension point, actions can have an "enablesFor" attribute
that allows for specification of the enablement criteria of the action.  According
to the doc, there are three choices for the enablesFor value:

- An integer, to specify the exact selection size
- "multiple", to indicate more than one selection
- "!" to indicate no selection

I think an important category that is not possible using these rules is "one or more",
also expressible as "non-empty selection".  I think in the tech preview it allowed you
to say "1+" to say one or more, "2+" to say two or more, etc.  Something like this needs
to be added back, so that this enablement rule is possible.

Also, "!" is not needed, because you can just use integer value "0".

NOTES:

AW (01.03.01 13:11:46)
	Yes, I can image many more important catgories.
<flame on>
	But I think adding more options to the popupMenu extension point is the wrong approach. We should not
	invent a new (albeit small) programming language here! As long as the set of options is not
	Turing equivalent <g> I will always be constrained.

	I want to write Java-code not use an unintuitive data description language that is misused as a (bad) programming language.
	(Do you remember Anythings <g>?).

	Split plugins into two sets of classes. One describes the plugin in Java code (similar to XML) and allows me to
	write arbitrary predicates, the other set is the real (and big) plugin.
	The first set is always loaded, the second only when needed.

	Use the Java-compiler to check configurations instead of our non-checking XML parser! 
<flame off>

DS (3/1/01 10:50:15 AM)
	Kai proposed the same idea to me yesterday.  I agree that the enablement criteria for
	actions is imprecise.  However, we are simply following the plugin story defined by
	core.  Perhaps this will change, but I don't expect it to happen before we release.

DS (3/1/01 10:56:39 AM)
	The doc is actually wrong.  Many more options are supported, as shown in this
	code snippet from SelectionEnabler.  I will update the doc.

	String enablesFor = config.getAttribute(PluginActionBuilder.ATT_ENABLES_FOR);
	if (enablesFor == null)
		enablesFor = "*";
	if (enablesFor.equals("*"))
		mode = ANY_NUMBER;
	else
		if (enablesFor.equals("?"))
			mode = NONE_OR_ONE;
		else
			if (enablesFor.equals("!"))
				mode = NONE;
			else
				if (enablesFor.equals("+"))
					mode = ONE_OR_MORE;
				else
					if (enablesFor.equals("multiple") || enablesFor.equals("2+"))
						mode = MULTIPLE;
					else {
						try {
							mode = Integer.parseInt(enablesFor);
						} catch (NumberFormatException e) {
							mode = UNKNOWN;
						}
					}

JohnA (3/1/01 11:08:43 AM)
	We don't need to specify arbitrary enablement criteria in the XML, the enablesFor
	tag is really just a convenience.  Since ActionDelegates get sent a selectionChanged 
	method when the menu is opened, they can perform arbitrary enablement criteria at 
	that point. I think as long as the enablesFor tag allows for a reasonable set of options, 
	any other special cases can be handled in the selectionChanged method.  It looks like
	the code above handles a pretty good set of criteria, so the doc can just be updated
	to reflect that.  Maybe the doc could also throw in a sentence saying that the
	IActionDelegate.selectionChanged method can be used for more complex enablement
	criteria, so ISV's don't get the impression they are constrained to the set of choices
	available in the XML.

DS (3/1/01 11:48:53 AM)
	Doc updated.

AW (02.03.01 10:05:15)
	Yes, ActionDelegates get sent a selectionChanged message but only after the plugin has been loaded.
	So there is the strange situation where an enablement criteria in the xml file enables an
	action (e.g. because exactly two IResources were selected), then the plugin is loaded and the
	enablement code in the ActionDelegate decides to disable the action because other
	requirements are not met (e.g. both IResources don't implement specific adapters).
	As a result a strange error dialog pops up. Because this happens only when the plugin is not
	loaded it is quite confusing.

KH (3/6/01 5:52:07 AM)

	Moving to feature request.