TeamSpace
Quality vs. quantity Microphone
Home Who We Are What We Do What We've Done Why Work For Us Blog Contact Us

My Managed Bean Conundrum - Part 2

Bob Laing - April 22 2013 10:00:00 AM


Continuing on from Part 1 in this series it is now enough of copying someone else's code -- it's time to write my own code.  I'm going to create a bean called AppUtils - the purpose will be store code that will be portable to other databases/applications and provide generic methods to access and retrieve data from Domino objects (typically documents).  To create this bean I'll follow much the same process as when creating the SystemUtils bean.  From Designer under Code and then Java I click New Java Class and fill in the Package of com.teamspace.ca and the Name of AppUtils and then click Finish.  This creates an empty Java class as in the following screen shot:

Image:My Managed Bean Conundrum - Part 2

The next step is to make the bean serializable.  This means the bean can have persistence, or able to store information to be retrieved at a later point.  To enable serialization, add the text "implements Serializable" after public class Apputils as in the following screen shot:

Image:My Managed Bean Conundrum - Part 2

Notice the red x on the left side.  Click once on that and you'll see an explanation of the error and suggestion on how to resolve.

Image:My Managed Bean Conundrum - Part 2

Double click on Import 'Serializable' (java.io).  This will add an import statement at the top of the bean which imports the Serializable Java Class into this bean.  This will eliminate the hard error that will prevent the  bean from being saved, but now you'll see a yellow warning.  If you click once on this you'll be prompted to Add generated serial version ID.  This is a long unique id number which helps keeps track of version of the bean.

Image:My Managed Bean Conundrum - Part 2

Double click the Add generated serial version ID which will add a long variable with a unique value.  Next we're going to add a constructor.  A constructor has a solitary purpose and that is to create an instance of a class.  Add the code highlighted in the following screenshot.

Image:My Managed Bean Conundrum - Part 2

Now we're done with the preliminary stuff and ready to write some code.  The method I started with for my bean will take as input a lookup value, a lookup view and a field name.  The method will lookup the value in the first column of the view and return the field value from the first document that matches the lookup value.  Copy the following code (not including the line numbers) into the bean after the public AppUtils() {} and I'll explain what it does.

1        public static Vector<String> getKeywordList(String kwCategory, String kwView, String kwField) {
2                Vector<String> kwList = new Vector<String>();
3                try {
4                        Database curDb = SystemUtils.getDb();
5                        if (curDb.isOpen()) {
6                                View kwLookupView = curDb.getView(kwView);
7                                if (null != kwLookupView) {
8                                        Vector<String> v = new Vector<String>();
9                                        v.addElement(kwCategory);
10                                        Document doc = kwLookupView.getDocumentByKey(v, true);
11                                        if (null != doc) {
12                                                kwList = doc.getItemValue(kwField);
13                                        }
14                                }
15                        }
16
17                } catch (NotesException e) {
18                        e.printStackTrace();
19                }
20                return kwList;
21        }


Line 1 identifies the method name which is getKeywordList.  This method is public, which means it is visible outside of this class and it is static which means the method can be called directly.  The method receives three parameters:  kwCategory, kwView and kwField.  All three parameters are identified as String variables.

Line 2 identifies the Vector which will hold the values that will be returned from the method.  A Vector is a Java object that can hold multiple values.  A Vector in this case will return the values contained in a multi-value field in a  Domino document.  The type of the Vector needs to be identified, in this case the Vector will hold values.

Line 3 starts the standard Java try/catch block.  Java tries code, and if it fails for any reason, the processing falls to the catch statement which can take whatever action is necessary.  In this case the catch will print the error message to the console(line 18)

Line 4 uses the SystemUtils bean to get the current database object.  This database object contains the same properties that a database object would contain in Lotusscript

Line 5 checks to verify the database object is valid and open -- looks just like Lotusscript doesn't it ?

Line 6 and 7 get a view object from the current database and checks to see if the view object exists.  The view is obtained using the kwView parameter that was passed to the method.

Line 8 declares a new vector that will be used as the lookup key to get a document in the view.  Line 9 adds the kwCategory value to the vector.

Line 10 and 11 get a document using getDocumentByKey and verify that a document was found.

Line 12 gets the value contained in the kwField and stores it in the kwList vector.  This vector will then be returned from this method in line 20.

I've been coding Java agents in Domino for years so my perspective may be a littie warped, but I see very little in this method that differs from Lotusscript.  The syntax is a little different, but the Domino objects are the same regardless what language is manipulating them.

To see this bean in action, I've created a simple XPage that returns the value retrieved to a combobox control.  That code follows:

<xp:label
      value="getKeywordList Test(Platform KW): "
      id="label3"
      for="comboBox1">
</xp:label>

<xp:comboBox
      id="comboBox1">
      <xp:selectItem
              itemLabel="Select"
              itemValue="Select">
      </xp:selectItem>
      <xp:selectItems>
              <xp:this.value><![CDATA[#{javascript:getAppUtils.getKeywordList("STATUS", "KeywordsLU", "value");}]]></xp:this.value>
      </xp:selectItems>
</xp:comboBox>


In the comboBox, the following code  javascript:getAppUtils.getKeywordList("STATUS", "KeywordsLU", "value"); calls the method getKeywordList and passes as parameters "STATUS" which serves as the lookup key in the "KeywordsLU" view which then gets the matching document and returns the contents of the "value" field in the document.  This then results in the comboBox looking like this:

Image:My Managed Bean Conundrum - Part 2

So all is good right ?  I have a bean, and I can use it in an XPage to retrieve the values I want.  What's the conundrum ???  I was doing some searching and reading on managed beans and I saw a post that mentioned that managed beans contain getters and setters(which my bean does not) and if there are no getters and setters then the managed bean actually is just a plain old Java method.  So do I have a managed bean here or do I just have a Java object ?  I'm really not sure - weigh in if you have an opinion…