XForms Everywhere

Every day the craze about the iPhone is getting to a new peak. Many questions about Apple’s new phone has been answered during the last few weeks, except maybe one: will XForms run on the iPhone? And who will be the first to try? ;)

So here is the challenge: be the first to try to access on a iPhone a form created with XForms and ran by Orbeon Forms. Let us know by posting in this blog or sending us an email at info@orbeon.com. Is it working? How does it look like? Be the first to respond and we will send you a free copy of our book, Professionnal Web 2.0 Programming*. Amongst other Web 2.0 technologies covered in this book, you will find about 20 pages on XForms.

If you want to try a relatively complex page, head for a DMV form. For your own safety, you should avoid typing that long URL while 20 people are waiting in line behind you, ready to kill you in order to get their chance to try an iPhone. So instead use http://tinyurl.com/346hko, or of course follow a link from this blog post.

(*) My apologies to people who are reading this and don’t live in the US: the free book offer is limited to people who have a mailing address in the US.

Last week we fixed a few bugs related to state handling. Cool, you may think, but what is this state handling thingy about?

The idea is in fact fairly simple: user interfaces (and this is not limited to XForms or even to the web) usually need to keep track of some information to work properly.

First, there is information which never changes during the lifetime of the page. With XForms, this includes UI controls definitions, but also definitions such as models, submissions, bindings, event handlers, and actions. This may be contained in a static document on disk, but it may also be produced dynamically, with XSLT, JSP, PHP, you name it. In Orbeon Forms, this is called the page’s static state.

Second, there is also information which may change as the user interacts with the form. For example, an XForms page uses XML documents, known as XForms instances, which store data captured and presented by controls. Instances can be changed over time by XForms action, user input, or talking to external services. They also hold properties determining whether controls using that data are visible, required, read-only, or valid.

The XForms page may contain switches (think “tabs”, although there are other uses) which show only one of several parts of the user interface at a time. It is important to rember which part of a switch is visible. The page may also contain repeated sections with an associated selection index, which must be tracked. In Orbeon Forms, all this makes the page’s dynamic state.

Static and dynamic state information (as a whole called state information) needs to be stored somewhere. Finding how to represent state information, as well as possible “somewheres” to store it is what state handling refers to.

We hope it’s a little clearer now! We’ll look into more details in a further post.

The XML Prague conference was quite pleasant. To summarize:

• I arrived in the conference room at 9:03 AM on Saturday (it started at 9:00) after departing from California about 50 hours earlier. I have 9 different boarding passes for that trip (7 to get to Prague, plus 2 to get to Geneva, my final destination), which is a personal record. That’s also probably an upper bound for the number of hours of sleep I got over the previous 65 hours.

• I met again a few people you expect to see at every XML conference, including Norm Walsh, Eric van der Vlist (who kindly invited me to speak at the conference) and a few others.

• I met for the first time with the eXist development team, which had an eXist workshop on the Sunday. eXist is an incredible project. We integrate it in Orbeon Forms, use it for some customer projects already, and we only hope to use it more.

• I presented a talk entitled Application of XML pipelines. The slides are available on slideshare, although they are missing the code examples and live demos which made much of the presentation. The talk made many mentions of XForms, since much of Orbeon Forms’s architecture, including the XForms engine, is supported by XML pipelines.

• I was surprised to see how many people knew about Orbeon Forms, were using it, or were planning to use it in the future. That was very encouraging!

Thank to Petr Cimprich, the principal organizer, and to everybody who made this small but friendly conference a reality.

XPath is designed to be used within a host language, like XSLT or XForms. Some host languages provide a tracing facility: for instance XSLT has the <xsl:message> construct. Other host languages however don’t, like XForms. For this reason the XPath trace() function can be quite useful¹.

trace() takes 2 arguments: a value which is a sequence of items, and a label which is a string. It returns the value and logs both the label and value in an implementation dependent way. Let’s see what is logged when you execute the following XPath expressions with the open source Saxon engine on the employees document we have seen before:

• The expression: trace(/company/employee[1]/@firstname, 'Name')
  Shows: Name [1]: attribute(firstname, untypedAtomic): /company/employee[1]/@firstname
• The expression: trace(string(/company/employee[1]/@firstname), 'Name')
  Shows: Name: xs:string: John
• The expression: trace(/company/employee, 'Employee')
  Shows: Employee [1]: element(employee, untyped): /company/employee[1]
Employee [2]: element(employee, untyped): /company/employee[2]
Employee [3]: element(employee, untyped): /company/employee[3]
• The expression: trace(/, 'Document node')
  Shows: Document node: document-node(): /

When you use trace() in an expression, there is no guarantee that the function will be executed, as the engine might not need to run that part of the expression, which mean that you might not see anything in the trace output. The following expression reads “false() and ...“. This is an and expression which starts with false(), so whatever comes after that doesn’t matter: the result is always false(). In cases like this, the XPath engine is likely not to run the trace() function call.

false() and trace(true(), 'This doesn''t get displayed')

You can see what an expression returns by putting the whole expression inside a trace(), like in the examples above. You can also use it inside a path expression. For instance this returns a sequence of names:

/company/employee/string(@firstname)

To see what are the employees taken into consideration by this expression, just add a trace() step within the path expression:

/company/employee/trace(., 'Employee')/string(@firstname)

I posted previously on how you can use Firebug to watch events going to HTML elements. Now let’s see how you can quickly locate JavaScript code at a certain line with Firebug.

Many tools have a “go to line” entry in some menu, but Firebug doesn’t. Instead, you can use the search box located at the top right corner of the Firebug panel. There, enter the # symbol followed by the line number (for instance: #3547). You would like to avoid using the mouse to click in that search field? You can do it: instead of using the mouse, press ctrl-shift-k (or command-shift-k on a Mac). Using ctrl-f (command-f on a Mac) would be more natural, but Firebug can’t use that shortcut as it is already taken by Firefox.

If you are using the search field to look for text, as you press “enter” Firebug takes you to the first occurrence of the text you typed. There is no “find next” button, but instead press “enter” again, and Firebug will take you to the next occurrence.

XPath is both simple and powerful. Since XForms uses XPath, we benefit greatly from XPath, its simplicity and power in XForms. But while most of the time XPath is simple and comprehensible, it is also a sophisticated language. Most of the time, XPath expressions will do exactly what you would expect, but there are a few exceptions. I’ll have a look in what follows at a case that still surprises me: the order and context position of nodes returned by XPath expressions.

An XPath expression can return a sequence. Items in the sequence are in a certain order, and each of them has a context position. For instance, consider this document, with 3 employees, John, Peter, and Carl:

<company>
    <employee firstname="John"/>
    <employee firstname="Peter"/>
    <employee firstname="Carl"/>
</company>

Consider these 2 expressions:

1. /company/employee[1]/following-sibling::employee
2. /company/employee[3]/preceding-sibling::employee

The first expression returns the employees that follow the first employee. There is not much to be surprised about here: John is the first employee, so it returns Peter and Carl in that order. The second expression gets the employees before Carl. It returns John and Peter in this order, as all the path expressions in XPath return nodes in document order. Let’s summarize:

1. The 1st expression returns: Peter, Carl
2. The 2nd expression returns: John, Peter

Now let’s add the predicate [1] to both of those expressions:

1. /company/employee[1]/following-sibling::employee[1]
2. /company/employee[3]/preceding-sibling::employee[1]

When the value of a predicate is of a numeric type, as it is the case here, the predicate is called a numeric predicate. A numeric predicate is true if the value is equal to the context position and false otherwise. Then the question is: for each one of the two sequences, which item has as a context position equal to 1?

1. The first sequence is composed of Peter and Carl in that order, and Peter is the employee with context position equal to 1.
2. The second sequence is composed of John and Peter in that order, and here Peter, the second employee in the sequence, is the employee with context position equal to 1, not John which is the first employee in the sequence!

The reason for this potentially surprising result is that when you use a reverse axis, such as preceding-sibling, position is assigned in reverse order. So because a reverse axis is used, the context position of the last item in the sequence is 1.

You can think of the engine as assigning context position starting from the node where you start your search: if you are “going down”, as with following-sibling, context positions are assigned in document order, but if you are “going up” like with preceding-sibling, then context positions are assigned in reverse document order. Even if context positions are assigned differently depending on the type of axis you are using, the nodes returned by a path expression are always in document order.

Does this make more sense?

We have mentioned before how much we love Firebug, the Firefox extension for developers that lets you view, edit, and debug HTML, CSS, and JavaScript. Erik mentioned earlier here that the author of Firebug, Joe Hewitt, gave a presentation at Yahoo! and that you can watch or download the video of that presentation.

I finally got a chance to watch that video a couple of weeks ago and I had to share with you something I learnt about one feature of Firebug many of us have used in the past and that seemed to have disappeared at some point: the ability to watch events going to particular elements on the page. There used to be an “Events” tab, but that tab is no more. Now instead, you need to go to the HTML tab, locate the element you are interested in, right click on it, and choose Log Events. From that point, Firebug logs all the events dispatched to the element in the Console tab.

For instance, set Firebug to log events for an input field. Then type a key in that field. You will see the following sequence of events dispatched to the input field: keydown, keypress, and keyup. Then from the console, click on one of those events and Firebug will take you to the DOM tab, where you can see all the properties of that event. Neat, isn’t it?

It’s the weekend, our time for something non-technical. But even if we are not working, we can still think about work, can’t we? At least this is what Lise Belkin did in this New York Times article: Time Wasted? Perhaps It’s Well Spent. Amongst others, the article mentions a few points from an often cited 2005 Microsoft survey on productivity. On average we spend 45 hours at work every week, and deal with 45 emails every day. According to a separate poll conducted by Staples, 49% of business managers make calls and check email behind the wheel and 18% check their email in the bathroom (!).

So we do indeed work a lot. But we also think that a lot of this time is wasted. According to the same Microsoft survey, we spend 5.6 hours each week in meetings, and 71% of them are considered not productive. And out of the 45 hours we spend at work, we think 16 are unproductive. There seems to be a feeling of frustration
about our own productivity, and a sense that something can be done to make us more productive. But what?

Doing longer hours doesn’t work. Some feel that Getting Things Done (GDT) is our way to salvation. Belkin’s article points to another method implemented by 75% of the workforce at Best Buy’s corporate headquarters, which is called Result-Only Work Environment (ROWE). ROWE puts an emphasis on what is being produced, not how it is produced. ROWE is about results, not the how much time you spend to reach this result. What about you give a try to ROWE? Maybe you can start your next workday not by thinking that you will be at your desk for the next 8 hours, but with setting goals you want to reach during that day.