Re: [concern-users] Best way to approach subject history

[Holger E. <he...@me...>]

Quoting Andy Depue <an...@ma...>:

> What do you think of this proposal?
>=20
> Modify org.concern.Log by adding these methods:
>=20
>   void setAnnotation(String name, String value);
>   String getAnnotation(String name);
>   Iterator iterateAnnotationKeys();
>=20
> And for Hibernate's sake:
>   Map getAnnotations();
>   void setAnnotations(Map annotations);

the map typed setter and getter should be sufficient.

> The same modification will have to be made to org.concern.controller.Lo=
g.  If
> I understand the source properly, the same modification will have to be=
 made
> to org.concern.controller.Archive as well.

right

> Next, modify the hibernate mapping to accommodate the attributes map (n=
ote,
> the reason I'm limiting it to String keys and String values is to simpl=
ify=20
> the Hibernate mapping).

i agree

> Next, add these methods to the Controller:
>   boolean complete(String userValue, String activityName, Map /* <Strin=
g,=20
> String> */ logAnnotations);
>   ? any other suggestions ?

ok

> If we want the ability to annotate a log entry after it has already bee=
n=20
> created, then we will need the ability to uniquely identify a particula=
r log
> entry from the client side - probably by adding the Log's id to=20
> org.concern.Log.

no. one should rather identify the activity / event / listener upon submi=
ssion
of the logs.

> Another thought I had was to add annotations to
> org.concern.controller.Subject=20
> (just like above), and provide methods for accessing those annotations =
(or=20
> the Subject instance) from Activities or client code.  Then, when a Log=
 (and
> later an Archive) is made from the Activity, copy a snapshot of the sub=
ject's
> annotations to the Log.  Client code could then annotate the subject ev=
en=20
> during the course of completing an activity.  For example, if a supervi=
sor=20
> sent a request back to a user for correction, the client UI could promp=
t the
> supervisor to provide a reason for the need to correct the entry and an=
notate
> the subject with that note.  When the subject is later reviewed by the =
user,
> he/she will be able to review the note and correct the subject.  In thi=
s=20
> example, we have a sequence of activities like this:
>=20
>   1. User submits the subject.
>   2. Supervisor reviews the subject and sends it back for correction
>   3. User reviews Supervisor's comments, makes corrections, and resubmi=
ts the
>=20
> subject.
>=20
> Now I'll present the same sequence again, only include details on how=20
> annotations might be handled:
>=20
>   1. User submits the subject.
>     - Client code sets the annotation "user" to the user's id.
>     - The activity completes, and the annotations are copied into the L=
og.=20
>=20
> The Log entry now contains the user id of the user who submitted the
> subject.
>   2. Supervisor reviews the subject and sends it back for correction.
>     - Client code sets the annotation "user" to supervisor's id.
>     - Client code sets the annotation "comments" to the supervisor's
> comments.
>     - The activity completes, and the annotations are copied into the L=
og.=20
>=20
> The Log entry now contains the user id of the supervisor who rejected t=
he=20
> entry and the supervisor's comments.
>   3. User reviews Supervisor's comments, makes corrections, and resubmi=
ts the
> subject.
>     - Client code can retrieve the current annotations for the subject =
(as=20
> they stand now) and see the supervisor's comments, and also who the=20
> supervisor was (via the user id).
>     - Client code can also look through the log and see the history of=20
> activities performed against the subject, including the annotations as =
they
> existed at the time each of those activities completed.
>     - User modifies the subject.
>     - Client code sets the annotation "user" to the user's id.
>     - The activity completes, and the annotations are copied into the L=
og.
>=20
> You get the idea.  Basically, the subject will always contain a "curren=
t"=20
> snapshot of the annotations (much like CVS-HEAD :) ), while the Log wil=
l=20
> contain the history of annotations against the subject.  If a subject h=
ad=20
> been sent back for correction several times, the user could see the=20
> supervisor's comments for every time the supervisor sent the subject ba=
ck for
> correction.  The system also knows which user was involved in each acti=
vity.=20
>=20
> Of course, this is only an example and there are other applications for
> this.
>=20
> Let me know what you think,

i think, i got the idea. but i think, using the subjects as a temporary l=
og
store is not intutive. as i mentioned above, you are actually attaching t=
he
annotations to a subject-activity relation. furthermore the whole control=
ler api
communicates with strings (and collections thereof), making it easily exp=
osable
with soap, .. . the subject class is not visible from outside the control=
ler yet.

i'd prefer the following api:

public interface org.concern.Controller {

boolean complete(String userValue, String activityName, Map /* <String,=20
> String> */ logAnnotations);

boolean notify(String userValue, String eventName, Map /* <String,=20
> String> */ logAnnotations);

// ...
}

public abstract class org.concern.controller.AbstractSynchronousActivity =
{
// and
public abstract class org.concern.controller.AbstractListener {

void addAnnotation(String name, String value);

// ..
}


regards,

holger


-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/