Feed items

 A customer asked me recently how they could use XForms constructs to create a form that dynamically populates a table with available products that can be ordered based on selection of a product provider.  In this case, the customer also wanted to have the product order list be editable once provided, allowing the user to delete rows or even to add more rows to the product order table initially provided for the selected store.  Seemed like another good example for the blog.

So, suppose you have a main data instance for a form that looks something like this:

Each product has a name, code, and cost, and the end-user will indicate the quantity of the product they desire. The above data corresponds to showing an empty table until the user chooses a "storeID". Here is the XForms user interface markup for showing a four column table having as many rows as there are "product" elements in the data.

Initially, the table will have just one row of four user interface elements containing essentially empty or zero values.  However, now lets hook up something that allows us to pick a store ID so we can fill the table with an initial order of products.  Now, it would be reasonable in a full form application to obtain the list of stores from a web service and then get the starting list of products for the selected store from another web service.  Getting data from web services is not an important but orthogonal point, so in this mock-up, I'm going shorten all of that down to just having the data available in a format that looks like this:

The user is provide the ability to select a store using the "select1" control, and the list of stores can be easily picked up from the data using an "itemset".  Once the user makes a choice, an "xforms-value-changed" event on the select1 could be used to run a web service to get the product list, but here we'll just mock that up with an "insert" because the data is already available:

The "ref" on the select1 tells where to store the resulting store selection.  The "nodeset" on the itemset tells where to get the list of stores from.  The "ref" attribute on the xforms:label in the itemset tells what to show for each item in the list of choices, and the "ref" xforms:value tells what to store in the data ("storeID" due to the ref on select1) when a particular list choice is selected.

The "xforms-value-changed" event handler recognizes when a selection has been made, since that results in a value change on the "storeID" data node.  The delete action gets rid of any preceding list, and then the insert action copies the list of products for the selected store into the main data.  In particular notice that the XPath predicate in the origin attribute selects a store element to copy based on the store element's ID attribute matching the selected store identity placed in the storeID element by the value change behavior of the select1.

Once this insert occurs, the xforms:repeat is automatically responsive to the change of the data.  It generates a four column row of user interface controls for each of the inserted product elements.  For example, if the user picks store A, then they get three rows for Widgets, Gadgets and Trinkets.  If they then pick store D, the form automatically adjusts to five rows for Lockets, Pockets, Rockets, Sprockets and Sockets.

Once the table content has been set with the product list for a particular store, the user may choose to add or delete rows from the table. Here is an additional instance that would be used to store the data prototype for a product:

A button to add a row to the repeat table would trigger the addition using the following XForms markup:

This simply inserts a product prototype, obtained via the origin attribute, into the location defined by the context and nodeset attributes at a position corresponding to the row of the table that current has the input focus.  When the data is inserted, the repeat table automatically generates another four-column row of user interface elements to allow the user to interact with the new data.

Similarly, a button to delete a row from the repeat table would trigger the deletion using the following XForms markup:

This simply deletes the product data element corresponding to the row of the table that currently contains the input focus.  The row of user interface elements that presented this data is automatically deleted.  As the next step of the action script, if the product list data becomes empty due to the prior delete, a new empty product prototype is inserted. The repeat table then presents one row of interface elements, so this extra insert ensures the user is never left with an unsightly empty table.

Last but not least, the actions scripts of both of the triggers above end with an xforms:setfocus action.  This is because pressing a button, be it to add or delete an item from a table, transfers focus to the button.  That's just how the web works.  But the user's focus is not really on the buttons; those are just tools.  The user's focus is on changing the table, so it is a better user experience to push the focus back to the repeat table.