Tip of the Iceberg

Category java xpages
If you're learning about XPage development, particularly if you're pushing past "drag and drop" development, it's likely that you've encountered the term "bean". If so, it's also likely that you've seen this term in the context of a larger concept: "managed beans". For the purposes of this post, let's ignore the "managed" portion for now and just focus on what it means for a Java class to be considered a "bean".

Given the coffee motif of the Java language, the term "bean" is used simply to indicate the role a class plays as a unit of Java. You may have also encountered the acronym POJO: "Plain Old Java Object". As Wikipedia indicates, a POJO is just any Java class that doesn't conform to any specific conventions. A bean, on the other hand, conforms to very specific - but very easy - conventions:

1. It includes an argumentless constructor. For those of you with a LotusScript background, this is similar to how you can Dim a variable as a New NotesSession() or a New NotesUIWorkspace()... you don't have to pass any parameters, or arguments, to that declaration... you just create the new object, then interact with it later. NOTE: this doesn't mean that a bean can't also have constructors that do accept arguments; Java, after all, does support method overloading. But it means that, at a minimum, the class supports instantiation with no arguments.
2. Attributes of the object are accessible via predictably named "getters" and "setters". For example, if I create a House bean, and one of its properties is "address", the class will include a getAddress() method and a setAddress() method. Similar to the first point, the getter accepts no arguments, and the setter accepts one: the new value of the property. One might well ask, why not just make the property public, if you're always going to provide public getters and setters? The answer is simple: forcing reads/writes to call methods provides the luxury of doing other stuff™, if desired. This provides an opportunity to sanitize incoming data, for example, to ensure a property's value is not being set to invalid data. Also worthy of note is the one deviation from the getPropertyName / setPropertyName convention: if the property is a boolean (true/false) value, the getter uses an "is" prefix instead - for example, isForeclosed() - but the setter always uses "set".
3. The class is serializable. Serialization is the process of storing the state of an object somewhere else. This could be in some flat file on the hard drive, a database record, or even just a different in-memory format. Deserialization, then, is the reconstruction of the object state from an alternate location. This is actually a key reason for the previous two conventions: some process external to the class definition can parse the serialized state of an object and restore its state predictably... construct an instance with no arguments, then call the setters for each of the attribute values it finds.

Why is it crucial to understand the nature of beans when developing XPages, even if you're not specifically writing Java code? Because darn near everything in an XPage is a bean. Every control - every inputText, every panel, every repeat - is a bean. This means that your code can interact with control instances in a predictable fashion. An inputText has a title property that stores a String, therefore it must have a getTitle() method that returns a String, and a setTitle() method that accepts a String. Just about every control has a styleClass String property, so it's generally safe to assume that, even in SSJS, you can call getStyleClass() and setStyleClass() regardless of which control you're interacting with. If you've attended my session on advanced theme development (and/or downloaded the presentation), you know that you can customize nearly any property of a control via a theme... this is why: every control is a bean, so the theme manager knows predictably how to inspect and modify any control attribute without having to hardcode specific behavior for each.

There are many other advantages to the extent to which everything in XPages is based on beans, like using abbreviated EL (expression language) syntax to bind read/write control attributes to a property of another bean (this is a topic for another day). But the key point to remember is that, even if you're not writing any Java yourself, everything you're interacting with is some Java bean... so, as long as you know what properties that object supports (and whether or not each property is a boolean), you know how to retrieve or modify those properties programmatically... even without any explicit documentation.