PERSON: /
0 identities: /identities -> CMultipleAttribute
1 *PARTY_IDENTITY*: /identities[at1] -> CComplexObject ->
parent: null
2 name: /identities[at1]/name -> CSingleAttribute
I query the objects/attributes of an archetype and print the result.
I get for the object-class PARTY_IDENTITY that it has no parent.
Shouldn't the parent be "identities"
Or do I misunderstand something?
I used the latest source-version of ADL-parser.
Thanks
Bert
Hi Bert,
This is a known issue of the parser, or actually the immutable nature of the AOM classes. The parent attribute can’t be passed into the constructor during parsing of a c_object node since it’s not yet initialized. Adding a function addParent() to CObject will solve this issue but also break the immutability of the CObject class (therefore the whole AOM object tree representing an archetype).
We need to consider if we want to drop the immutability of AOM classes to implement getParent() correctly. Somehow, I feel that getParent() isn’t really useful since if you have a tree of AOM objects and traverse from the root, it’s always easy to get the parent c_attribute of any c_object. In Java, the definition of a class can be obtained during runtime as java.lang.Class and it’s read-only (only getters, no setters) after it’s loaded by the JVM. The same should probably be done for Archetypes. The definition of an archetype represented as tree of AOM objects can be kept read-only after it’s loaded by ADL Parser.
An in-between solution is to keep a flag or just check if the parent attribute has been set for this cobject: if not addParent() can go through, otherwise the method should just returns or thrown an IllegalStateException. So the object can still be immutable after it’s properly initialized.
Any thoughts? Anyone wants to take this task? 
Cheers,
Rong
Rong Chen schreef:
Hi Bert,
This is a known issue of the parser, or actually the immutable nature of the AOM classes. The parent attribute can’t be passed into the constructor during parsing of a c_object node since it’s not yet initialized. Adding a function addParent() to CObject will solve this issue but also break the immutability of the CObject class (therefore the whole AOM object tree representing an archetype).
Thanks Rong, for explaining. It is no problem finding the parent when iterating through the archetype-definition-objects. I just thought, it was an error, but it now seems a design-choice. The good thing about choices is that you have them.
Let me explain my position about this:
What seems to me a good idea is to store archetype-files, the AOM/AP objects in a ORM-layer in a database, for quick access to information, and also for use in template, although, I do not have it completely clear how to, I am working on it:
But it has consequences, the classes cannot be immutable, because for to write a fast and flexible ORM-layer (with or without Hibernate) it is good to have the classes not final (you cannot derive from them, Hibernate discourages final classes, see http://www.hibernate.org/hib_docs/reference/en/html/persistent-classes.html : 4.1.3) , and to have the private properties not final (you need to assign them later in a POJO section, and you need a default constructor, which gives an error when properties are final, because you cannot assign a value after constructing the object).
And, about choices, immutability is good in code, but it is restrictive, and if it is in the way, then I remember, it is a choice, not an obligation.
There is no way to reach my classes on a system then over the interface I offer. In other words, I am deciding which code is deriving from my code, and I am deciding which code is setting properties in my code.
I know this horrifies some Java-developers, but I am not a Java-developer, I am an pragmatical application-builder, and now, I am using Java to do it. I have made some choices, and these are consequences.
regards
Bert Verhees