282840 - Implement @selection for select

Status: RESOLVED WONTFIX

(Core Graveyard :: XForms, defect)

Description

[Olli Pettay [:smaug][[e-mail]]]

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

This is done for select1, 
changing summary
"Implement @selection for select/select1" ->
"Implement @selection for select"

Comment 2

[alexander :surkov (:asurkov)]

Is there any suggestions how it can be realized? I have in view controls behaviour/looks when @selection is open. As I understand user should be able to specify some new values for select control. How can it be achieved from interface view point? Should user be able to modify some values or remove them?

Comment 3

[Doron Rosenberg (IBM)]

The easiest way would be to add a input above the select where the user can enter stuff and press enter, which will add it.

Comment 4

[aaronr]

(In reply to comment #3)
> The easiest way would be to add a input above the select where the user can
> enter stuff and press enter, which will add it.
> 

But will it add the item(s) to the list for the life of the form?  What if the instance is 'reset'?

Comment 5

[Doron Rosenberg (IBM)]

(In reply to comment #4)
> (In reply to comment #3)
> > The easiest way would be to add a input above the select where the user can
> > enter stuff and press enter, which will add it.
> > 
> 
> But will it add the item(s) to the list for the life of the form?  What if the
> instance is 'reset'?
> 

If the data is supposed to stay there for ever, would be easy to do (store in a seperate array).

Comment 6

[aaronr]

(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > The easiest way would be to add a input above the select where the user can
> > > enter stuff and press enter, which will add it.
> > > 
> > 
> > But will it add the item(s) to the list for the life of the form?  What if the
> > instance is 'reset'?
> > 
> 
> If the data is supposed to stay there for ever, would be easy to do (store in a
> seperate array).
> 


I don't think that items added by the user with @selection="open" to still be there after a xforms-reset, though.  Even though xforms-reset is targeted at the model to make sure that all of its contained instance documents are set back to their initial values (which conceptually wouldn't affect a control that reflects non-instance data), I think that the 'real' purpose behind it is to be able to reset a form just like you can do in html forms.  A good question for the WG, though.  Allan?

Comment 7

[Allan Beaufour]

(In reply to comment #6)
> I don't think that items added by the user with @selection="open" to still be
> there after a xforms-reset, though.  Even though xforms-reset is targeted at
> the model to make sure that all of its contained instance documents are set
> back to their initial values (which conceptually wouldn't affect a control that
> reflects non-instance data), I think that the 'real' purpose behind it is to be
> able to reset a form just like you can do in html forms.  A good question for
> the WG, though.  Allan?

Yes, I think xforms-reset should _reset_ back to initial data state, so the user entered values should not be saved.

I must admit that I've "just" seen selection="open" for select as the same as select1, just with the posibility of writing multiple (space seperated) values in the input.

The spec. states:
"For open selections: If the initial instance values match the storage value specified by one or more of the items, the all such matching items are selected. If the initial instance values do not match the storage value specified by one or more of the items, all such non-matching items are included as selected values, as if entered through free entry. Free entry text is handled the same as form control input 8.1.2 The input Element, possibly in multiplicity"

That does not contradict my understanding... but it's not validating it either.

Is there a problem in just "copying" the select1 understanding of it?

Comment 8

[Doron Rosenberg (IBM)]

So we need to change one of the interfaces xbl widgets inherit from to contain a "reset" method or such.

Comment 9

[Leigh L. Klotz, Jr.]

 (In reply to comment #6)
> Even though xforms-reset is targeted at the model to make sure that all of its contained instance documents are set
> back to their initial values (which conceptually wouldn't affect a control that
> reflects non-instance data), I think that the 'real' purpose behind it is to be
> able to reset a form just like you can do in html forms.  A good question for
> the WG, though.  Allan?

Note that select and select1 can participate in multiple models, and in particular, the itemset can come from one model and the ref from the other, so some thought needs to be given to what happens if you want to propagate a reset on the model containing the itemset to a select1 whose ref points to a different model which is not reset.

Also note that the larger topic of UI resets (as opposed to instance data resets) includes what to do about initial states for xf:switch as well, so consulting the WG would be a good idea. 

(I had originally proposed undo instead of reset, but we threw it out because of the difficulties in undoing setvalue and other side-effects in event handlers, which would require authors pairing each action with an undo action.)

Comment 10

[aaronr]

Attachment: simple testcase

simple testcase.  Doesn't do anything special in Novell, XSmiles or formsPlayer, so I'm guessing that no one has implemented it, yet.

Comment 11

[aaronr]

Also need to consider what to do if user types in "foo" and "foo" is later added to the itemset through another action.  Should there now be two foo's or just the one from the itemset?  More straight to the point -> do we allow a user to enter an item that is already on the list?  Or do we ensure that the user entered items NOT duplicate existing items?

Comment 12

[Leigh L. Klotz, Jr.]

One quite reasonable idea for open select if the lexical value space supports it (e.g., is declared to be NCName) is to present appearance="compact" as a typein box with completion.  Mark Birbeck has written a blog entry on this topic, though he implemented it using a select and a dynamic itemset for completion.  This type of completion-via-popup UI is quite a popular JavaScript application these days (Google Suggest, Delicious tags completion), and the semantics of it are really just <select appearance="compact" selection="open"> with a specified itemset, and bound to a datatype that has space delimiters.

Comment 13

[Allan Beaufour]

(In reply to comment #12)
> One quite reasonable idea for open select if the lexical value space supports
> it (e.g., is declared to be NCName) is to present appearance="compact" as a
> typein box with completion.  Mark Birbeck has written a blog entry on this
> topic, though he implemented it using a select and a dynamic itemset for
> completion.  This type of completion-via-popup UI is quite a popular JavaScript
> application these days (Google Suggest, Delicious tags completion), and the
> semantics of it are really just <select appearance="compact" selection="open">
> with a specified itemset, and bound to a datatype that has space delimiters.

I vote for that. Supporting "completion-via-popup" directly would be _really_ nice.

Comment 14

[aaronr]

works for me.  Can someone ref a page that has a similar control so that we can see what it looks like?

Comment 15

[Leigh L. Klotz, Jr.]

XForm has long left it up to processors how to present the ui for an open enumeration with an existing itemset as completion choices.  Below are the UI choices that non-XForms systems have made to present this same case.  Consistency in GUI systems is helpful, and it may be that making similar UI presentation choices will result in a better user experience:

http://www.google.com/webhp?complete=1&hl=en
You'll need to sign up for an account to get this to work:
http://del.icio.us/YOURUSERNAMEHERE?v=4&noui&url=http://www.mozilla.org
Here's the same thing but with controls for the choices shown as well as completion:
http://del.icio.us/YOURUSERNAMEHERE?v=4&noui&url=http://www.mozilla.org

Here is an implementation of select/@selection='open' done in XForms by Mark Birbeck of x-port.net in his FormsPlayer XForms processor:
Mark's example uses an input and a select1.  The itemset of the second select1 is populated during typing in the input by using an xf:send from the incremental value of the input, and the action on the select1 items completes the typing in the input.  

The dynamic xf:send part is a separate feature; the recommendation here is merely a UI presentation for the static condition of an itemset in select when selection='open' and appearance='minimal', resulting in a simple typein box with some kind of pop-up display of completion choices.  Again, the mechanism by which the itemset gets populated is immaterial to this feature, though really cool...

Comment 16

[Leigh L. Klotz, Jr.]

http://internet-apps.blogspot.com/2005/04/xforms-patterns-incremental-and-google.html

Comment 18

[David Bolter [:davidb] (NeedInfo me for attention)]

RIP xforms