javarosa
javarosa copied to clipboard
getodk
Form fails to load when jr:count is set to a number
Software versions
- JR v2.12.1
- Collect v1.18.0
Problem description
Using this form, a dynamic number for jr:count=" /nested-indexed-repeat/friends/pets_count " works fine, but jr:count="2" causes an error:
XPath evaluation: type mismatch
Expected XPath path, got XPath expression: [2],null
Steps to reproduce the problem
- Open the blank form in Collect (it works)
- Change to
jr:count="2"and open the blank form again (it fails)
Expected behavior
Unless I'm missing something, explicit count should work. Maybe there's XML in some other part of the form that's causing problems?
Other information
Relevant stack trace location (the code that parses count):
https://github.com/opendatakit/javarosa/blob/master@%7B2019-01-21%7D/src/org/javarosa/xform/parse/XFormParser.java#L1485
It's not that dynamic values work well but static don't . If we have a static value it also should be in a separate element for example:
<bind calculate="2" nodeset="/repeat_count_test/e1_count" readonly="true()" type="string" /> and then we can use it:
jr:count=" /repeat_count_test/e1_count "
I don't think we want to change anything here do you agree @ggalmazor?
I need to wrap my head around this and understand it. I'll try to say something as soon as possible :P
The specification shows a raw value and explicitly states that the value should be evaluated dynamically: https://opendatakit.github.io/xforms-spec/#creation-removal-of-repeats So jr:count="3" should be supported, as should jr:count="/data/foo * 3".
pyxform introduces an intermediary field so this doesn't affect most users. @cooperka is running into it because he uses a different form builder. I believe the issue is that any xpath expression should be allowed rather than only xpath path expressions but this seems like it's pretty low priority given everything else ongoing.
Hello @grzesiek2010, you have been unassigned from this issue because you have not updated this issue or any referenced pull requests for over 15 days.
You can reclaim this issue or claim any other issue by commenting @opendatakit-bot claim on that issue.
Thanks for your contributions, and hope to see you again soon!
This particular attribute doesn't come from any other existing spec and now that I look at the code more closely, it's very clear that the intent is for its value to be a reference. Out of curiosity, I checked CommCare and they definitely don't support anything other than a reference either even though their XForms spec also has an example with a literal value. I think the spec might just be wrong in this case since JavaRosa introduced the attribute. @MartijnR does that seem possible?
I want to add that I'm not saying that making the jr:count value a reference is a better spec design, only that it was a very clear choice by the original JavaRosa authors. The same way that we honor historical XPath decisions that we may not agree with now, it would make sense that for additions in the jr namespace we either honor the original implementation or have an explicit conversation about changing it.
Uh oh, sounds like we should find and punish the writer of those parts in the specs. Thanks for looking into that!
we should find and punish the writer of those parts in the specs
Haha, I hope you know that's not what I intended! 🤗 So what do we do with this information? How strongly do you feel that any expression should be allowed?
Haha, I hope you know that's not what I intended! 🤗
I do!
I think it would be a nice-to-have addition, but don't feel strongly about it. So I'm happy to keep as-is if it's a pain to change in JavaRosa. There are other attributes that only accept a path, so no big deal to treat jr:count as one of those.