Re: [platform-ui-dev] Activities and Contexts - Important Update

[Chris McLaren <Chris_McLaren@xxxxxxxxxx>]

> On a side note, I noticed that the ability to exclude patterns from 
activity 
> bindings recently went away. This seems like a problem with the way the 
> pattern matching works today. For example, in Javaland, there's a 
"Developing 
> Java" activity that matches to, say, org.eclipse.jdt.ui.*. Now we'd like 
to 
> add an activity, "Developing Java Applets" with a pattern 
> org.eclipse.jdt.ui.applets.*. My understanding is that as long as a 
pattern 
> matches an enabled activity, it will appear. So you can't turn Applets 
off 
> while Java is on. Assuming my understanding is correct, I'd like to see 
the 
> pattern matching work differently. I think the algorithm should be to 
look 
> for the pattern that most closely matches the ID in question and then 
filter 
> based on the state of that activity. This would allow for people to 
provide 
> effective activities at multiple levels of granularity within a 
namespace.

Yes, this was removed. Aside from the explanation that this makes things 
simpler, here's the argument that got rid of exclusion bindings.

Given one defines two activities: 'Java Development' and 'PDE 
Development'. It is well understood that 'PDE Development' requires all of 
the functionality of 'Java Development'.

Conceptually, we have two possible ways to define this relationship:

a) 'Java Development' -> match(org.eclipse.jdt*)
b) 'PDE Development' -> match(org.eclipse.pde*) + match(org.eclipse.jdt*)

OR 

a) 'Java Development' -> match(org.eclipse.jdt*)
b) 'PDE Development' -> 'Java Development' + match(org.eclipse.pde*)

The distinction is subtle, but we want to encourage the latter for two 
reasons:

1. The latter forms a requirement relationship between 'PDE Development' 
and 'Java Development' that the former would have difficulty deriving 
(considering that it would mean math based on regex expressions). Having 
the requirements relationship explicit allows us to easily produce a UI 
which can enforce it upon the user.

2. Trigger points. Say someone is able to select some functionality in the 
domain org.eclipse.jdt.*, like choosing 'New Java Project' from the New 
Project Wizard even though Java Development is not enabled. 

(The design request was such that there are a few places in the UI, called 
'trigger points' which can trigger new activities to become enabled aside 
from the activities UI itself, the ultimate 'trigger point'. Trigger 
points should still give highlighting preference to functionality in 
enabled activities)

In this case, the new functionality matches org.eclipse.jdt.*. How does 
the trigger point know to enabled 'Java Development' and NOT enable 'PDE 
Development'? Currently, we are using the rule that the match must be 
explicit. The latter mechanism allows this.

Now.. on to your question..

Using the latter mechanism, it was felt to be wrong to allow the following 
construct:

a) X -> match(something)
b) Y -> X - match(somethingelse)

(where the '-' indicates an exclusion match).

It produces a requirements relationship where Y 'requires' a superset of 
the functionality of X. Quite strange.

Things are simpler if the matching is additive only.

Also, it encourages people to structure their identifiers along activity 
lines. I realize this is not possible for many existing domains of 
identifiers, but it is always be possible to build entirely from inclusion 
matching. The question becomes 'Is it practical?'

Can you give me an idea of the number of inclusion matching rules that 
would be required for your case?