Alright, alright, so it was Star Wars 5 where the striking back occurred. But still a great reference! Now it’s Domino’s turn for some action. We’ve talked about the parts of this that require thinking like a web developer, so when do we get to be Domino developers again? Right now! Assuming we have a framework, and assuming we have a good idea of what we want things to look like, we’re ready to start thinking about the data. However, we’re going to do all of this without creating a single form.
Attached below is a small, very simple, sample database. With a little knowledge of the constructs, and without any thought to the design, something like this can be created in as few as 10 minutes in XPages, and that’s only the beginning. It’s a simple page that allows you to enter two entries to a ‘form’ and save those, displaying the data in the table below. These are all things that are based on Domino structures. The Data Entry fields emulate a Form, while the Table emulates and even draws from a view on the Notes back end. To understand how the data is being stored, we need to do a little digging into the nature of how our XPage is defined.
Please download the companion application to this post here.
XPage data binding: How do I get a form on the page?
Every XPage itself is defined as an object through the <xp:view> tag. These tags will encapsulate the design of the page itself. As an extensible language, one thing that you will notice that may not be familiar is that the XML hierarchy often uses ‘this’ to refer to its parent element. Directly below the <xp:view> tag, you will see an <xp:this.data> tag, defining the Notes data structures that are included on the page. Here we have defined a dominoDocument element named XPageDeveloper using the form Developer, which, as we’ll recall, doesn’t actually exist.
Further down, you’ll see the controls we’re using for data entry. Each control has an <xp:label> to contain the field’s label information as well as an <xp:inputText> for data entry. inputText is the XPages equivalent of a basic text field in Domino, or an input element in HTML. There are other, more complex data entry fields, but those will come later. The ‘value’ property of this inputText object can identify one of two things. If it is a simple value, or code that evaluates to a value, you’ll get an input element containing that value. However, what we have here is something special. This Expression Language (Important to know the name at first, but at the beginning, EL doesn’t come up often) statement will bind the data submitted to this control to the document and field indicated. The generic syntax for this is “#{<document>.<fieldName>}” where document is the var property of a defined dominoDocument on the page. These structures are thus submitting to the Developer form, as we defined above (which, again, doesn’t need to exist). Below them is the most simple kind of action button, which simply submits the data structures on the page (through the submit=”true” property) and reloads the page (with the refreshMode=”complete” property).
So, what about the view? Well, if you look in the code, you will see that there is a view available to the Domino side of things, a single view named XPage Developers which contains all documents of form name Developer. This provides the structure for the viewPanel object on the XPage. While there are many ways of displaying data through XPages, utilizing Domino views can easily be one of the fastest and most convenient. By passing the name of the view to our viewPanel control, we are able to utilize the underlying columns to easily display the data. Even more impressive, this can all be generated automatically by the XPage designer. I simply added the viewPanel, chose the view name, selected the desired columns, and the rest was taken care of for me. Now we have an easy way to view the data on the web, as well as full support for paging through large amounts of data.
This has obviously been a very, very simple entry into data binding and display, but these concepts are core to XPage development, and can easily get lost in the confusion of learning several different languages as well as structures. The important thing to remember when approaching XPages is to start small. One thing that traditional Domino development teaches us is to compartmentalize when we can, to use shared code and structures, and to tackle things one step at a time, one form at a time or one view at a time. The same thing should be done with XPages. Trying to dive right in will cause headaches and culture shock, but the rewards can be worth it.
Next time we’ll take a look at some more specific translations from notes to XPages, focusing on many of the controls at our disposal. We’ll also start to talk a bit about what it seems like we’re losing in the transition and why that’s not the case.
I encourage anyone following along to follow me on Twitter @AaronDBrake for updates, and alerts about new posts. I also welcome conversations and questions. The goal of this blog is to help every Domino developer who’s thinking about taking steps into XPages, and I want to hear how I can help you do that.