Jim Alateras wrote:
>
>>>
>>> Question 1
>>> ==========
>>>
>>> I use The following code fragment to create an object from an archetype
>>>
>>> rmobj = archetype.buildRMObject(valueMap, errorMap, sysmap());
>>>
>>> One of my constraints for this archetype is optional, as shown below
>>>
>>> ELEMENT[at0004] occurrences matches {0..1} matches {
>>> value matches {
>>> DVTEXT matches {
>>> value matches {/.+/}
>>> }
>>> }
>>>
>>> In the valueMap I don't supply a value for this element and therefore
>>> it is not created. The 'rmobj' instance is created as expected.
>>>
>>> At some later stage, I want to record a value against
>>> ELEMENT[at0004]. Do I need to manipulate the 'rmobj directly as shown
>>> below
>>>
>>> Account account = (Account)rmobj;
>>> Element element = new Element("isDebitAccount",
>>> new DvText("isDebitAccount"), isDebitAccount);
>>> account.getDetails().items().add(element);
>>
>>
>>
>> You can manipulate the in-memory object as you normally do in
>> non-archetype based software. But by doing that you take the risk to
>> leave logic specific to certain archetypes in your code, which would
>> break the constraints with the archetype if e.g the details is changed
>> in new definition of the archetype. The result is that your software
>> can't be as much adaptive as it could be with dependency to certain
>> archetype.
>>
>>>
>>> or can I create it using a path expression?
>>
>>
>>
>> Such feature doesn't exist now.
>>
>> Instead of modify the object directly, you should perhaps create a new
>> one instead by using archetype.buildRMObject(). The reasons are:
>> 1, you don't want to have any specific knowledge of details of certain
>> archetypes.
>> 2, since the high level objects, Composition, Party, EHR etc, are
>> always versioned, you can always create new ones instead of
>> overwriting the old ones.
>>
>
> Rong,
>
> Just want to discuss this a bit further. From programming perspective
> would you work with valueMap objects (where the key is a path) and only
> create an instance of an information model object, from an archetype,
> when you have collected all the required information?
Yes, this is exactly the way what I would like to improve the current
object creation logic of the kernel. Using path, more specifically
runtime path, as the key is probably more sensible way to organize input
values. The key benefit is that it will allow more than one data node to
be created on one archetype node (e.g. CMultipleAttribute).
>
> Alternatively, if you are performance sensitive do you work with the
> information model and use archetype for validation (i.e. validate the
> model against the constraints).
Suppose archetypes are classes in java and rim objects are java objects
instances created by java classes (as they always are), rim objects
should comply with the constraints in archetypes just the same as java
objects are always valid according to java class definitions since it is
reinforced by the java runtime environment. We perhaps can achieve this
with kernel by only allowing rim objects to be created by archetypes
directly, then there is no need to validate rim objects against archetypes.
On the other hand, if one would like to validate input data without
creating any rim objects, it is possible to perform on raw data (non-rim
objects) on the leaf constraints level where the constraints are mostly
about data range of primitive data types.
For other type of validation, which usually involves large objects and
their internal structures (defined by archetypes), I am not sure it
worth the risk of coupling to archetypes for better performance (object
creation in memory is pretty fast anyway).
>
> [Apologies, if I haven't quite grasped the core concepts to building
> applications using archetypes]
No problem, we are all exploring :)
Would be interesting to see other's view on this...
Rong
>
> cheers
> </jima>
>
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org
