XPages developers all know that they aren’t writing Notes apps anymore. The experienced ones know, cognitively at least, that they aren’t bound by the same rules that applied to Notes. But there’s a difference between knowing and doing.
Let’s take a really simple example: a standard Notes form with a few fields in a table. Imagine you have a simply Notes form with a table containing 6 rows and two columns. The first column contains the labels for the fields appearing in the second column, for a total of 6 pairings of static text and fields across table columns.
Pretty normal right? And so if you decide to make an XPages version of that by creating a control and adding the data source, then you drag the fields into your editor and get something that looks like this…
Using a standard HTML table, this sets up a label/field pairing that is nearly an exact match to the structure of the original form. This is just fine for your very first XPages application. If you delivered this to a user, chances are they would nod and say “okay” and then move on with a list of enhancements.
Now you’re getting a bit more sophisticated. Instead of using a standard Table, you’re using a Form Table component, which understands title and description information, and provides rows with a basic understanding of labels and controls that relate to each other.
In both of these patterns, you have 6 rows of components in your control to represent 6 rows in your original design. This is a completely normal and everyday practice and it can be found in dozens of XPages applications written by IBM, provided by the community at OpenNTF.org, or sold commercially by business partners.
What if I told you that this approach isn’t a best practice? What if I said that there is a far simpler way to both dramatically increase developer productivity AND future-proof your application design? Would you like to know what it is?
“It’s not that simple,” you might reply, “I don’t just need labels. The inputs have to be bound to different fields, and some of them are required while others aren’t, and they need different styles and… and… and…”
Well, try it. Just look at the screen shot I’ve attached and ask yourself how much work that really is. It took me about 23 minutes, at midnight, to write an abstract custom control that can provide reading & editing of practically any Domino document in seconds. All you need to do is decide how you want to populate the members of the PageController class in any given instance. That could be from an NSF, from some XML, from a block of JSON via a REST service, from an RDBMS or whatever other path you choose from the near infinite variety of resources open to you in the XPages context.
Perhaps you think my implementation is too simple. You’d like to be able to group your inputs together into logical groups with headers. No problem, that’s just one more layer to the abstraction by adding an additional controller. It takes about another 5 minutes. I didn’t bother throwing in, say, a <xp:tabPanel> around the Form Table in this example, but I think you can see that it would require about 30 seconds to do so.
When you shift your thinking away from building XPages that contain your implementation details, and instead focus on them providing structure to implement from metadata, it opens up a new world of possibilities. You can get yourself out of the business of massaging endless pages of visual components, and start to achieve real productivity gains.
Let’s take a further example of an easy win: what if in the future, the Form Table Row is enhanced to allow for a new labelPosition value? Perhaps “placeholder”? How much code would you have to change to leverage this feature across all your applications? Doesn’t “one line” sound like a fantastic answer?
P.S: What you’re reading here, by the way, is the Red Pill Methodology for XPages applications. This is the ONLY WAY we build XPages apps. And yes, there’s a lot more to it than I’ve discussed so far. We have a rich set of supporting technology that we share with our customers, and what I think are some excellent ways to determine how to extract the metadata needed to drive the above examples. But this methodology is the core reason my colleagues can do things like mobile-enable 39 applications in a single day.