Yes, you read that right: every Domino administrator should read the new XPages Portable Command Guide. Developers should too, but from what I've read so far, I feel it's more crucial that admins pick up a copy of this book.
Let's assume that you're a diligent administrator. You've known for maybe a decade now (or more) how best to configure an end user's Notes client installation. You can set up an efficient replication and mail routing topology in your sleep. You've even kept current, so you now know all the best practices for configuring DAOS and Traveler. Congratulations! You're a top notch email administrator.
But if I'm your Notes developer, and I need you to deploy a new XPage application, do you know what questions to ask me in order to ensure that the correct persistence settings are enabled in the application's xsp.properties file? Do you know what heap size should be set in the server's INI to provide a solid balance between performance and scalability? It's fantastic that you know exactly how to support every last detail of an email environment, but do you know how to support applications?
If you don't, or you're not sure, or even if you think you're sure, buy this book. Sorry for the blunt honesty, but I haven't met a single Domino administrator who could instinctively tell me what the xsp.persistence.mode setting should be, based on whether the users want the application to be fast, scale to massive amounts of concurrent users, or provide a healthy compromise between the two. If, at a minimum, you can't answer that question without even stopping to think, and you administer production Domino servers running 8.5, or ever plan to, you need this book.
Hint: the answer is on page 24. In fact, the entire first chapter - all 81 pages of it - are just about how to configure one file: xsp.properties. This is where you define, either at the server level, or at the application level, or both, resource management (such as CPU and RAM), cache management, and the like. There are plenty of settings that can be defined in this file that only the developer should care about, but many of them you don't want the developer to decide. Trust me, if you leave it to me, I'm typically going to max out the RAM consumption in an attempt to provide lightning fast response times. But it's your server. You should be overriding me on that decision... as long as it's still in keeping with the end users' business needs, of course.
Chapter 2, with the exception of a couple pages at the end about defining very specific security settings, is also about a single file - notes.ini - for tweaking stuff like Java heap sizes and improving post-restart performance by preloading certain JVM tasks. Again, pretty much all admin stuff. Developers should also understand these things, or we won't be writing efficient code, but it's the administrators who need to know what the appropriate settings are based on the hardware available and the users' needs.
Chapter 3 is all about Domino console commands. Very useful for the developer when doing unit testing, but obviously this is still primarily targeted at the administrator.
Okay, admins, the second half of the book would probably just bore you. So feel free to move along now. But buy the book, okay? Your end users would love for their admin to know how to support their apps as well as their mail, even if they don't realize that's what they want. Trust me on this.
Developers, still with me? Good, 'cause we're getting to the half of the book you'll actually find interesting.
Chapter 5: Server-Side Scripting. This chapter digs slightly deeper into the server languages like SSJS and Java than Mastering XPages did, but honestly I didn't see a whole lot new here. On the other hand, this is, after all, a "portable command guide". So whereas, in the words of one of the authors, Mastering XPages was about the "journey" of learning to develop XPages applications, this is kind of the "yellow book" (for those of you who have been around a while) for XPages: the handy reference you keep conveniently next to your mouse pad at all times.
Chapter 6: Server-Side Debugging Techniques. This is where it gets really interesting. A loose form of some of this has already been distributed in PDF form with the XPages Extension Library (the actual library itself, not the next book about XPages that I'm going to tell you that you should buy), but this provides the same information in a more polished form, as well as much more detail. Spoiler alert: once you've finished this chapter, you'll know how to bind your test server's HTTP task to an Eclipse debugger, so you can step through your code just like you used to do with LotusScript. Mood killer: that does you no good if you write all your code in SSJS... you only get step-through for your Java code. Sorry. Take it from a guy who used to hate Java: just get it over with and learn Java. You'll write better code, your XPage apps will run faster and be more powerful, and your skills will be more portable should you ever decide (or be forced) to seek employment outside of the Domino microcosm. If your experience at all resembles mine, after a few months you'll wonder why you ever liked LotusScript. *
In summary, this is an excellent read for developers and admins alike. It's not as sprawling an epic as Mastering XPages, but it's not meant to be. This is a reference guide, something you'll want to absorb as much of as possible, but should keep on hand to revisit as the need arises.
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