-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for external instances #30
Comments
Any chance this will be added to javarosa/odk validate/odk collect family? |
Hopefully. Otherwise we need to go ahead with building a new validator based around's enketo's XPath evaluator. I know Dimagi is using external XML instances a lot already (same as above). Not sure what validator they use. The feature has now been added to Enketo Express. |
Martijn are you following the approach dimagi is using? Do they have their
|
Yes, same approach. No re-inventing of any wheels. I just added CSV support in addition to XML. Dimagi has their own version of Javarosa that supports XML external instances as above. |
👍 for referencing the URI of the external itemset from within the XForm. |
This opens the way for some exciting future possibilities, because the URL published in the /xFormsManifest could be a dynamic document. E.g. a dynamically created XML 👍 (or CSV 👎 ) Document.... It could be external to KoBo/Ona too. You could e.g. create a service that dynamically creates a document based on another survey or based on earlier responses to the same survey. |
Is this working? On Wednesday, March 18, 2015, Martijn van de Rijdt [email protected]
|
In Enketo Express it is working, yes. |
Awesome On Thursday, March 19, 2015, Martijn van de Rijdt [email protected]
|
One way around ODK Validate is to add dummy content to the external instance. Instead of: <instance id="cities" src="jr://file/cities.xml" /> we do: <instance id="cities" src="jr://file/cities.xml" >
<!-- the following line is necessary for some xform parsers -->
<root><item><name/><label/></item></root>
</instance> It's just a temporary dirty trick to fool ODK Validate, but it should work for all Pyxform-produced forms. Luckily the javarosa parser doesn't check the content of the choice_filter. |
What's needed? Is there a ticket for this? On Monday, June 15, 2015, Martijn van de Rijdt [email protected]
|
I wrote it out into a test here using the 'pyxform_test_case' syntax ( from pr #28 ). @MartijnR, If that test describes all that's required, we can take a stab at it in the next couple weeks. |
beautiful @dorey 👍 The only thing to change in the tests, is the ODK Validate trick, either by removing the self-closing |
Martijn, Would this enable pull csv like functionality in enketo express? Matt On Mon, Jun 15, 2015 at 10:25 PM, Martijn van de Rijdt <
|
[removed earlier reply] pulldata() support has now been added to both Enketo (and pyxform) by adding the external |
UPDATED: ignore this comment I wonder if, after the recent changes wrt to column 'value' we should output instead: <value ref="value"/> <!-- ref="value" instead of "name" -->
<label ref="label"/> This would change the ODK-validate trick into: <instance id="cities" src="jr://file/cities.xml" >
<!-- the following line is necessary for some xform parsers -->
<root><item><value/><label/></item></root>
</instance> and thus require a value and label column (csv) or node (XML) in the external document. |
Actually "value" instead of "name" doesn't seem to work in PyxForm (for regular choices sheet). So let's stick with using "name". In any case, any OpenRosa XForm client supporting this feature could deal with both as it's just regular XForm syntax. So it could quite easily be changed later, without breaking existing forms. The snippets in the OP are correct. Sample XForm + XML media: external_xml.zip and live |
@MartijnR I notice that the form.xml in external_xml.zip makes use of Also, what content type does enketo expect? The XML example https://enketo-stage.ona.io/::YYmJ seems Enketo is attempting a CSV processing instead of XML. |
@ukanga, when looking at the code only, it seems like Enketo may (accidentally) be lenient towards this. However, Content-type should be appropriate for the source. At the moment, in Enketo if the (jquery get) auto-parsed result is not an XML Document it will be considered CSV. I think generally it should be |
I've added an issue to EE as the explicitness of the jr:file or jr:file-csv connectors should probably be used to parse correctly regardless of the Content-Type it is served with. kobotoolbox/enketo-express#710 |
earlier discussion on ODK dev forum
<select>
or<select1>
with a regular<itemset>
and always add a single<instance id="" src="" />
to the model (unless that instance with that id already exists).id
attribute = lowercased filename minus the extension: countries.csv =><instance id="countries">
src
attribute for XML sources getsjr://file/
prefix and for CSV sources getsjr://file-csv/
prefix (similar to jr://image, jr://video and jr://audio).ref="label"
because itext references couldn't work.Examples
1a. XLSForm input (CSV file, no choice filter):
1b. XForm output:
Very similar to a regular select_one with choice filter (but in this case the choice filter is empty)
2a. XLSForm input (XML file, no choice filter):
2b. XForm output:
Exactly the same syntax as used by CommCare for their many XML external instances
3a. XLSForm input (CSV file, with choice filter):
3b. XForm output:
Notes:
src
attribute)The text was updated successfully, but these errors were encountered: