Date revision: This forum will remain open to new posts and responses until December 1, 2018. (After that date, you will still be able to view and search the forum.) Also, we're taking a second look at the best place to host future conversation. For now, keep using this forum, and stay tuned for more news.

Jan 13, 2015, 5:43 PM
45 Posts
topic has been resolvedResolved

Building an application using Java and Parent Child relationships.

  • Category: Managed Beans in NSF
  • Platform: All
  • Release: All
  • Role: Developer,End User
  • Tags:
  • Replies: 5

One of the main reasons for advocating the use of Java and Managed Beans in XPages is often stated as the ability to have Parent/Child relationships, without reproducing data other than one link field from the Parent to the Child or in other words a One To Many relationship. For many years I have developed traditional Notes applications with Order Forms, Sales Forms etc with line items linked by UniversalID of the Parent displaying them in multiple Embedded Views adding and editing line items by a form as a DialogBox or a full Notes Form e.g. Customer Record and their associated Invoices, yes there are a couple of repeated fields in there (if you don't want to do a look up) like Name and Address but it is no big deal, (I only recently discovered the @getGetDocField Formula Function- how easy is that!). I all works perfectly.

All that said, I do need to move on and I do wish to embrace the possibilities of what Java can bring. So I have spent some time over the last few months studying Java in general, on to subjects like Inheritance, polymorphism, Interfaces etc etc etc, along with scouring the many fragmented Notes resources. I cannot for the life of me find anything on how this relates to the building of Notes applications and the best practices to adopt using anything other than the odd basic CRUD single document examples.

Clearly I am missing some of the basic understanding but if anyone could point me in the right direction on how to construct an application using Java/Managed Beans and highlighting the typical classes, constructors and methods one uses in Java and how they relate to the individual Parent and Child Docs how you access them etc. it would be greatly appreciated.



Jan 14, 2015, 1:00 PM
589 Posts

I'm not sure exactly where to start the discussion.

Improving the Parent/Child relationships in XPages is NOT specific to using Java.  You can get some improvements just by sticking with SSJS.  You mention carrying a couple of repeated fields as being "no big deal".  But in reality it can be depending on how you use it.  You need to have code to keep those in sync etc.  Or do a live lookup like @getDocField -I've never used that one myself - but that won't help you in a view I'm sure.  Just from the form.

So in XPages itself being able to do things like a lookup from anywhere - but especially a view panel control or a repeat control opens up a lot of doors for the "Parent/Child" stuff. 

The other big one is being able to use 2 datasources on a page.  So you can have a viewPanel/RepeatControl on the page with a document so you in effect get the same embedded view with show single category that you had before.  But it's much better because you have so much more control over the UI and hooks to the child document that you just can't get with the Notes client.  I've done several shows on this stuff.  I can't remember then all but I think I did a bunch in NotesIn9 018.  So you might find that interesting.

Now all that has nothing to do with "Java".  

If you're starting out in Java I would ignore for now "Inheritance, polymorphism, and Interfaces".  It's not needed yet.  Here's what I might typically do.

I'll create a class called "Company".  That will load in all the values from the document.  Then I forget the document.  I don't care.  When I go to save it I reload the document and save all the current values of the object/bean back to the document.  Done.


I'll also create a class called "Contact".  It'll do the same thing as company.  It'll load from a "Contact document" and also save back to the contact document.  There will be a method like:

load(String uniqueKey) {]


do from the Company object I'll have a method like:


inside there I'll get a handle on the view..  create a collection of the contacts with the shared key...  you might use UNID's I prefer @Unique()'s.  I loop thought the collection and do something on the loop like:

Contact tmpContact = new Contact();

tmpContact.load(this.uniqueKey)  // this refers to the current company object



So in company I'll have declared:

List<Contact> contactList;


In the constructor I might have:

this.contactList = new ArrayList<Contact>();


in there will be a method in the company like:

public List<Contact> getContacts() {

    return this.contactList;



so from an XPage that is being bound to the company object I can throw in a repeat control to show all the contacts by using something like:

Company.getContacts() in the javaScript of the repeat control.  Or I could use EL as well of course.

So this is how I'm using Java in a lot of apps.  It's allowed me to make a "Business API" of my key objects.  Starting that is more important then trying to get all the Java right from a "Purist Java Developer" point of view.  Because now you can easily add new methods:











etc....  It'll just grow and grow and it's all reusable code that keeps getting better because you don't need to keep reinventing the wheel.  


A little bit ago I started a series on designed as an intro to Java for XPages developers.  It's a build an app from scratch.  I've NOT finished it yet...  hope to start up soon.  I don't think I got to any parent child stuff yet... hopefully soon... but it might be interesting to you.


Let me know if you have further questions.  Either here or email me.  My address is on every video.


Good Luck!


Jan 14, 2015, 1:00 PM
589 Posts

ignore.  I messed this up



Jan 14, 2015, 3:42 PM
45 Posts
Building an application using Java and Parent Child relationships

Perfect David, absolutely perfect.

I am well versed with the XPages and multiple data sources advantages etc, I have used them to good effect already, but I could not get my head round the basic principles of how Java objects would relate to the parent and child scenario. I think the key element I was missing being the creation of an array of Child objects from a Child class and then using that array  in repeats etc. As you suggest I have got bogged down with some of the 'purist theory'.

Yes, I have been eagerly awaiting the next installment on your series and hoping you covered this topic, but couldn't wait any longer hence this post.

Congrats on your 300,000 downloads on a fantastic achievement and a fantastic resource.

Many thanks



Jan 14, 2015, 4:39 PM
589 Posts


Thanks for the kind comments.  I do appreciate that!

Glad I could help bridge the gap a bit.  Basing your code on Java is a different way to think but I really enjoy it.  It can solve a lot of problems and speeds things up I find.


I'm hoping to get back to NotesIn9 stuff soon.  I had some issues to deal with un November and then the Holidays hit but I'm hoping to get going again very soon.  


Jan 20, 2015, 11:55 AM
453 Posts
Agree with David the Parent/Child thing is not a JAVA issue

I agree with David's point the Parent/Child thing is not related to JAVA. In fact I have been using @Unique for years, even in Native Notes, to maintain relationships because the UNID can change and destroy everything. In native notes I would embed a single category view based on the LinkKey in the parent to get the children. While this worked well it's use was limited. Once in XPages the landscape opened up immeasurably especially with repeat controls (IMHO). I have built a couple JAVA Classes and am far from a JAVA expert, but they have opened several new directions for me. 

I agree with you on the issue of documentation on JAVA in XPages. There are a few video sessions out there (see NotesIn9 and others) and a lot of Blogs etc. but the search for relevant information can be frustrating and very time consuming. The Mastering books are good starts.  

Date revision: This forum will remain open to new posts and responses until December 1, 2018. (After that date, you will still be able to view and search the forum.) Also, we're taking a second look at the best place to host future conversation. For now, keep using this forum, and stay tuned for more news.