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:
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.
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".
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.
locating XPage components with XspQuery
Sun, Apr 14th 2013 12:00a Tim Tripcony Several years ago, I wrote a utility Java class designed to make it easy to search for components within the current XPage instance based on various criteria. I've found it enormously useful, and, apparently, so has Keith Strickland, because he added it to org.openntf.xsp.extlib, complete with a few refinements. As an example of how you might use this, examine the following line of code:
List requiredFields = new XspQuery()
.loc [read] Keywords: ldd
your how is not your what
Wed, Apr 3rd 2013 11:36a Tim Tripcony I've noticed a pattern emerging when I'm asked for help with XPages. Here's a representative conversation:
"I'm trying to do [X] and it's not working. How can I do that?"
"What are you trying to accomplish?"
"I already told you. I'm trying to do [X]."
"No, that's how you're trying to do it. What are you trying to do?"
For example, replace "[X]" with "reach into a repeat control from outside it" (since this has become the most frequent topic I'm asked about [read] Keywords: xpages application
my new favorite quote
Sat, Mar 23rd 2013 5:20p Tim Tripcony "We go about our daily lives understanding almost nothing of the world. We give little thought to the machinery that generates the sunlight that makes life possible, to the gravity that glues us to an earth that would otherwise send us spinning off into space, or the atoms of which we are made and on whose stability we fundamentally depend. Except for children (who don’t know enough not to ask the important questions), few of us spend much time wondering why nature is the way it is; where the [read] Keywords: wiki
Taking the scary out of Java in XPages: Prologue
Tue, Feb 26th 2013 9:50p Tim Tripcony The discussion following my last post made stark the need for greater availability of information that makes the nature of Java more accessible to Domino developers. Credit for the title of this post goes to Declan, who is considering writing a series of blog posts on this topic. I will be doing the same; hopefully there will be a fair amount of duplication. As David Leedy is fond of stating, it's a good thing when several people share the same information, because that makes it easier for the [read] Keywords: domino
Passthru vs. component - my perspective
Sat, Feb 16th 2013 9:40p Tim Tripcony Paul Withers posted a thorough article explaining the differences between namespaced XPage components (e.g. ) and their corresponding passthru elements (e.g. ), providing numerous examples of what actually happens when these objects are constructed. I've always heard (and often repeated) that passthru elements are more efficiently processed than their namespaced equivalents, so Paul's post inspired me to offer my own perspective.
Simply put, there's practically no difference... but there a [read] Keywords: acl