RE: XForms timer

Erik,

> This could certainly be in another specification that can be 
> used along with XForms, but I do think that somebody, 
> somewhere should standardize declarative markup to implement a timer.

For a while now we've been using a pre-processing stage on our forms, to add
features that are not directly supported in XForms and that we don't yet
want to add to formsPlayer until some standard is agreed upon. To give an
example, we want an author to be able to get 'Google suggest' style
functionality just by using a drop-box, but we don't want to go adding too
much to formsPlayer that takes it away from 'pure' XForms. But at the same
time we don't want to hand code these suggestion lists all over our forms,
since we want to use them all over the place. So we simply added an XSLT
pre-processing step that adds all the necessary models, instance,
submissions, keyboard event handlers, etc., to obtain suggestions from a
server and use them to create a list of choices.

Another example of the kind of functionality that gets used a lot is the use
of tabs; using xf:switch with @appearance="tabbed" as the hook, it's very
easy to use XSLT to turn the switch/case into a set of tabbed dialogs. (I
think you do this with Orbeon?)

So, here's the suggestion...why don't we have a set of pre-processing
stlyesheets that we can share and work on, that allow us to experiment with
new features, and during the course of that experimentation we can find out
what mark-up feels right, and of course how easy they would be to implement.
The idea would be that the output can still include XForms, so even if the
ultimate target is something like Orbeon or FormsFaces, you would feed the
resulting XForms (after the pre-process step) to those processors. In other
words, provided that you define any new features in terms of existing ones,
it should always work in any XForms processor.

To kick it off and see what people think, I've attached our XSLT for a
timer. You can have as many timers as you like in a form, and they can
either be repeating times or one-off timers.

To illustrate how to use a timer to create a clock, you would first create a
model with an instance to hold the time:

	[xmlns:t="http://www.w3.org/2006/xml-events/timer"]

	<xf:model id="mdl-clock">
		<xf:instance id="inst-clock">
			<time xmlns="" />
		</xf:instance>

Then, on initialisation you would start a timer going that fires the event
"tick" every second:

		<xf:action ev:event="xforms-ready">
			<t:setTimer
			 id="clock"
			 duration="1000" type="repeat"
			 target="mdl-clock" event="tick"
			/>
		</xf:action>

Finally, the handler for "tick" just sets the instance data to the current
time:

		<xf:action ev:event="tick">
			<xf:setvalue model="mdl-clock"
			 ref="instance('inst-clock')" value="now()" />
		</xf:action>
	</xf:model>

To use the time somewhere, just do this (you'll probably want to format
it!):

	<xf:output model="mdl-clock" ref="/time" />

and it will update every second.

The XSLT is pretty straightforward, and merely replaces the t:setTimer
element with the following call to script:

  <xsl:template match="t:setTimer">
    <xf:setvalue model="mdl-timeout" ref="instance('inst-timeout')"
     value="js:timer_setTimer(
       '{@id}', {@duration}, '{@type}', '{@target}', '{@event}'
     )"
    />
  </xsl:template>

We haven't added things like cancelTimer yet, but as you can see they would
be very easy to add. But the most important thing, I believe, is that with
such simple XSLT you can very easily experiment with new features, new
attribute values, even new elements, before deciding what should actually be
proposed as a 'standard'.

Any thoughts?

Regards,

Mark


Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
b: http://internet-apps.blogspot.com/
w: http://www.formsPlayer.com/

Download our XForms processor from
http://www.formsPlayer.com/