- From: John Boyer <boyerj@ca.ibm.com>
- Date: Tue, 13 Dec 2005 10:01:38 -0800
- To: ava@vaz.ru
- Cc: www-forms@w3.org, www-forms-request@w3.org
- Message-ID: <OFF5E7C42C.C74D0DA3-ON882570D6.00623B25-882570D6.0063072D@ca.ibm.com>
Yes, understood that the problem you face with XForms 1.0 is still outstanding. Just wanted to migrate away from 'duplicate'. As modifications to insert, you might see more of this start to show up sooner in other processors. However, as to your larger question, note that you can use a little trickery with model relevance to help with at least some of your duplicate problems, especially the ones about replacing data with a default instance. If you put the default data structure under the same parent and make it non-relevant, then it will be stripped out on submission. Also, it isn't pretty, but you can copy data with setvalue one value at a time from raw instance data into a separate instance containing a soap envelope. You would do this on xforms-submit. This only breaks when your web service accepts repeated data. Same story handling the soap response. Use the submission instance attribute to target the response to a separate instance from the instance containing the soap request envelope. Then, on xforms-submit-done, use setvalue to copy string by string result to some raw data. Again breaks on repeated data. If you have repeated data on request or response, then you're going to have to use the instances containing the soap envelopes *as* the primary instances. On the UI side, you'd use a group with a UI binding that drills past the soap envelope elements so your UI controls still think they're talking to raw data. The only downside is that if the soap request has to contain repeated data, then there's no way to reinitialize it with Xforms 1.0. Cheers, John Boyer Alexander Anokhin <ava@vaz.ru> Sent by: www-forms-request@w3.org 12/13/2005 03:53 AM Please respond to ava To John Boyer/CanWest/IBM@IBMCA cc www-forms@w3.org, www-forms-request@w3.org Subject Re: xf:duplicate emulation John Boyer wrote: > > In the next day or two, the new 1.1 working draft will appear. > In it, you'll see that we've scrapped duplicate and destroy in favor of > simple modifications of insert and delete that cover the functionality > of duplicate and destroy. > > The main problems for insert were how to identify a nodeset that > could become empty and how to get a prototypical subtree from > someplace else. > > By simply adding the new attributes to insert rather than inventing a > new action, we found we could achieve the desired results. We also > found that insert's separation of the target location into nodeset, at > and position made it easier than was the case with duplicate to > express the most common use case of inserting a new homogeneous > collection item into a repeat after the currently indexed repeat item. > Also, an insert with a target of the root document element of the > instance results in replacing the instance. > > Details and examples to be published shortly. > Thanks for quick reply, John. Completly agree, but the problem is to achieve such functionality in XForms 1.0 only, since very few client-side processors implements 1.1 WD (afaik FormsPlayer only?). As i see for now it can't be done without using of Javascript to make FireFox XForms extension behave like in 1.1 WD. Main problem of client-side XForms for me is poor portability. Sutuation seems like in HTML world while ago - we've one spec and many specialists, whose primary job is to make HTML-pages looks similar in different browsers. So articles like "How to make crossbrowser XForms" makes me worry for the future of this technology ;). and sorry for casual english. -- Alexander Anokhin AVTOVAZ JSC email: ava@vaz.ru icq: 123275798
Received on Tuesday, 13 December 2005 18:02:04 UTC