RE: On running a pre-processor [RE: XForms timer]

I see you're already on this...sorry about my last response.

I believe that there is considerable value in encouraging XForms
implementations to handle select/@enumeration='open' the way I proposed.
It's entirely within the recommendation; it uses the appearance
attribute as a hint; it uses the type system correctly; it is amenable
to event-based population as you type with incremental and events and
submission.  I'm pleased to hear from Erik that Orbeon already does
this.

I'd suggest that Erik and I write up a note either for www or for
exforms on this presentation.  

Authors can use this, as Gary suggests, for experimentation entirely
within the spec, while we gain experience valuable for the meta-level
intent-based authoring you describe, which of course an XSLT
transformation would be dandy for.

Leigh. 

-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
Behalf Of Mark Birbeck
Sent: Friday, May 19, 2006 4:15 AM
To: 'www-forms'
Subject: RE: On running a pre-processor [RE: XForms timer]


Hi Erik,

> Leigh's solution doesn't involve xforms:output and 
> xforms:repeat: just xforms:select1/@selection="open", 
> xforms:itemset, and xforms:submission.

Leigh didn't actually mention submission in his example, but I think we
agree that when people talk about 'Google suggest' they usually mean
that a
list is obtained from a server or something.

You're right that we can create the effect with select1 and submission,
and
I said that in the first part of my email:

> > Yes, you can of course use XForms to create an approximation of 
> > 'Google suggest' functionality, by using a combination of a 
> > submission, two instances, and a select1.

But my point is that we are asking the author to 'wire' these components
together; they have to create the submissions, the itemset, and so on.
And
if you have four or five of these suggestion lists on a form, that's a
lot
of 'wiring' you are asking an author to do.

I'm saying that what we really want is something that is as simple to
use as
this:

  <xf:input ref="a" suggestions="countries">
    <xf:label>Country:</xf:label>
  </xf:input>

'countries' might be a reference to a model, or something, but whatever
it
is, it indicates which 'selection list' to use, and the management of
that
list is done for you.

In other words, once we have recognised the *pattern*, we should wrap it
in
some convenient mark-up. (There is nothing in the notion of
'suggestions'
that implies a select1. And there is also nothing to say that your list
of
'country suggestions' should be the same as my list. Your list might
contain
previously entered values, plus some that come from your company
intranet...my list might contain entries that I've put into del.icio.us,
etc.)

But the implementation details are not my main point...it's how we going
go
about making this pattern available to authors once we've identified it.
There seem to me to currently be two courses of action open to us, and
neither is very good.

The first is to propose the @suggestions attribute for XForms version 2,
3,
4, or whatever; we'd then have discussions and arguments with everyone
about
what features it should support and so on. That's fine, and a good way
to
go, but we won't see anything in a specification any time before
mid-2007,
and we want this (and many other features) now.

The second way of proceeding is to simply add the attribute to
formsPlayer,
document clearly how the attribute indicates which set of submissions
and
instances to use, and then leave it to authors to decide whether they
use
the feature or not.

I don't like that approach, because I'd like people to be able to follow
our
tutorials and not have to keep looking over their shoulder as to whether
they are straying from the XForms specification or not.

So I'm suggesting a third way, which is to use a pre-processing step
which
will allow us to play with new features and learn a lot about how they
work,
before finally deciding which ones really are useful and which are not.
Provided that the output from the pre-processor is still XForms,
everything
will still work in any of the current processors, and therefore anyone
can
make use of the pre-processor.

(For those familiar with C++, you could say that what we're doing is
creating an XForms Template Library that mirrors the C++ Standard
Template
Library (STL).)


> If I understand right, his solution (and ours in OPS) just 
> requires that the XForms engine then display a nice 
> autocompletion widget.

Sure...but when I mentioned suggestions (and other features) it was in
the
context of a discussion about how to make new features available to
authors
without either breaking standards or waiting two years. It certainly
wasn't
about how to implement suggestions...I showed how to do that in my blog
over
a year ago [1], and the *technique* is certainly no mystery. But to
stress
again...my point is that even a simple version of this technique is more
than we need to ask an author to have to do.


> Your solution is actually building the widget in XForms, 
> which is a different approach.

I'm not interested in the specifics of creating a suggestion control; I
just
used it as an example in a broader discussion about having a
pre-processing
step. As it happens, I do think it makes it easier to define, test and
modify widgets if they are defined in terms of other widgets, but that's
really tangential to this topic.

Regards,

Mark

[1]
http://internet-apps.blogspot.com/2005/04/xforms-patterns-incremental-an
d-go
ogle.html


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/

Received on Friday, 19 May 2006 22:53:32 UTC