Hi I-Chen:

You can actually simplify the cd to:

EventTranslation = <commands> List(Condense).
Condense = "condense" Strategy.

and you show all node and edge events at the strategy level
as in the example below.

The option notation I used below is a little clumsy.
Ignore it. David proposed a better one based on
pattern matching. We can add that later.

-- Karl

==============
Hi I-Chen and Bill:

This is a fun project. We have three faculty members and Doug working with
two students and we make good progress.

I was not aware on Friday of this design improvement that Mira made and which
Bill followed. But it is a very good one.
It is the APPC bean that has all the necessary information to do the filtering.
So your adapter code will now live in the APPC bean directly
and we forget about a separate AdapterBean class.

But all we said on Friday still applies:

You have as input a list of event objects and as output a
list of event objects and you have an event translation language
that defines the event translation.

// simplified cd, no translation of event contents
EventTranslation = <commands> List(ETCommand).
// ET = Event Translation
ETCommand : Condense.
Condense = "condense" Strategy List(ETOption). 
ETOption : AllBeforeNode | AllAfterNode | AllBeforeEdge | AllAfterEdge |
SelectiveBeforeNode | ...
AllBeforeNode = "AllBeforeNode".
AllAfterNode  = "AllAfterNode".
AllBeforeEdge = "AllBeforeEdge".
AllAfterEdge  = "AllAfterEdge".

SelectiveBeforeNode = "selectiveBeforeNode" List(Node).
...
// note: I dropped the "ignore" from Friday


Example:

EventTranslation object:
condense  {A -> D D -> Z}
  AllBeforeNode AllAfterNode AllBeforeEdge AllAfterEdge

Example:
Class graph:
A = B C.
B = D.
C = E F.
D = G.
G = Z.
E = Z.
F = Z.

Object traversed: A-object (there is only one)

Strategy:
S2: A -> D D -> Z

The traversal goes everywhere

Traversal               S2
before A                before A
before ->A,B            before ->A,D
before B
before ->B,D
before D                before D
before ->D,G            before ->D,Z
before G
before ->G,Z
before Z                before Z
after Z                 after Z
after ->G,Z
after G
after ->D,G             after ->D,Z
after D                 after D
after B
before C
...                     ...
after ->A,B             after ->A,D
after A                 after A

The implementation of event translation definitely requires the 
use of the AP library (tg package). Bill has already experience
with this library; please coordinate with Bill.

-- Karl

>From mira@informatik.uni-siegen.de Mon Nov 23 08:42:33 1998
>Subject: Re: Questions
>To: ichenp@ccs.neu.edu
>Date: Mon, 23 Nov 1998 14:41:46 +0100 (MET)
>From: "Mira Mezini" <mira@informatik.uni-siegen.de>
>Cc: generic@ccs.neu.edu
>
>> Dear Prof Mezini,
>>  I have a question about the new pseudo code of APPC-Beans. It seems to
>> me that the method traversalEvent(NodeEventObject nodeEvObj) in
>> APPCBean.java has the same functionality as the one in AdapterBean.java.
>> Why is that so? And actually, I'm not sure why APPCBean needs the method
>> traversalEvent()? I mean, why does it listen to generic traversal events
>> that fired by TraversalBean?
>>  Thanks for your time.
>
>> -IC
>
>You are right, the method traversalEvent(NodeEventObject nodeEvObj) in 
>http://www.ccs.neu.edu/home/bdelaveg/APPC/rev-eng2/Global/APPCBean.java  
>has the same functionality as the one in the class AdapterBean
>as it was in the .pdf file. In the original description, adapter beans
>were put between traversal beans and the appc beans. They expected the
>message traversalEvent(NodeEventObject nodeEvObj) from the
>traversal and sent the appropriate message to the appc beans (based 
>on the information in a mapp object). I started refining the code 
>for traversalEvent(NodeEventObject nodeEvObj) in AdapterBean. During 
>this process, I realized that the adapting functionality can also
>be performed by the APPC beans themselves. That's why I put 
>traversalEvent(NodeEventObject nodeEvObj) in the class APPCBean. 
>That is, in the the new pseudo code there is no AdapterBean class.
>(see http://www.ccs.neu.edu/home/bdelaveg/APPC/rev-eng2/Global/)
>All the responsibilities previously assigned to AdapterBean (which, I 
>believe, you wanted to implement as part of your project) would now 
>be implemented in APPCBean. 
>
>I preferred this design, because I think it would be a bit more
>efficient, since APPCBeans can access directly some information
>for which adapter beans, if implemented as explicit objects, would
>need to send messages to appc beans.
>
>Does that clarifies your confusion? Please let me know.
>
>- Mira
>
>