Re: [platform-ui-dev] Clarifying activities in 3.0

[Chris McLaren <Chris_McLaren@xxxxxxxxxx>]

Jim is referring to two documents I
recently wrote to help clarify Activities and Contexts. They have been
posted on the platform-ui development page. 


1. Personally, I believe that *whenever
possible, activities should be defined by plugins and not the product manager*,
for the following reasons:

a. Activities describe their functionality
by matching to particular identifiers. Identifiers are strings whose format
is completely domain specific. I expect it will be a difficult task for
a product manager to come along after the fact and unwind the details in
each plugin.

b. Third party plugins come along after
the product manager,  yet there is no reason that these plugins shouldn't
participate in activities, either by defining new activities or defining
pattern bindings to other well known activities in dependent plugins.

c. One type of anchor (or 'trigger point',
or 'place where activities can be enabled or disabled', etc.) might be
a command to toggle a particular activity. For instance, perhaps the 'working
with cvs' activity, which would bring in all the cvs support, might benefit
from having a command (and key binding) to quickly toggle this specific
activity on and off without going to the activities UI. As it toggles on
and off, menu and toolbar items related to cvs would appear and disappear,
etc. You can't do this type of thing unless you know the activity's identifier.

d. Furthermore, other plugins dependent
on your plugin might also want to take advantage of using the java api
to react to activity changes related to activities defined in your plugin.

It so happens that in the eclipse sdk
we have enough domain knowledge of all of our plugins, including a fairly
standard syntax for identifiers and a short walk or phone call away from
all the plugin owners, that it is possible for us to pull off defining
these at the product level to get all the free filtering by the workbench
(views, commands, perspectives, etc.). This makes it easy to get up and
running quickly without asking the owners of the 80-odd plugins to make
changes to their plugin.xml files on our behalf. But, if any plugin wants
to work with custom anchors, or otherwise make use of the Java API to react
to changes in particular activities, they assume an implicit dependency
on the plugin defining these activities. At this point, we would try to
coordinate as a product to push down the definitions of activities to our
plugins to eliminate these dependencies.


2. If the example is compelling enough,
JDT itself perhaps could partition Java Development into 'Basic Java Development'
and 'Advanced Java Development' and have the latter require the former.
This specific example has come up in previous discussions I've had when
thinking about J2EE vs. J2SE.


3. Contexts have identifiers. Therefore
they can be filtered by activity just like any other type of object with
an identifier. To do this, an activity's pattern binding should include
a pattern matching the context's identifier. (In M6, contexts, which you
can see in the keys preference page, are not being filtered by activity.)


Chris.

"Jim D'Anjou" <danjou@xxxxxxxxxx>
Sent by: platform-ui-dev-admin@xxxxxxxxxxx

01/14/04 07:55 PM

Please respond to
platform-ui-dev

To	platform-ui-dev@xxxxxxxxxxx
cc
Subject	Re: [platform-ui-dev] Clarifying activities in 3.0

Having read the recently updated Activities and Contexts
documents and the numerous entries in this mailing list, I have some questions
and comments.

1. Regarding the intent for the product manager to define activities, does
that not assume that the product is more/less static and won't be enrichened
with other features perhaps from other providers? For example, if I add
some spiffy modeling tool feature to the eclipse platform shouldn't the
owner of that feature be encouraged to define activities (and categories)
relevant to that feature (this is identical to the earlier question on
JDT and PDE). In the eclipse world the client's product is often the aggregate
of features from mulitiple providers. Another variant is the case when
product consumes the function of another and adds more stuff (the IBM WebSphere
Studio Russian doll model).

2. How do I filter out subsets of function? Imagine that I want to simplify
the JDT for Java students (I encounter this all the time when I visit universities
incorporating Eclipse into their curriculum). I want a category called
"Java Student" and I want a simplified perspective and a simplified
set of actions (incidentally, can I filter programmatically created actions
that were not created through an extension point. They are not "identifiable".)
. It is not clear how I might define a pattern that subtracts function
or create a pattern with very specific function (I assume it has something
to do with the local identifier but the syntax and overall construction
is not understood). I am sure this can be done I just don't understand
some of the syntatical details.

3. It was stated that Context definitions can be filtered by activity.
How is that done? XML or Java API or both? The mailing list also indicates
that this may no longer be true so perhaps the question is not relevant
anymore.

4. I share the comment by Ed Burnette as I am in a similar role of trying
to explain this stuff to others.

Jim