XForm Repeats

In this entry I talk about one method for dealing with empty repeats. Here is the method I ended up using:

Within the xforms:repeat add the following two xforms:triggers:

 <xforms:trigger class="delete" appearance="minimal"
   ref="self::node()[count(//dc:title) > 1]">
	<xforms:label>Remove</xforms:label>
	   <xforms:action ev:event="DOMActivate">
		<xforms:delete nodeset="instance('metadata')//dc:title"
		   at="index('repeat.title')"/>
	   </xforms:action>
 </xforms:trigger>

 <xforms:trigger class="delete" appearance="minimal"
   ref="self::node()[count(//dc:title) < 2]">
	<xforms:label>Remove</xforms:label>
	     <xforms:action ev:event="DOMActivate">
		<xforms:setvalue ref="instance('metadata')//dc:title"
		   at="index('repeat.title')" value=""/>
	     </xforms:action>
 </xforms:trigger>

This above code essentially creates two if statements, swapping in the appropriate action based on the number of dc:title elements in the document. The first statement in the ref attribute of xforms:trigger only creates the delete action if there is more than one title elements in the repeat. The second xforms:trigger comes into play if there is only one title element in the repeat, this uses a setvalue action to clear the element without deleting. This prevents the last dc:title element from being deleted from the document but there still needs to be at least one dc:title element in the initial document.

I prefer this method because I didn’t like inserting an empty “template” element for every repeated element as in the previous example. I also ran in to problems with the delete removing the wrong element in the repeat and, although I’m sure it was just buggy code on my part, I find this to be a simpler solution. Of course I still have to insert an empty element into the initial data if the selected document doesn’t have the element.

I think both of these solutions are just patches until XForms 1.1 is supported by Firefox. XForms 1.1 has a much more elegant solution to the empty repeat problem which allows the use of a template instance that can be used to insert new elements/nodes. This would eliminate the need to add empty elements and it could also be very handy for simplifying potentially complex forms into manageable interfaces. (I have some thoughts on how to use this with a MODS XForm.)

For those who don’t want to wait for the Firefox extension to catch up (it sounds like they have enough to keep them busy and are not looking at implementing 1.1 specs until it is completed), Orbeon has implemented some of XForms 1.1, including the contex and origin attributes that allow inserting elements from a template into an empty node.

Advertisements

2 Responses to “XForm Repeats”

  1. Mark Birbeck Says:

    Hi,

    formsPlayer 1.5 has an almost complete implementation of XForm 1.1, too. Some of the most interesting stuff in 1.1 is actually the set of new features to allow more control over submissions (like setting headers, dynamic URLs, etc.).

    You might be interested in XForms is coming of age with version 1.1.

    Regards,

    Mark

    Mark Birbeck, formsPlayer
    http://www.formsPlayer.com/

  2. wsalesky Says:

    Hi Mark, thanks for the heads up on formsPlayer and XForms 1.1. I had been aware of formsPlayer (I follow your blog, and find the formsPlayer website to be very helpful for XForms tips) but have not tried it yet. It seems if I want to take advantage of XForms 1.1 this would be a great time to give it a try.

    -Winona

Comments are closed.


%d bloggers like this: