Every week or so, I spot some post or conversation about the pros and cons of “managed beans.” Whenever I see this, my first reaction is to chuckle because I know the more prosaic use of the word “beans”, but then I think about how all these discussions imply that this is some sort of fundamental shift in the development paradigm for IBM collaboration solutions.
It’s not. “Managed beans” is just a name for a slightly more abstracted version of something that you, as a Notes developer, have already been doing for years.
Here’s what a managed bean is for a Notes developer: a variable in the Globals for your form or view.
Yeah, that’s it. Except with managed beans, you also get to have global variables for your Session (environment variables) or NSF (public profile docs).
Okay, sure, a managed bean is written in Java instead of Lotusscript. But if you use the OpenNTF Domino API, there really isn’t that much of a difference.
So let’s break down the term: managed beans. First off, obviously, there’s “bean.” What’s a bean? It’s a Java object. Fundamentally, that’s it. There’s no secret sauce, no magic transport to a castle in the sky — a bean is just an object that’s defined by some class. If Lotusscript had beans, you would already know that any instances of NotesDatabase, NotesDocument, NotesView, NotesViewEntry and NotesItem are beans. They’re just objects that have properties and methods.
If you’ve ever written a custom class in Lotusscript that looked anything like the following, congratulations! You’ve written a bean!
Class Foo
Private pBar As String
Sub New ()
End Sub
Property Get bar As String
bar = pBar
End Property
Property Set bar As String
pBar = bar
End Property
End Class
Here’s what the same code looks like in Java…
public class Foo {
private String pBar;
public Foo() {
}
public String getBar() {
return pBar;
}
public void setBar(String value) {
pBar = value;
}
}
Big difference, right? The only substantial change is that we’ve applied the Java standard of prefixing the properties with “get” and “set.” But that’s not foreign to Lotusscript developers either, since you’ve certainly used .getItemValue() and .getFirstDocument() many times in your Notes career.
In fact, we can even make our Lotusscript bean look a little more like our Java bean…
Class Foo
Private pBar As String
Sub New ()
End Sub
Function getBar() As String
getBar = pBar
End Function
Sub setBar (value As String)
pBar = value
End Sub
End Class
So there’s your bean. That’s all you have to do. Okay, we can get pedantic and talk about the need to make it Serializable, or the requirement of an empty constructor, or adhering to the is/get/set naming standards — but these are distractions of practice that make “beans” sound like something harder than plain ol’ Objects. All you’re really dealing with is an Object, and even if you’ve only ever written Lotusscript in your whole career, you’re very familiar with dealing with Objects.
What, then, about the “managed” part? What makes a bean “managed?”
Managed means two things: 1) your Object has a name (perhaps it’s O-S-C-A-R); and 2) your Object is kept in a scope.
“That’s it?” you’re asking, “That’s the big deal?!” Yup, that’s it.
You’ve been dealing with Object that have names and scopes your whole career. For instance, how many of you have used this little gem in the (Globals) of a Form…
Dim uidoc as NotesUIDocument
Dim doc as NotesDocument
…followed by this in PostOpen event…
Set uidoc = Source
Set doc = uidoc.Document
Look! Those are managed beans! You gave one bean a name of “uidoc” and the other a name of “doc” and you scoped them both to your Form! You’ve been making managed beans for over a decade, you ninja!
Some of your are now thinking “dude, that’s nothing. I have Lotusscript libraries with Global List variables that manage context and auto-bind to Form events, so I only need to drop in a Use statement and one line in the QueryOpen and it sets up my entire global transactional workflow system!” Okay, cool! So now you REALLY get what managed beans, controller classes, view and session scopes and phase listeners are all about! Get those libraries converted to Java and start building them into plugins using the Starter Kit!
But for the rest of you, you still already understand how to use managed beans. You might not know the syntactical nuances of using them in XPages yet, but you certainly understand the advantage of putting commonly used Objects in a convenient variable scope for your applications because it massively simplifies all your code. So get out there and read up on the syntax and try it out in your XPages applications RIGHT NOW, because you already know just how useful and important this approach really is.
The Rabbit Hole 
Really nice post. I totally agree with the value of creating objects in Java, I’m starting to wonder about the need for “managed beans” as we’ve been using them. To me the managed part is the faces-config piece. Where the objects get created automatically and all that.
Now we can avoid faces-config and use our object in a data context. Though it seems there’s some performance hits depending on how you do that.
But we can also create an object and put it on scope manually. When I only realized recently is you can still use EL in that case.
And finally, there’s objectData which looks really interesting as it seems to be able to work with the simple actions like save. (Though I’ve not been able to get readOnly to work like I at least thinks it should work)
So I guess I’m wondering, with all these ways to use java objects, which is best? Or the pros and cons of each.honestly at the moment I’m starting to think that objectData is better then messing with faces-config at least for document data source based beans.
Thanks for the kind words, David. The “managed” part can be achieved through the faces-config settings, but it’s not the only way to do it. That’s just one syntactical option. If you look at the XSP Starter Kit, you’ll see that it has Java-based managed beans for all 4 scopes (plus a 5th for “server” scope.)
The ObjectData data source is very cool and I’ve been using it a lot lately. It has a lot of conveniences over faces-config managed beans, in that it’s easier to diagnose problems, has more constructor flexibility, and is expressly part of the “page save” operation rather than something you have to manually attach to.
What’s *best* really depends on what you’re trying to achieve. If you want maximum convenience and speed-of-implementation, then ObjectData is probably best. If you want maximum flexibility and reusability, then I tend to prefer managed beans contributed by a server-based plugin. But there’s lots of compromises in between, too — like wanting to design a pure template-based implementation because you have existing compliance processes for template rollouts.
The point I’m trying to convey in this article is that whatever approach you take to building and maintaining your data objects, you should recognize that the fancy-sounding XPages techniques aren’t fundamentally different from the practices that everybody is already used to. They just have some syntactical differences and some use-cases that weren’t available before. But the reason you want to apply them as practices are the same reasons that you applied global standard Lotusscript objects in your apps 15 years ago.
One of the other important aspects with managed beans, other than getting over the intimidating name as Nathan’s post covers with aplomb, is indeed finding the best use for them. In my code, I almost never use view- or request-scoped managed beans – instead, I use them for app config and session-scoped user information (though I often store that in user-keyed application beans too). They’re one tool in the rather healthy toolbox of methods to create and get at Java objects from XPages.
There’s one critical and HUGE difference between “beans” in LotusScript and beans in Java. In LotusScript you have to type all that code yourself. In Java, you right-click, select Source > Generate Getters and Setters. You suddenly realise you should have renamed a property or method. In LS you use find a replace and check every reference, and at this point realise that calling your variable what you did has caused you major headaches. In Java you go to the variable declaration, press Alt + Ctrl + R and change the name. Of course for both you need to update references elsewhere in the database – updates in Java update other Java classes but not SSJS.
There are critical differences in number handling. That is a big learning curve. And after your advice last week I now set properties as Boolean instead of boolean.
But for anyone who thinks “What’s Nathan saying that I should migrate LotusScript to Java, that’s a huge job”, my two cents worth. If you have DialogBox etc during the LS to get responses from the user, that will be a bit of a headache because LS will wait for the user response but Java won’t. But otherwise, I’ve recently migrated some LotusScript and it took about 30 seconds per line. It would have taken less with org.openntf.domino!
That’s a great point, Paul. Once you’re in XPages & Java, the tooling from the IDE is way, WAY better. Setting up the debugger is a lot more complicated, but once you do it, it’s actually a bit more flexible than the LS debugger is.
And Paul’s final point is why Red Pill Development offers LS to openntf.domino conversion services for $1/line, so if you’re on the fence about getting started with all this, you can zip up a script library, email it to me at nathan.freeman@redpilldevelopment.com, and pay via credit card to start working with code and processes you’re already familiar with.
Whether you want to do it yourself or you want to outsource it, the fact remains that you’re already using a managed beans strategy for your Notes apps, and you can continue to use this best practice in new ways by simply understanding the implementation of it in XPages.
[…] How do I use a managed Bean? You can treat a managed bean as global variable and/or global class / function. See Nathan Freeman’s definition of a managed bean. […]