> On Jul 18, 2017, at 8:48 AM, C. M. Sperberg-McQueen > <cms...@blackmesatech.com> wrote: > > Trying to implement a new functionality I thought would be simple, > I am running into unexpected difficulties with the xf:select widget. > > I have put a sample form at > > http://www.blackmesatech.com/2017/07/testcase/index.xml > > Several problems are arising: > > - First and foremost, the menu displayed by the following widget > appears to be empty of text, although xf:output statements inserted > for diagnostic purposes appear to show that the XPath expressions > used are correct. > > <xf:select ref="p[@id='select']/@items"> > <xf:itemset nodeset="list/item"> > <xf:label ref="."/> > <xf:value ref="@id"/> > </xf:itemset> > </xf:select>
The problem here is so simple it’s slightly embarrassing: the ‘ref’ attribute on xf:select sets the context item, so the relative expression in the xf:itemset/@nodeset attribute cannot (as written) succeed: no attribute every has element children. If one makes it absolute (lead with instance(‘name’)/… or with ../../), the drop down menu ceases to be empty. So the belief that the diagnostic messages showed the XPath expressions to be correct was wrong: the two instances of the same expression had different context nodes. I can now shift to the challenge of making the display nicer. > - Second, when I try to use xf:output in the xf:label element, > I get an error; ditto when I try to use a constant but remove the @ref > binding attribute. Are both the value and the label of an itemset > required to use @ref? For this I have currently found no simple solution. Binding to a node using @ref works great when there is a node whose string value is what you want in the menu. That’s not the case for the application I’m working on: the items from which the user must select often have child elements, some of which should be included in the value to be shown in the menu and others of which [the end-notes] should be omitted. And for some entries additional information should be supplied from context. A simple ref attribute binding to the original element will produce the desired string perhaps 20 or 30 per cent fo the time. Probably the best solution I can come up with in the next couple of hours will be to apply an XSLT transform to the current instance data to create an auxiliary document instance containing the appropriate label and code values. In XSLTForms I can use the transform() function; in another XForms implementation one would need to submit the current main instance to a service on the server which would run the XSLT transform and return the appropriate select-values instance. > > Anyone who can shed any light on this would receive a large shipment > of gratitude (and a beer if we’re ever in the same bar). It’s too early in the day just now, but I’ll take myself up on this tonight. ******************************************** C. M. Sperberg-McQueen Black Mesa Technologies LLC cms...@blackmesatech.com http://www.blackmesatech.com ******************************************** ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Xsltforms-support mailing list Xsltforms-support@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xsltforms-support
