Author: David Leedy

This show comes directly from my day job.  This is a presentation that I gave to the internal XPages team. I talk about using Java Objects but not necessarily via “Managed Beans”.

A lot of XPages and Java talk centers around “Managed Beans” but that’s not your only option.  There are additional ways to use Java Code in your XPages Applications that don’t need Managed Beans.  There’s also DataContext, objectData and “ScopedBinding”.  NOTE: “ScopedBinding” is a term I’m making up myself.

So I’m really not an expert here, this is just stuff I’ve been playing with and there might be things I’ve missed but this is a simple demo on how to use a Java Class from each of these entry points. I thought it might be useful especially if you hear the term “Java Managed Bean” and think it’s something scary.

Another Note:  I have a little Java Class in here for the demo.  That Class itself was rushed and not exactly an example of best practice.  It’s kinda close, but I left some crap in there that needs to be cleaned up.

Hope You like the show.

P.S. In the show I am asking for feedback on how you prefer to consume NotesIn9 Videos.  Do you stream from the website? Do you download and watch off line via iTunes/RSS?  Do you prefer YouTube?  Any feedback on that would be appreciated.  I’m trying to find out preferences between downloading vs streaming for the most part. Feel free to comment here, or send me a note on twitter or email.

thanks!

UPDATE: I mentioned on the video that there were several things that I did not know.  Most of them have been answered by the great Tim Tripcony who sent me the information below.

 

UPDATE 2: Here is the demo file for this show

beans.zip

Comments from Tim Tripcony:

 

Great video today! I’m hoping I can answer some of the questions you brought up during the demo:

1. Java “purists” would tell you that if your class has A) an argumentless constructor, B) properties exposed via getters and setters, and C) implements Serializable, it’s a bean. With “managed beans”, all that is being “managed” is the variable name and scope. So the class you showed is always a bean, regardless of each of the ways you demo’ed using it, because its own code meets the bean criteria. But you also registered it in faces-config, so Domino “manages” making sure there’s always an instance of that bean named “PersonBean” in the session scope. That’s what makes it managed. It was already a bean because it uses bean conventions (serializable, argumentless constructor, and getters/setters).

2. ignoreRequestParams is ideal for “related” data sources. For instance, if you had an XPages-based blog, and you’re using the standard document data source for blog entries, then you’d want that data source to respect the URL, because then you can use built-in URL parameters like action, documentId, formName, and databaseName, and it’ll know which document to open, whether it’s new, in edit mode or read mode, etc. In contrast, if you had a repeat underneath the entry content to display comments, then your data source for each comment in the repeat *should* set ignoreRequestParams to true. Otherwise, even if you’ve set action to “openDocument” and calculating the documentId based on what row the repeat is rendering, the data will IGNORE those properties, because it will see matching URL parameters and the value of those parameters will override the data source properties. BUT… all of this behavior is the way that the original data sources (document and view) behave. The object data source always ignores the URL, so ignoreRequestParams has no effect, because it always ignores the params. The property just shows up because it’s part of the base interface for all data sources.

3. requestParamPrefix is ideal for “sibling” data sources. What I mean by that is if you have two data sources on a page that are sort of “peers” (as opposed to a parent-response, discussion thread style relationship). For example, suppose you had two documents that you wanted to allow the user to compare side-by-side… if you created one document data source with standard attributes (just var and formName), and a second document data source where requestParamPrefix=”other”, then your URL query string could contain something like documentId=”OU812″&otherdocumentId=”OU813″… So your first data source will be bound to the document whose note ID is OU812, and your second data source will be bound to the document whose note ID is OU813. Object data sources also ignore this property; this only affects document and view data sources.

4. The reason you had to set your data context to compute on page load is because data contexts are automatically associated with the request scope… so if you set it to compute dynamically, then it will create a new one on each request, not just one for each page instance (i.e. view scope). Setting it to compute on page load makes it behave more like a data source than a data context.

5. Your assumption about the syntax of #{sessionScope.ScopeBean.firstName} is correct. All 4 of the scopes are Maps, so when the variable resolver identifies sessionScope as a Map, then the property resolver knows that instead of the usual getPropertyName() / setPropertyName(newValue) syntax, it should call get(“propertyName”) and put(“propertyName”, newValue) instead… but only if it’s the last property in the chain — anything in the middle is always treated as a get. So the whole expression essentially gets translated into sessionScope.get(“ScopeBean”).getFirstName() in read operations, and sessionScope.get(“ScopeBean”).setFirstName() in write operations.