RE: A few XForms Questions...

I'd like to return to this discussion...

From: Micah Dubinko 
> 
> Hi Dan,
> 
> Your project looks very interesting. You were asking about
> >1) The ability to treat a select box as a "container."
> 
> Interesting. I assume the lists have to be bound to 
> "compatible" XML. In
> other words, you wouldn't want to put an <apple> into a list 
> of <orange>s.
> :-)
> 
> I haven't tried it, but this should be possible in XForms with a few
> <buttons> triggering XForms Actions <insert>, <setValue>, and 
> <delete>.

If you go to Dan Switzer's site, to actually see what he is describing, then you realize that this is functionally equivalent to <selectMany>. It is simply a different UI presentation than currently afforded by the selectUI attribute. I have used this approach before, and I call this UI control a "chooser." Perhaps this can be new selectUI attribute value. 

On the other hand, I have a complex form with 3 columns of listboxes where items are moved between some and copied between others. In that case, perhaps <insert> and <delete> may apply. However, functionally they are not necessarily mapped to directly editable data sets. Specifically, one listbox is not meant to edit its underlying data even though its item set changes. Perhaps this listbox comes from a different model than the one that gets submitted?
 
> >2) The ability to create n-related select boxes.
> 
> We do specify heirarchial selection items, but that's not exactly what
> you're talking about. OK, I see
> http://www.pengoworks.com/qForms/docs/examples/n-related_selec
> tboxes.htm
> 
> Again, I haven't tried this specific task, but it should be 
> possible. In
> fact, with partial submit and replace="instance" for incoming data, it
> should even be possible for the subsequent levels to come 
> from the server.
> 

Similar to the above, this is functionality equivalent to a selectOne with multiple levels of <choices> elements. Again, the selectUI attribute does not specifically accomodate this presentation. However, one may choose to implement the selectUI="listbox" in this way if there is more than one <choices>. Another implementation, may use a listbox where <choices> captions are listbox items that can not be selected, and its items are indented.
  
In fact, other common ways to present this are an expandle/collapsible tree or a categorized icon bar (popularized by Outlook). A tree containing checkboxes could be used for a selectMany. (The categorized bar does not need icons.)

The point is there are many representations. In my XForms implementation, I will probably extend the selectUI attribute to them to our designers needs.

> Thanks,
> 
> .micah
> 
> -----Original Message-----
> From: Dan G. Switzer, II 
> Sent: Tuesday, April 02, 2002 7:11 AM
> To: www-forms@w3.org
> Subject: A few XForms Questions...
> 
> 
> I had a few general questions that I haven't seen directly answered on
> the XForms site. I've been developing an open source JavaScript API
> (called qForms) for about 18 months. While XForms & qForms are not
> directly related, there are similarities in that we're both trying to
> provide a consistent method for handling/creating forms.
> 
> As flexible as XForms is, there are a few things that seems 
> to be absent
> from the XForms spec, which seem to be some of the most used 
> features of
> qForms:
> 
> 1) The ability to treat a select box as a "container." qForms 
> allows you
> to bind select boxes together so that items can be moved from 
> one select
> box to another. Also, items marked as a "container" post all 
> the options
> in the select box back to the server.
> 
> 2) The ability to create n-related select boxes. This is the 
> ability to
> relating select boxes together so that the value in one select box
> changes depending open a parent select box.
> 
> Are this features there and I'm just missing them, or are they outside
> the scope of what XForms is targeting to do? I'm really interested in
> following how XForms progresses, because I see a lot of 
> interoperability
> between the two--especially since the qForms engine will work in NS3+.
> 
> Anyway, looking forward to what's to come.
> 
> -Dan
> 
> qForms JavaScript API:
> http://www.pengoworks.com/qforms/
> 
> 
> 
>

Received on Thursday, 9 May 2002 15:36:34 UTC