Category: XPages

Ok.  There’s a lot going on in this show so let’s get started:

This show came from a Skype Chat I had with Tim Tripcony.  The goal here is a series that focuses on how you actually use xpages and java beans together.  We want to show how to bind to Java Objects instead of documents and actually use them.  This is not a full “app” but more of a CRUD example.  We didn’t want to distract too much from the core concept of linking XPages to Java Beans directly.

Of course I failed at that as since Tim was using source control for this I wanted to start the show with source control.  So you can see me bring the project down and create not only the .ntf but also the .nsf file.  So if that’s not too interesting to you skip it.  the Java stuff starts around the 15 minute mark I think.

I did do some editing to cut out some other parts that weren’t needed.  So there’s a pretty poor transition in there at one point. One of the things I cut out was how Tim was using Themes to pull Bootstap 3 into his app from a CDN.  So if you’re interested in Bootstrap you might want to download the app and check that out!  Clever.  Beats putting it into the NSF.

Today is actually my birthday.  So as a gift to the community I wanted to get this show out and start this series.  Jesse Gallagher asked if that I was doing a Hobbit Style Birthday.  Where a Hobbit gives out gifts on their birthday.  Wish I would have thought of it that way.  Typical Jesse – usually 3 steps ahead of me.

Anyway – I hope you like the show.

P.S. This show is at another new resolution. 1440×900 I believe.  I’m having trouble getting my  Parallels VM to use my normal 1280×720 resolution.  It works great for my work VM but not my NotesIn9 VM.  Really weird.  I do like the bigger resolution since you know…  it’s Designer and all that.  So I might try to keep this.  I don’t know.  But PLEASE let me know if you have problems viewing the show or reading any code.

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.