Tuesday, June 11, 2013

My First Experience with Managed Java Beans in an Xpages Application

In my latest application, I decided early on that I was going to use Managed Beans for my business logic.   Prior to starting I read and listened to everything I could find about them.   I am not going to explain how they work in this post, except to point you in the direction of the resources I used.

I learned about JavaBeans way back when I first started studying Java.   I learned Java by taking three credit classes at Northlake College in Irving, TX.  My instructor worked at IBM and was an excellent teacher.  JavaBeans were basically one chapter towards the end of my studies.  I think Java Server Faces, of which xpages is an implementation of, had just come out.   JSF was only touched on in lecture but was too new for the textbook.

Fast forward to today, I am pretty sure it was a Notes in 9 episode when I first heard about them.   I had already created two xpages applications without using them, so I really wanted to know what is in it for me.

The best resources today that I would recommend to learn to use managed beans is to watch Russ Maher's 2 hour Jumpstart from Connect 2013.   IBM has posted the video here (Thank You IBM!!).   It covers the same material he used in his Notes In 9 episodes in even greater detail.   Another great resource is this youtube presentation on Java for Domino Developers by Paul Calhoun.  It also runs two hours.

My use of Managed Bean is fairly simple at this point.   I use them to hold the data they enter as they click through a data entry wizard.   The data is only stored in the bean until they get to the final step.   I then write the data as a new document.   If the users quits in the middle, then I wipe clean the contents of the bean.  The bean also allows users to go forwards and backwards through the screens and see the data they entered.  Later, if the user edits the existing document, the bean is reloaded and then updates the backend document upon completion.   It can be done but it would be a pain to do all this without using managed beans.

Here is my code.   Like I said, this is pretty simple, but I think would be good to someone just getting started. I make a few comments in red.   I also cut out most of the instance variables to make this shorter.   The scope my bean is using is "session'.

import javax.faces.context.FacesContext; 
import lotus.domino.Database;
import lotus.domino.Document;
import java.io.Serializable;
@SuppressWarnings({"serial"}) 
 **I saw someone else do this to suppress warnings so I copied it,think it must be part of Eclipse**

public class StatusBean implements Serializable {
private String status;
private String typePO;
private String unid;

**These getter's and setters were generated by Eclipse. They are required**

public String getTypePO() {
return typePO;
}
public void setTypePO(String typePO) {
this.typePO = typePO;
}
public String getStatus() {
return status;
}
public void setStatus(String status) {
this.status = status;
}
public void setUnid(String unid) {
this.unid = unid;
}
public String getUnid() {
return unid;
}

public StatusBean(){
                //zero argument constructor 
**You can have other constructors if you want but you must have one like this.**
}

 **This method wipes the contents of the bean, used when cancelling***
public void deleteAllHeaders(){
this.typePO = null;
this.status = null;
this.unid = null;
}

***This method saves the new document and returns the document unique id to the caller***
public String saveNewDocument(){
String unid = "";
try{
*One very long statement below*
Database database = (Database)FacesContext.getCurrentInstance().getApplication()
.getVariableResolver().resolveVariable(FacesContext.getCurrentInstance(), "database");
Document doc = database.createDocument();
doc.replaceItemValue("form", "PO");
doc.replaceItemValue("status", status);
doc.replaceItemValue("typePO", typePO);
doc.save();
unid = doc.getUniversalID().toString();
}
catch(Exception e){
e.printStackTrace();
}
return unid;  //return new UNID to the calling SSJS function
}
}

Even if you don't know Java, I wouldn't call this hard stuff.   It really doesn't read much different than server-side JavaScript.   I haven't written the methods to edit and update existing documents yet, but I don't see that being very complicated.   I have to say I really love this way of coding.  

4 comments:

  1. A good start. I would make a few changes here. For starters remove the @SupressWarning and create what Eclipse suggests to you: a serialID. Each time you modify the class count it one up. This is for the JVM to keep track on serialized objects and their compatibility to classes. Not that important in XPages, but just a habit you should stick to.

    For the saveNewDocument() method I would either provide the database or the document as parameter. Depends a little on your logic. Minimum would be the database - this comes in handy once you decide that your data actually lives in a differnt database than the XPage. It also makes the code shorter since "database" is actually in SSJS. so in SSJS instead of having in a button: myBean.saveNewDocument(); you would have myBean.saveNewDocument(database);

    In this case you need to add doc.recycle();

    Using the document as parameter would then allow you to have one function that serves both for new and updated documents (you probably would call it saveDocument(doc) instead.

    ReplyDelete
  2. Stephan, I hadn't thought it through yet, but yes I do want to separate my design and data in separate NSF's, so I will make the saveNewDocument() method take a database as its argument. Great tip! If I can combine new and edit in the same method then even better. I will have to read-up on serialID's, I am a big believer in following best practices. I just stole @Suppress Warning from an example I saw without knowing too much about how it works. Thanks for the advice, I really appreciate it!

    ReplyDelete
  3. Hi,

    I am in the same position (changing from SSJS to managed beans) so please keep your experiences posted. Much appreciated!

    ReplyDelete
  4. Hello Patrick, thanks for chiming in. I will probably do a Part 2 to this post as I continue to make progress. Your resume has got to be the coolest I ever have seen!

    ReplyDelete