Re: Get the values of an element and combine them
John Boyer <[email protected]> Tue, 25 Feb 2014 15:20:18 -0800
| Newsgroups | gmane.comp.web.xforms |
|---|---|
| Message-ID | <OFFC4ACC3B.E6018A92-ON88257C8A.007F23DD-88257C8A.008034B5@ca.ibm.com> |
This is a multipart message in MIME format. --=_alternative 0080346988257C8A_= Content-Type: text/plain; charset="US-ASCII" 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 | [email protected] From: "Steven Pemberton" <[email protected]> To: "Steven Pemberton" <[email protected]>, John Boyer/CanWest/IBM@IBMCA, Cc: "Jean-Baptiste Pressac" <[email protected]>, [email protected], [email protected] 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 <[email protected]> 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 | [email protected] From: "Steven Pemberton" <[email protected]> To: [email protected], [email protected], "Jean-Baptiste Pressac" <[email protected]>, 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 <[email protected]> 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, --=_alternative 0080346988257C8A_= Content-Type: text/html; charset="US-ASCII" <font size=2 face="sans-serif">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.</font> <br> <br><font size=2 face="sans-serif">Constructing actual XML instance data is a way to solve (agreed) ghastly problem that structured data is in the unstructured character data. </font> <br> <br><font size=2 face="sans-serif">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.</font> <br> <br><font size=2 face="sans-serif">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.</font> <br> <br><font size=2 face="sans-serif">John M. Boyer, Ph.D.<br> IBM Distinguished Engineer & IBM Master Inventor<br> @johnboyerphd | [email protected]<br> </font> <br> <br> <br> <br><font size=1 color=#5f5f5f face="sans-serif">From: </font><font size=1 face="sans-serif">"Steven Pemberton" <[email protected]></font> <br><font size=1 color=#5f5f5f face="sans-serif">To: </font><font size=1 face="sans-serif">"Steven Pemberton" <[email protected]>, John Boyer/CanWest/IBM@IBMCA, </font> <br><font size=1 color=#5f5f5f face="sans-serif">Cc: </font><font size=1 face="sans-serif">"Jean-Baptiste Pressac" <[email protected]>, [email protected], [email protected]</font> <br><font size=1 color=#5f5f5f face="sans-serif">Date: </font><font size=1 face="sans-serif">02/25/2014 02:15 AM</font> <br><font size=1 color=#5f5f5f face="sans-serif">Subject: </font><font size=1 face="sans-serif">Re: Get the values of an element and combine them</font> <br> <hr noshade> <br> <br> <br><font size=1>On Mon, 24 Feb 2014 19:10:10 +0100, John Boyer <[email protected]> wrote:<br> </font> <br><font size=2 face="sans-serif">A couple of minor points:</font><font size=1> <br> </font><font size=2 face="sans-serif"><br> 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.</font><font size=1> </font> <br><font size=1>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.</font> <br> <br><font size=2 face="sans-serif">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:</font><font size=1> </font><font size=2 face="sans-serif"><br> - 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</font><font size=1> </font><font size=2 face="sans-serif"><br> - Similar issue if someone does a setvalue on the spatial datum, they must do parallel setvalue operations on the instance data</font><font size=1> </font><font size=2 face="sans-serif"><br> - Schema validity results for the spatial datum do not transfer to the controls bound to temporary instance data into which copies have been made.</font><font size=1> </font><font size=2 face="sans-serif"><br> - Model item properties like readonly, required, constraint placed on the spatial datum do not transfer, and so must be recoded as more binds</font><font size=1> </font><font size=2 face="sans-serif"><br> - If this construct is within a repeat, then all of these special cases have increased complexity in light of row insertions</font><font size=1> </font> <br><font size=1>I think you're being too negative. The root of the problem is unstructured data. Whoever designed the format</font> <br> <br><tt><font size=2> <dcterms:spatial xsi:type="dcterms:Point">east=456; north=123;</dcterms:spatial></font></tt> <br> <br><font size=2>should be forced to attend the beginners class on how to structure data in XML. It should be at least</font> <br> <br><font size=2> </font><tt><font size=2><dcterms:spatial xsi:type="dcterms:Point"><east>456</east><north>123</north></dcterms:spatial></font></tt> <br><font size=1>or</font> <br><font size=2> </font><tt><font size=2><dcterms:spatial xsi:type="dcterms:Point" east="456" north="123"/></font></tt> <br> <br><font size=2>but hiding the data in a string is ghastly.</font> <br> <br><font size=2>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. </font> <br> <br><font size=2>Steven</font> <br> <br><font size=1><br> </font><font size=2 face="sans-serif"><br> Cheers,</font><font size=1> </font><font size=2 face="sans-serif"><br> John M. Boyer, Ph.D.<br> IBM Distinguished Engineer & IBM Master Inventor<br> @johnboyerphd | [email protected]</font><font size=1><br> <br> <br> <br> </font><font size=1 color=#5f5f5f face="sans-serif"><br> From: </font><font size=1 face="sans-serif">"Steven Pemberton" <[email protected]></font><font size=1> </font><font size=1 color=#5f5f5f face="sans-serif"><br> To: </font><font size=1 face="sans-serif">[email protected], [email protected], "Jean-Baptiste Pressac" <[email protected]>, </font><font size=1 color=#5f5f5f face="sans-serif"><br> Date: </font><font size=1 face="sans-serif">02/24/2014 08:55 AM</font><font size=1> </font><font size=1 color=#5f5f5f face="sans-serif"><br> Subject: </font><font size=1 face="sans-serif">Re: Get the values of an element and combine them</font><font size=1> <br> </font> <hr noshade><font size=1><br> <br> </font><tt><font size=2><br> Here is an example of how I would do it:<br> <br> </font></tt><a href=http://www.cwi.nl/~steven/forms/dcterms.xml><tt><font size=2 color=blue><u>http://www.cwi.nl/~steven/forms/dcterms.xml</u></font></tt></a><tt><font size=2><br> <br> I'm not sure of all the requirements of your problem, but what I do is:<br> <br> 1. At initialisation, extract the values of east and north from your <br> input spatial value:<br> <br> <action ev:event="xforms-ready"><br> <setvalue ref="east" <br> value="substring-before(substring-after(instance('in')/spatial, 'east='), <br> ';')"/><br> <setvalue ref="north" <br> value="substring-before(substring-after(instance('in')/spatial, 'north='), <br> ';')"/><br> </action><br> <br> 2. Bind a calculation to the output spatial value:<br> <br> <bind ref="spatial" calculate="concat('east=', ../east, '; north=', <br> ../north, ';')"/><br> <br> I hope this helps.<br> <br> Steven Pemberton<br> <br> On Thu, 20 Feb 2014 16:13:50 +0100, Jean-Baptiste Pressac <br> <[email protected]> wrote:<br> <br> > Hello,<br> > I would like to use Xform to edit the following element :<br> > <dcterms:spatial xsi:type="dcterms:Point">east=456;<br> > north=123;</dcterms:spatial><br> ><br> > I could use :<br> > <xf:input ref="dcterms:spatial[@xsi:type='dcterms:Point']"<br> > class="dcterms:spatial"><br> > <xf:label>Latitude / Longitude:</xf:label><br> > </xf:input><br> ><br> > But is there a way to display two inputs to let the user enter the east<br> > value and the north value separately ?<br> ><br> > Thanks,<br> </font></tt><font size=1><br> </font> <br><font size=1><br> <br> </font> <br> --=_alternative 0080346988257C8A_=--