Re: [concern-users] CaseFolder

[Andy D. <an...@ma...>]

There is nothing wrong with the term Subject.  I used "case" simply because in 
my idea I was augmenting the subject with additional information.  I pictured 
a folder with the subject and additional related information contained in it, 
which then seemed more like a case.  The "case folder" contains the subject 
(with additional annotations as well).  I really don't care too much which 
term is used. :)
As for the storing of generic information, I think I would prefer options 1 or 
5.  I'm planning on implementing #5 in my code.  As far as con:cern is 
concerned, my "subject" will be CaseFolder.  My loader will take care of 
"stuffing" the CaseFolder with the actual subject and related annotations.

  - Andy

On Monday 02 May 2005 01:29 am, Holger Engels wrote:
> 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 seem
> 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
> some time now. I can see different approaches and I'm not able to decide,
> which 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. In a script, this could be somthing like "annotations.approved"
> versus "bo.approved". alternatively both could be called with a subject
> map.
>
> 2. named loaders 2
>
> the conditions and activities in process are associated with an aspect. The
> implementations are then called with the respective aspect.
>
> 3. derivation
>
> you could derivate a class <processname>JournalEntry from JournalEntry. So
> 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#comp
>onents-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,
> that the unstructured inforation can be queried along with the business
> object's information, so that you can easily implement filters for dynamic
> worklists.
>
> The advantage of 1 and 5 is, that there is a standard way, how to store
> process relevant information associated to a subject. This is especially
> helpful, if your subject store can not store unstructured information. The
> disadvantage 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
> modifications to the rest of concern.
>
> Regards,
>
>
> Holger