This forum is closed to new posts and responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:

HCL Software Customer Support Portal for U.S. Federal Government clients
HCL Software Customer Support Portal



Apr 15, 2014, 6:34 PM
178 Posts

Some basic examples performing CRUD operations using java and managed bean(s)

  • Category: Other
  • Platform: All
  • Release: 9.0.1
  • Role: Developer
  • Tags: managed eban,java,crud
  • Replies: 8

hi, can anyone provide some basic examples about performing CRUD examples using managed beans and java? or does anyone know an example db to look into?

Apr 15, 2014, 9:16 PM
366 Posts
Can I ask the scope of the request?

I see a bunch of folks requesting this lately and not really know why, except that they have seen/heard that this is a good Idea from the community.

The reason I ask is if you go this route you are duplicating what XPages does.  The XPage itself is compiled into a Java class that in essence becomes the pages "managed bean" for the fields bound to a document data source.

Unless you are using some OTHER data source besides domino documents (Like a RDBMS) then you are re-creating the wheel.

 

http://xpagetips.blogspot.com has several slide decks and example code on managed beans. 

Apr 16, 2014, 8:39 AM
178 Posts
the why - learning java and where to use it

hi Paul,

the request is to basically understand how and where to use java. also to store some of my business logic in a more central place.

I found some samples how to laod data from a document into a bean, but not how to save data from a bean into a document.

 

Apr 16, 2014, 10:26 AM
178 Posts
example

e.g an example how to load info from a document:

package com.proj.test;
 
import java.io.Serializable;
import lotus.domino.Database;
import lotus.domino.Document;
import lotus.domino.NotesException;
import lotus.domino.View;
import com.ibm.xsp.extlib.util.ExtLibUtil;
 
public class Config implements Serializable {
    private static final long serialVersionUID = 1L;    
    private String prefLegal;   
    private Integer numViewRows;    
    private String documentId;
 
/**********************
* Constructor        *
**********************/  
    public Config() throws NotesException {
    try {
loadConfigurationDocument();
 
} catch (Exception e) {
e.printStackTrace();
}  
    }
   
    /**********************
* Methods            *
**********************/
    public void loadConfigurationDocument() throws NotesException{
try {
System.out.println("finding Configuration document");
System.out.println("finding Configuration document");
Database db = ExtLibUtil.getCurrentSession().getCurrentDatabase();
View view = db.getView("$v-preferences");
Document doc = view.getFirstDocument();
if (null != doc) {
System.out.println("loading Configuration document");
this.setDocumentId(doc.getUniversalID());
System.out.println("id Configuration document:" + this.getDocumentId());
prefLegal = doc.getItemValueString("prefLegal");
   // ... read all other items and store them in private fields
   numViewRows = doc.getItemValueInteger("prefDefaultNumOfRows");    
   System.out.print("closing Configuration document");
doc.recycle();
}else{
// add some error logging?
System.out.println("problem finding Configuration document()");
}
view.recycle();
 
} catch (NotesException e) {
e.printStackTrace();
}
}
    
    /***********************
* Getters and Setters *
***********************/
    public void setDocumentId(String documentId) {
this.documentId = documentId;
}
public String getDocumentId() {
return documentId;
}
public String getPrefLegal() {
return prefLegal;
}
public void setPrefLegal(String prefLegal) {
this.prefLegal = prefLegal;
}    
public Integer getNumViewRows() {
return numViewRows;
}
 
public void setNumViewRows(Integer numViewRows) {
this.numViewRows = numViewRows;
}   
 
}

 

on an xpage I use the code:

<xp:inputTextarea id="inputLegal" value="#{configBean.prefLegal}"></xp:inputTextarea>

 

I wonder how I can update the document in the preferences view with the information entered on the the xpage? Instead of placing SSJS under a submit button I would like to store the logic into a java class and call a method from the button...

 

Not clear how to do this...

Apr 17, 2014, 2:52 PM
586 Posts
My thoughts

I'm going to go out on a limb here and disagree with Paul Calhoun.  I think I've only ever disagreed with him once before but that was about BBQ.  So that was less a disagreement and more like Holy Wars.  :)

 

Anyway - While yes there might be SOME duplication of what XPages does to "convert" documents to managed beans the fact that you now have your business objects represent rather then generic NotesDocuments is VERY POWERFUL.  It allows you to put more of your business logic in one place.  This in turn allows you to speed up development in the long run.  

Yes it can be done wrong so you have to be careful.

No I'm NOT saying you need to use Java for an XPages application.  But I am saying that if you have a "company document".  Translating that into a custom Java Object and making that a "global variable" that is amazingly great that in my opinion, it's absolutely worth the effort to try and work with and get a comfort zone.

Patrick - there's a bunch of videos on NotesIn9 on this.  I think Russ's might be the best getting started.  I'm not sure.  I've done some myself and have more coming.

In you're code snippet here...  you're loading the document and reading the values...  So you add a save method...  in there re-load the document (not the values) and do a doc.replaceItemValue() of what's in your object and put that info on the document.  Then save it.  Recycle everything of course then.

You're button then just calls the save method...  either using SSJS or EL should work as well.

I do this all the time.

 

Apr 17, 2014, 3:19 PM
366 Posts
Here is the important distinction (imho)

Does the "data" that is being saved to the Mangaged bean need to "persist".  Meaning do you need it again some other place.

If the answer to that is no, then it's really hard for me to justify the additional overhead and addition code of using a managed bean for creating Notes documents through standard XPage components.

So via XPages components (Zero "code")

Via Managed Beans (Code to manage EACH component)

So if you are just trying to learn how it all works, then code away.

If this is for production, they it's overkill.

 

PS.  David makes GOOD Barbecue.  In Texas we make GREAT Barbecue.  :)

Apr 18, 2014, 1:55 PM
586 Posts
Hold on Tex...

:-)

The great Paul Calhoun writes:

Does the "data" that is being saved to the Mangaged bean need to "persist".  Meaning do you need it again some other place.

If the answer to that is no, then it's really hard for me to justify the additional overhead and addition code of using a managed bean for creating Notes documents through standard XPage components.

So via XPages components (Zero "code")

Via Managed Beans (Code to manage EACH component)

So if you are just trying to learn how it all works, then code away.

If this is for production, they it's overkill.

I submit to the court that there's more to the story...

Paul uses the team "Managed Bean" in his comment but lets strike that as that's more specialized.  What we're really talking about is if you want to interact with a domino dataSource - a document or a View or a Java Object.  That Java Object might or might not be a "Managed Bean". It could be an object Data Source, it could be an object you just put into scoped binding.  I did a video on different wants to use Java Objects in XPages here:  http://notesin9.com/index.php/2013/08/01/notesin9-122-working-with-java-objects-in-xpages/

As with anything it all depends on your app or environment. I don't think it's about the object needing to "persist" as much though that's how Managed Beans are often used.  As Global variables...  Global to the page, session, or application.  Keep in mind that you can't safely put a domino object in certain scopes.

Anyway - to me it's not about the lifespan of the object.  It's about the ability to make you're own API.  As I said in the recent Java vs. JavaScript debate show...  The Domino API is pretty handy...  We use it all the time.  What if it didn't exist?  what if it was just a mess of 3,000 functions?  Yuck! But if you have an environment, where you're using multiple apps...  I think making a "Business Backend API" is an absolute Godsend. And yes that means using Java to represent documents.  In the early stages it seems silly.  Why make a Java object to represent a Customer/Company?  Just to load and save the document.  But what if your customer/company had methods like:

getAllContacts(),  addContact(), getLastShipDate(), getAmountOwed(), getPrimaryContact(), getMailingAddress(), getPreviousMonthRevenue(), getPreviousMonthLastYearRevenue(), getRecentOrders()

Those sounds handy....

What if everytime someone changed a field on the company you wanted to log and track it?  Pretty easy to add in the Java Object. Maybe a better example is handling if 2 people are editing the same doc at the same time.

What if you needed to use this company object in multiple applications...  no problem..  make an OSGI plugin... or do it the baby way like I do and just push the design to any database that needs it?

What if the company was a division and part of a group of companies..  a "Family" you might say...

You could have a Family object that holds all the Divisions... A "FamilySet"  Maybe now you want to pull all the orders for the Family so you can see how business is going... maybe output that to Excel via Apache POI...

Yes... the first day with you're Company object that simply represents a company notesDocument seems silly..  not a lot to gain.  But on day 45..  when you've slowly built the functionality up of the object?  Now you're at warp speed.  Things speed up because you have a good base of working and tested code.  You now have you're own Business API! And yes you gain some other potential benefits of MUCH less code in the XPages markup and working with the Java Editor which is rather powerful in it's own right.

 

Don't underestimate the power of a business api.  And don't underestimate Pennsylvania BBQ!  :-)

 

 

Apr 18, 2014, 2:34 PM
366 Posts
David is correct.

I don't disagree with anything Mr. Leedy states.  

Having a business API is a powerful tool in your toolbox.

But that was not the question that got asked.

Writing a Java Class or Managed bean to manage the read/writes to every field on every notes document in every application though (imho) is NOT a best practice.

That's what the Domino API and the java class that the XPage source code produces does automatically.

So unless I have BUSINESS requirement for replacing the existing functionality then I'm over architecting the application.

There are reasons to write Java classes/managed beans that replace the CRUD operations that are built into the existing API.  But this is mostly for complex interrelated applications like the ones David describes.

If I need to update some config documents in a single application that is not used anywhere else, replacing the built in CRUD is overkill.

So use the right tool for the job.  The more tools you have (the more experience you have) the easier it is to get the job done.

 

Apr 21, 2014, 9:04 PM
16 Posts
Have a look at...

this article series: http://www.pipalia.co.uk/notes-development/rethinking-xpages-part-one/

I have found great inspiration in it. I have just recently released a system to test built entirely using an MVC model along the lines of this series of articles. All logic written in Java - and all data bound to XPages via EL. I find this a much cleaner solution than using SSJS - but it may take a little more learning...

I am working on  a second version of a demo database (presented at DanNotes in Denmark in November) - you can see the slides here (and there is a link to the demo database: http://www.slideshare.net/JohnDalsgaard/mvc-and-ibm-xpages-from-dannotes-in-korsr-dk-28-november-2013). Please note that since then I have found a much cleaner way of handling validation in the model - avoiding using session beans and using view beans instead (which really is something you want to prefer for scalability purposes).

I have a list of blogs coming up - but have not yet had time to write about this since we are still just getting the system out into the open ;-)

/John


This forum is closed to new posts and responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:

HCL Software Customer Support Portal for U.S. Federal Government clients
HCL Software Customer Support Portal