This was an email chain from Jul 2010 timeframe, against NOF 4.0.0. Kevin had the proposed changes, I've assigned to him.
Sounds like those are the right templates then (there hasn't been any updates to em). I'll check it out, but if you reckon there's a bug and you have a fix, then go ahead and commit the changes (somewhere under trunk/distribution, if i remember right).
Sent from my iPhone
On 28 Jul 2010, at 11:28, "Kevin Meyer" <firstname.lastname@example.org> wrote:
> > Hi Dan,
>> >> Yes, the parent should do the work, and the child delegate to it. It's
>> >> called the mutual registration pattern.
> > That is what I understood. I wanted to confirm with you as I was seeing
> > some funny behaviour.
>> >> In your email you talk about the 'template' in the singular, but actually
>> >> there are several templates available (I'm assuming you are using the ones
>> >> I describe in my book?).
> > I'm using the templates I fetched from the NOF
> > "/distribution/tarball/.../ide/eclipse/templates" directory.
> > I should compare them to the ones in your book...
>> >> I don't think that there are any bugs in them; rob says he's been using
>> >> them ok (though I think he trimmed them down a bit).
> > The issue that I have with the 'noc-1m' "1:m parent" association
> > template is that following two lines are the wrong way around?:
> > // associate arg
> > childElementName.setParentPropertyNameInChild(this);
> > getChildCollectionName().add(childElementName);
> > Since, if the child method "setParentPropertyNameInChild(this)"
> > delegates to the parent (e.g. contains
> > "parentObject.addToChildCollectionName(this)") then you've got
> > an infinite recursion taking place - the child item is not yet
> > in the parent collection, when the parent calls the child... :-o
> > AFAIK, There is no equivalent child template ('nocmod' assumes no
> > parent?).
> > Regards,
> > Kevin