Re: xf:duplicate emulation

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