- From: John Boyer <boyerj@ca.ibm.com>
- Date: Tue, 25 Feb 2014 15:20:18 -0800
- To: "Steven Pemberton" <Steven.Pemberton@cwi.nl>
- Cc: "Jean-Baptiste Pressac" <Jean-Baptiste.Pressac@univ-brest.fr>, public-xformsusers@w3.org, "Steven Pemberton" <Steven.Pemberton@cwi.nl>, www-forms@w3.org
- Message-ID: <OFFC4ACC3B.E6018A92-ON88257C8A.007F23DD-88257C8A.008034B5@ca.ibm.com>
Well, I agree that the root of the problem is unstructured data, but that doesn't support the characterization of "negative". A better word would be realistic. Constructing actual XML instance data is a way to solve (agreed) ghastly problem that structured data is in the unstructured character data. It's just that doing so sometimes involves as little effort as you depicted, when in a simple test case, but anyone going down this road should be aware of the additional complexities that they must accommodate in order to get all the rest of the advertised benefits of XForms, especially when scaling the technique from test case to production application. Trying to create a reusable pattern, or "best practice", out of this is frustrated by a person's attempt to use the technique in combination with other aspects of the language in different applications. It breaks in one way in application A and in another way in application B. When this happens, it is an indication that more direct language support is needed, regardless of what we think about the people who designed the data schema. In fairness to whomever we characterized as having created a ghastly design, these things come up all over the place, even other W3C specs. For example, take a look at xsd:date, or better still xsd:dateTime. In order to provide a nice control that allows a person to input all the pieces of that value, cracking that out into instance data is just not a very scalable approach, especially if you're using these in a repeat that collects the dates and times of something like expenses, patient intake, etc. John M. Boyer, Ph.D. IBM Distinguished Engineer & IBM Master Inventor @johnboyerphd | boyerj@ca.ibm.com From: "Steven Pemberton" <Steven.Pemberton@cwi.nl> To: "Steven Pemberton" <Steven.Pemberton@cwi.nl>, John Boyer/CanWest/IBM@IBMCA, Cc: "Jean-Baptiste Pressac" <Jean-Baptiste.Pressac@univ-brest.fr>, public-xformsusers@w3.org, www-forms@w3.org Date: 02/25/2014 02:15 AM Subject: Re: Get the values of an element and combine them On Mon, 24 Feb 2014 19:10:10 +0100, 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. In fact this example revealed to me a place where I would like *really* to have an event: after instance construction, but before recalc etc are done. 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 I think you're being too negative. The root of the problem is unstructured data. Whoever designed the format <dcterms:spatial xsi:type="dcterms:Point">east=456; north=123;</dcterms:spatial> should be forced to attend the beginners class on how to structure data in XML. It should be at least <dcterms:spatial xsi:type="dcterms:Point"><east>456</east><north>123</north></dcterms:spatial> or <dcterms:spatial xsi:type="dcterms:Point" east="456" north="123"/> but hiding the data in a string is ghastly. But my approach is to construct a proper XML instance from the unstructured data right at the start, and then treat the data as it should be treated. You can keep the unstructured data alive with a bind, and that can be your return value. Steven 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 Tuesday, 25 February 2014 23:20:53 UTC