Re: [concern-users] CaseFolder

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

Hi andy,

first of all:

o con:cern does not address this issue yet
o of course, it's not a bad idea

then some questions about the terminology used in concern, because you se=
em to
prefer the term case over subject:

o is subject (as a short form of subject matter) a good term?
o is modeller a good term?
o are there any other strange terms in con:cern?

I'm thinking about a store for generic information with the subject for s=
ome
time now. I can see different approaches and I'm not able to decide, whic=
h on
suites best. Maybe you can help me ..

1. named loaders

a process can have several named loaders in parallel that load different =
aspects
of the subject. a condition then should refer to the respective aspect. I=
n a
script, this could be somthing like "annotations.approved" versus "bo.app=
roved".
alternatively both could be called with a subject map.

2. named loaders 2

the conditions and activities in process are associated with an aspect. T=
he
implementations are then called with the respective aspect.

3. derivation

you could derivate a class <processname>JournalEntry from JournalEntry. S=
o you
would address the issue with hibernate's capabilities.

4. dynamic components

another hibernate only solution:

http://www.hibernate.org/hib_docs/v3/reference/en/html/components.html#co=
mponents-dynamic

5. loader based solution

as you described or somewhow similar.

3 and 4 assumes, that every reasonable subject store provides some means =
to
store unstructured information with business objects. The advantage is, t=
hat the
unstructured inforation can be queried along with the business object's
information, so that you can easily implement filters for dynamic worklis=
ts.

The advantage of 1 and 5 is, that there is a standard way, how to store p=
rocess
relevant information associated to a subject. This is especially helpful,=
 if
your subject store can not store unstructured information. The disadvanta=
ge is,
that different parts of the process relevant information will have to be =
handled
differently (maybe inefficiently) by dynamic worklists.

Approach 5 can be implemented as an intelligent loader without any modifi=
cations
to the rest of concern.

Regards,


Holger


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

> As I look into using con:cern with our product, I'm tempted to employ a=
n idea
> and thought I'd bounce it off others to see if it makes sense.  A "case=
" can
> sometimes have state that you really don't want to infect your object m=
odel
> (subject) with.  For example, say you have a JournalEntry class in your=
=20
> object model (and, of course, use Hibernate for ORM :)  A user submits =
a=20
> JournalEntry, which then must be approved by an accountant and a manage=
r. =20
> The JournalEntry enters into a process as the subject of the case.  If =
the=20
> JournalEntry is NOT approved, then the accountant/manager rejecting the=
 entry
>=20
> can send it back to the user for correction, along with a note.  OK, so=
 I=20
> might be willing to let the approval and other flags be in my actual=20
> JournalEntry (isApproved(), etc).  But I really don't want the correcti=
on=20
> note sent from the accountant/manager to the user to be in the JournalE=
ntry.=20
>=20
> So, I'm thinking of creating a "CaseFolder" class that looks something =
like
>=20
> this (as an example):
>=20
> interface CaseFolder
> {
>   Object getSubject();
>   Object getAnnotation(String key);
>   void setAnnotation(String key, Object value);
> }
>=20
> Basically, this wraps the actual subject and allows "annotations" to be=
=20
> inserted into the folder along with the subject of the case.  An annota=
tion
>=20
> is just a generic property, really, and is used to pass around informat=
ion=20
> related to the case/subject that is not a part of the actual case/subje=
ct=20
> (such as the rejection note).  The process model would then be built ar=
ound
>=20
> the CaseFolder instead of the JournalEntry directly.  My "Approved" con=
dition
>=20
> in the process model would go from:
>=20
> public boolean eval(JournalEntry subject)
> {
>   return subject.isApproved();
> }
>=20
> to:
>=20
> public boolean eval(CaseFolder subject)
> {
>   return ((JournalEntry)subject.getSubject()).isApproved();
> }
>=20
> Or, if I decide that I don't want the approve flag stored in my object
> model:
>=20
> public boolean eval(CaseFolder subject)
> {
>   return subject.getAnnotation(KEY_APPROVED) =3D=3D Boolean.TRUE;
> }
>=20
> The client could access the rejection note like this:
> String rejectionNote =3D
> (String)caseFolder.getAnnotation(KEY_REJECTION_NOTE);
>=20
> My "Loader" implementation would return instances of this CaseFolder st=
uffed
>=20
> with the JournalEntry instead of the JournalEntry directly and would al=
so=20
> handle persisting the annotations along with any changes to the
> JournalEntry.
>=20
> Does con:cern already address this issue?  Is this a bad idea?
>=20
> Thanks,
>   Andy
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great events=
, 4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=3D20
> _______________________________________________
> concern-users mailing list
> con...@li...
> https://lists.sourceforge.net/lists/listinfo/concern-users
>=20
>=20


Holger Engels
(Dipl Inf Med)

--
Consultant, Architect, Developer
Mobile: +49 176 20119752


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