My colleague, Chris Toohey (or, as I sometimes refer to him, "Winnie the Tooh") has already demonstrated how we can strip the markup generated by an XPage down to the bare minimum. Of particular interest for this article is the "createForm" attribute of the <xp:view /> tag, which, when set to false, tells Domino not to auto-generate a form tag that surrounds the content of the page.
As noted in the comment thread of the aforementioned article, stripping the generated markup has many valid uses, but creates more manual work for you: you're essentially telling Domino, "it's okay, I'll take it from here". Instead of settling for what the platform automatically gives you, you're seizing control and making it do precisely what you want it to do. Which is fantastic, but for most of what we typically want to do, this would be overkill.
In the case of the form tag, removing it disables all built-in event management. For the server to know what's happening in the browser, the page needs to post its data, and without a form tag, Dojo doesn't know what to post. So having a form tag is a Very Good Thing™... but wouldn't it be great if we could specify precisely where we want that tag to be? Well, luckily for us, there's a way... it's just secret. Or, perhaps more accurately, it's hidden.
When editing any XPage, Designer first shows us a Design tab, which is approximately a WYSIWIG representation of the page content. There's also a Source tab that displays the XML tags that represent the actual design of the page. None of this is the real code, of course; this is just an instruction set telling Designer what Java code to generate when the page is built. But since we don't actually write that code ourselves, it's fair to think of the XML on the Source tab as the "source code" of the XPage.
Whenever we drag components from the palette to either tab, or set properties on components already on the page, the XML is updated to reflect our changes. The editor just does this automatically, providing us a visual - and, in the case of code editors, combo boxes and the like, content-assisted - approach to specifying the content of the page. But there's nothing stopping us from simply typing the XML by hand. Many of us who have spent a great deal of time developing XPages have found that, eventually, this approach becomes a faster way of working than trying to do everything visually... at a certain point, the editor just gets in the way.
One area where this is noticeable is when dealing with components that do not appear in the palette by default. Granted, you can add them, but when you're using additional control libraries (such as the OpenNTFExtension Library), the palette can get rather cluttered, so I find that I keep the palette restricted to the components I use constantly, and just manually type in the tags for the rest. Additionally, as I recently discovered, there is at least one component that cannot be added to the palette: <xp:form />.
That's right: there's a form component. And it does pretty much exactly what you would expect: it moves the form tag to where you want it to be. So instead of surrounding the entire page content, including your header and footer, site / application logo, and so forth, it surrounds only what makes sense to include in a post: fields and controls with bound events.
But wait, there's more: you're not limited to just one. You can add as many form tags as you want (just don't nest them). Remember how hacktastic this used to be? When you wanted, for example, to create a search field that posted to somewhere else, and not actually have it write to the document the user was editing, you had to close Domino's form tag, start your own, etc. What a pain.
Ironically, we don't even need separate forms any more, even if different fields are bound to different data... it all gets posted to the same place, and our data sources sort out how (and even if) everything ultimately gets written to disk. So why would you bother creating multiple form tags? In a word, performance.
Suppose you've created an in-view-edit interface by putting a panel inside a repeat control that iterates view entries, and each panel has a localized data source bound to the document associated with the iterated view entry. One day a user opens this page, updates a contact's phone number, and clicks the Save button specific to that contact. The data is sent, written to disk, and can be retrieved later as needed. Everybody's happy... except the browser and the server, because they both just performed more work than was necessary.
In the above scenario, if the interface is displaying five fields each for 30 rows, the browser is posting the current value of 150 fields (plus a few hidden $$ fields) just to update one phone number. If, on the other hand, you were to surround each row's fields in a form tag, then you're only posting 5. In most cases, the performance differential will be indistinguishable. But if the user has a slow network connection, they'll notice a difference. Similarly, if the application needs to scale to support many concurrent users, the server is going to "notice" a difference when all users are posting 5 fields at a time instead of 150, and that perception of improved performance will trickle down to the users as well.
Before I leave you, allow me to present one more parting gift. An oft-discussed scenario where Dojo doesn't play nice with the default form handling in XPages is use of the dialog dijit. In case you're not already familiar with this issue, when a dialog is displayed, Dojo moves the DOM elements that comprise it to the end of the body tag in order to avoid potential layout problems. In most web development contexts, this does not pose a problem, because the developer has already placed the dialog outside of any form tags they are creating, and is manually handling whatever they need to in order to ensure the dialog functions as desired. In an XPage, however, this DOM manipulation causes the dialog to be moved outside of the auto-generated form... which, as was already mentioned, means any events bound within the dialog are now broken, and any fields it contains are divorced from the form as well.
I estimate that I've seen at least a half dozen different approaches to rectifying this issue (including one I came up with all the way back in the Squawk days), and most, if not all, of them use some client-side JavaScript to move the dialog back inside the form. The dialog control in the Extension Library somehow just magically handles all of this... I've done some spelunking in the source code, but to be honest, I still don't fully understand how they're doing it.
But it turns out that there's an easier way, and it doesn't involve any JavaScript, server- or client-side:
Create a form tag to surround all the fields and event-bound controls that are not in a dialog.
Place each dialog outside of that form.
Create a form tag inside each dialog, and put the dialog's content inside that form.
That's all there is to it. No JavaScript at all. And yet, events still work, whether they're inside a dialog or not, and field data gets posted correctly. Everybody's happy... even the browser and the server. Possibly even the user...
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()
.addInstanceOf(UIInput.class)
.addEquals("required", true)
.loc [read] Keywords: ldd
lotus
dojo
java
javascript
openntf
oracle
server
357
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
xpages application
java
673
SSJS is a crutch
Fri, Feb 22nd 2013 10:50p Tim Tripcony I've been debating for quite a while whether I should write this post. It obviously makes a potentially controversial statement. A fellow developer who knew I was drafting it put my hesitance into perspective: "you really want to be that guy?" This was my response:
I want to be the guy who saves people pain. But sometimes to do that, you have to tell your friend if she wants to stop being punched in the face, she needs to leave the guy who keeps punching her in the face.
This post is ju [read] Keywords: agent
domino
formula language
ibm
lotus
lotusscript
notes
xpages applications
development
java
javascript
openntf
wiki
420
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
domino
xpages application
development
properties
security
535
org.openntf.xsp.extlib
Mon, Jan 21st 2013 5:20a Tim Tripcony About 18 months ago, I created an OpenNTF project called Community Control Library. The fundamental reason for creating the project was my belief that the single factor keeping the Domino community from realizing the true potential of the platform is the assumption that the XPages Extension Library is the extension library, not an extension library. Let's briefly revisit its history:
IBM starts an internal project, code named "Porus" (in reference to the Greek / Roman god of plenty), inte [read] Keywords: domino
ibm
notes
policies
xpages application
applications
best practice
community
development
openntf
wiki
