When I'm coding an XPage, I live in the Source tab... especially now that, as of 8.5.2, I can drag new components directly into the XML instead of having to choose between typing everything manually and bouncing back and forth between tabs each time I want to add a new component. One pet peeve I have, however, is when I open a design element and find that the XML isn't formatted: no line breaks between tags, inconsistent white space surrounding attributes, etc. I know, that's a fairly petty thing to get annoyed about, but when I'm troubleshooting a problem or even just trying to familiarize myself with a codebase, I prefer order to chaos every time.
The good news is that this is quick and easy to remedy: just press Ctrl + Shift + F, and Designer reformats the XML and makes it all pretty. Well, as pretty as XML is gonna get, anyhow.
On the other hand, there are (at least) two scenarios in which this can be inefficient. One of these is when a single XPage (or Custom Control) is huge... I've seen several that take upwards of a minute to reformat and, on at least one occasion, can even stall Designer indefinitely, requiring an intervention from NSD. The other is when an application contains a significant amount of unformatted XSP files (I suppose it's not too difficult, by now, to guess why I might now be encountering this latter scenario on a daily basis)... while each may be comparatively terse, it naturally becomes an annoyance to open dozens of them and have to reformat each individually.
Thankfully, there's an easy remedy for this as well:
Switch to the Package Explorer view
Expand the folder representing the affected application
Right-click the "XPages" folder and select "Source > Format"
Repeat step 3 for the "CustomControls" folder
Upon opening any of the design elements contained in these folders, you'll see that the XML is now properly formatted.
Because there is no immediate repaint operation necessary in response to this menu option, even ridiculously large XSP files are reformatted almost instantaneously. Likewise, since it operates upon all resources within the selected folder, it's far more efficient - even for small sets of elements - to update them in bulk than to reformat each individually. The primary downside, of course, is that this results in the modification of potentially many design elements with no corresponding change in the behavior of each... depending upon your organization's change management process, this might result in some confusion. But the few folks I've already mentioned this to in passing have found it to be a handy productivity aid. I hope some of you find this useful as well.
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