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