W3C home > Mailing lists > Public > public-xformsusers@w3.org > February 2014

Re: Get the values of an element and combine them

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Mon, 24 Feb 2014 15:15:23 -0800
Message-ID: <CAAc0PEUsRerFgrdHM1YDvdZ43kpcChzuSBW2qmSxz0r4ZQ9trg@mail.gmail.com>
To: John Boyer <boyerj@ca.ibm.com>
Cc: Steven Pemberton <Steven.Pemberton@cwi.nl>, Jean-Baptiste Pressac <Jean-Baptiste.Pressac@univ-brest.fr>, "public-xformsusers@w3.org" <public-xformsusers@w3.org>, "www-forms@w3.org" <www-forms@w3.org>
All,

Here is an example using a component approach (works in Orbeon):

The component:

https://gist.github.com/ebruchez/9194679

Use of the component:

https://gist.github.com/ebruchez/9194725

You can try it here:

http://goo.gl/kA8SJa

Works with all types of updates of the data, and within repeats. As
John implies, that's what components and encapsulation give you over
plain XForms. Too bad we haven't standardized that yet!

Regards,

-Erik

On Mon, Feb 24, 2014 at 10:10 AM, John Boyer <boyerj@ca.ibm.com> wrote:
> A couple of minor points:
>
> 1) It's typically better to use xforms-model-construct-done so that the data
> values are available to the UI when it is first created, rather than having
> any kind of value change.
>
> 2) The reason I don't usually push this approach is that, you're right, it
> doesn't account for many use cases in the lifecycle of the data.  For
> example:
> - If a new result is obtained from a REST or web service by an xforms
> submission, then the xforms submit done must also do the same copy
> operations
> - Similar issue if someone does a setvalue on the spatial datum, they must
> do parallel setvalue operations on the instance data
> - Schema validity results for the spatial datum do not transfer to the
> controls bound to temporary instance data into which copies have been made.
> - Model item properties like readonly, required, constraint placed on the
> spatial datum do not transfer, and so must be recoded as more binds
> - If this construct is within a repeat, then all of these special cases have
> increased complexity in light of row insertions
>
> Cheers,
> John M. Boyer, Ph.D.
> IBM Distinguished Engineer & IBM Master Inventor
> @johnboyerphd | boyerj@ca.ibm.com
>
>
>
>
> From:        "Steven Pemberton" <Steven.Pemberton@cwi.nl>
> To:        public-xformsusers@w3.org, www-forms@w3.org, "Jean-Baptiste
> Pressac" <Jean-Baptiste.Pressac@univ-brest.fr>,
> Date:        02/24/2014 08:55 AM
> Subject:        Re: Get the values of an element and combine them
> ________________________________
>
>
>
> Here is an example of how I would do it:
>
>                 http://www.cwi.nl/~steven/forms/dcterms.xml
>
> I'm not sure of all the requirements of your problem, but what I do is:
>
>                 1. At initialisation, extract the values of east and north
> from your
> input spatial value:
>
>                     <action ev:event="xforms-ready">
>                                  <setvalue ref="east"
> value="substring-before(substring-after(instance('in')/spatial, 'east='),
> ';')"/>
>                                  <setvalue ref="north"
> value="substring-before(substring-after(instance('in')/spatial, 'north='),
> ';')"/>
>                     </action>
>
>                 2. Bind a calculation to the output spatial value:
>
>                     <bind ref="spatial" calculate="concat('east=', ../east,
> '; north=',
> ../north, ';')"/>
>
> I hope this helps.
>
> Steven Pemberton
>
> On Thu, 20 Feb 2014 16:13:50 +0100, Jean-Baptiste Pressac
> <Jean-Baptiste.Pressac@univ-brest.fr> wrote:
>
>> Hello,
>> I would like to use Xform to edit the following element :
>> <dcterms:spatial xsi:type="dcterms:Point">east=456;
>> north=123;</dcterms:spatial>
>>
>> I could use :
>> <xf:input ref="dcterms:spatial[@xsi:type='dcterms:Point']"
>> class="dcterms:spatial">
>>      <xf:label>Latitude / Longitude:</xf:label>
>> </xf:input>
>>
>> But is there a way to display two inputs to let the user enter the east
>> value and the north value separately ?
>>
>> Thanks,
>
>
Received on Monday, 24 February 2014 23:16:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:37:43 UTC