# getParent() allways null in ArchetypeSlot nodes?

**URL:** https://discourse.openehr.org/t/getparent-allways-null-in-archetypeslot-nodes/13518
**Category:** Reference Implementation: Java (archive)
**Created:** [17 January 2010 05:48 UTC](https://discourse.openehr.org/t/getparent-allways-null-in-archetypeslot-nodes/13518 "2010-01-17T05:48:05Z")
**Posts on this page:** 6
**Page:** 1

<div class="post-metadata">

### Author: ![pablo](https://discourse.openehr.org/user_avatar/discourse.openehr.org/pablo/32/3505_2.png) [@pablo](https://discourse.openehr.org/u/pablo)
#### Post date: [17 January 2010 05:48 UTC](https://discourse.openehr.org/t/getparent-allways-null-in-archetypeslot-nodes/13518/1 "2010-01-17T05:48:05Z")

</div>

Hi,

I’ve a problem with my slots in archetypes, when I do a slot.getParent(), to get the parent CAttribute of this node, I get always null.

Any ideas?

Cheers,  
Pablo Pazos.

---

<div class="post-metadata">

### Author: ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)
#### Post date: [26 January 2010 08:22 UTC](https://discourse.openehr.org/t/getparent-allways-null-in-archetypeslot-nodes/13518/2 "2010-01-26T08:22:20Z")

</div>

Hi again,

Sorry for the delay. The parent attribute is not set in the current  
adl-parser due to immutability of the AOM. But this will change  
quickly. In fact, I am at the moment developing a modifiable AOM  
implementation in relation to openEHR template support. These changes  
will be uploaded to the openEHR repository once they are more  
stabilized and tested.

Cheers,  
Rong

---

<div class="post-metadata">

### Author: ![pablo](https://discourse.openehr.org/user_avatar/discourse.openehr.org/pablo/32/3505_2.png) [@pablo](https://discourse.openehr.org/u/pablo)
#### Post date: [26 January 2010 17:41 UTC](https://discourse.openehr.org/t/getparent-allways-null-in-archetypeslot-nodes/13518/3 "2010-01-26T17:41:22Z")

</div>

Great!

Please let me know when the update is available.

Thank you,  
Pablo.

---

<div class="post-metadata">

### Author: ![Koray\_Atalag](https://discourse.openehr.org/user_avatar/discourse.openehr.org/koray_atalag/32/70_2.png) [@Koray\_Atalag](https://discourse.openehr.org/u/Koray_Atalag)
#### Post date: [26 January 2010 21:43 UTC](https://discourse.openehr.org/t/getparent-allways-null-in-archetypeslot-nodes/13518/4 "2010-01-26T21:43:56Z")

</div>

Hi Rong, I’d be very interested in your approach to solve immutability issue. Could you pls. comment what sort of relationship does that have with templates?

Cheers,

-koray

---

<div class="post-metadata">

### Author: ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)
#### Post date: [9 February 2010 08:23 UTC](https://discourse.openehr.org/t/getparent-allways-null-in-archetypeslot-nodes/13518/5 "2010-02-09T08:23:38Z")

</div>

Hi Koray,

Basically, the current AOM is made modifiable in order to combine  
constraints coming both from archetypes and templates, a procedure  
sometimes known as 'flattening'. The result of that is all definitions  
and constraints are represented in one big 'archetype' structure in  
the form of AOM. The major benefit of doing that is that with some  
small changes, the current archetype (AOM-based) tools/components will  
be able to support openEHR templates.

Cheers,  
Rong

---

<div class="post-metadata">

### Author: ![Koray\_Atalag](https://discourse.openehr.org/user_avatar/discourse.openehr.org/koray_atalag/32/70_2.png) [@Koray\_Atalag](https://discourse.openehr.org/u/Koray_Atalag)
#### Post date: [10 February 2010 00:14 UTC](https://discourse.openehr.org/t/getparent-allways-null-in-archetypeslot-nodes/13518/6 "2010-02-10T00:14:52Z")

</div>

Hi Rong, thanks for that...So can we say that it is sort of "operational archetype"?

My previous message was indeed mostly addressing the "mutability" of the RM classes in Java implementation so that one can add/modify/remove RM objects on the fly to create an "Archetype Instance" conforming to the AOM but ultimately defined by the user input (i.e. multiplicities etc.). I know that Şeref is having difficulties at the moment with this in his implementation. I'd be interested in your and community's views on that.

Cheers,

-koray
