Hi Martijn,
Thanks for the reply. I have to admit, though, that I'm still a bit
confused. While shifting to relative paths seems perfectly fine for cases
where you're referencing variables within the current repeat instance, it
doesn't seem desirable to ever completely phase out absolute path
references. After all, what we're just starting to be able to do is
reference across repeat-group instances in flexible ways, which is critical
for a whole range of applications. For referencing repeated fields from
other contexts, it would seem that absolute paths would be necessary.
Take a simple example that recurs in a great many surveys: you have a
"household roster" repeat at the beginning of your form to collect some
basic details on every household member, but then it would be extremely
awkward to only ever ask follow-up questions about household members within
that early repeat; later on in the survey, you may start asking questions
about jobs, or about health, or about all manner of other things, and in
those later sections you may well want to refer back to household members'
details. You want to populate select_one and select_multiple lists with the
household member names, you want to check ages to make sure that you only
ask about number for children for women over 12 years old, etc., etc. These
are very common things to want to do.
Traditionally, doing these things has been extremely difficult if you use
repeat groups, because of the difficulty referencing specific values within
earlier groups. In principle, absolute paths like /form/repeatgroup[3]/name
provided a clear solution, but the predicate and context support in the
current ODK branch of JavaRosa has made it somewhat challenging to
construct those references in a way that is interpreted properly at
run-time. /form/repeatgroup[position() = /form/laterrepeatgroup/pos]/name
is maybe supposed to work, but doesn't, and generally there has been a lot
of heart-ache and confusion over how to do this stuff.
We have recently added an indexed-repeat() function to our own JavaRosa
branch (discussed here in another thread), and have submitted that for
potential inclusion in the ODK JavaRosa branch. It essentially allows you
to flexibly supply the repeat instance indexes to fill in the x's and y's
in paths like /form/outerrepeat/innerrepeat[y]/name. It's a very simple
function, but it opens up a whole range of applications, like those
discussed just above.
indexed-repeat() takes any XPaths, and so supports relative paths like
anything else. But, its raison d'etre is references across contexts, in
which relative references are far less useful. Is there a method for doing
cross-context referencing that you envision not relying on absolute paths?
Thanks again,
Chris
On Fri, Jun 14, 2013 at 6:00 PM, Martijn van de Rijdt < martijn@aidwebsolutions.com> wrote:
There has been some discussion around this in XLS Forms here with
Nathan: https://github.com/modilabs/pyxform/issues/91
@Chris, certainly support for the incorrect XPaths inside repeats should
remain in place inside ODK Collect and Enketo for backwards compatibility
reasons. Best to start moving to the correct (XPath) way of doing things
though.
Injecting positions is an unnecessary hack because XPath already
provides elegant ways of directly referring to nodes inside repeats,
without hacking.
@Will, to clarify the issue (as requested outside this thread):
This absolute path:* /data/repeat/node1* returns 2 nodes (or only the
value of the first node depending on the resultType you're requesting). So
if node2 needs to refer to the value of node 1 in each repeat, a relative
path should be used when building the form (by hand):* ../node1. *
*
*
Cheers,
Martijn
On Friday, June 14, 2013 12:14:50 AM UTC-6, Chris wrote:
Now I'm confused: why would the use of absolute paths become illegal?
Right now, XLSForm always resolves ${fieldname} references into absolute,
generic references like /form/outergroup/repeatgroup/**fieldname. It's
generic in that it's missing indexes, but those indexes get put in at
run-time, based on your current context (i.e., the absolute reference is
"contextualized"). I'm clearly no XForms expert, but that hardly seems like
errant behavior that needs to be stamped out in the future. At the very
least, any Collect or enketo release that didn't support such references
would be instantly incompatible with essentially all XLSForm-generated
forms to-date -- which would seem like a pretty undesirable thing. Or am I
missing something?
Chris
On Fri, Jun 14, 2013 at 3:43 AM, Mitch Sundt mitche...@gmail.comwrote:
Yes, within repeats, it is important to use relative access to values
within the repeat in a calculation. To my knowledge, XLSForm does not do
this entirely correctly; therefore, while the underlying engines (enketo,
javarosa) may support it, in may not be possible to use Build or XLSForm to
generate the proper calculate expressions.
Mitch
On Thu, Jun 13, 2013 at 2:25 PM, Martijn van de Rijdt < mar...@aidwebsolutions.com> wrote:
Support for calculations inside repeats has now been added to enketo!
A tip, related to this:
If you're coding XForms by hand, I recommend using ../relative paths
when referring to a node inside a repeat from another node inside the same
repeat (to prepare for the future where the use of (incorrect) absolute
paths in these cases will no longer be supported).
Cheers,
Martijn
On Friday, June 7, 2013 8:22:46 AM UTC-6, Martijn van de Rijdt wrote:
Hi Will,
I think, you stumbled upon a known issue with calculated items
inside repeats in enketo: https://github.com/**mod**
ilabs/enketo/issues/477https://github.com/modilabs/enketo/issues/477.
So it will probably work in ODK Collect, but not yet in enketo. Once the
issue is marked as closed it will soon thereafter be deployed.
Cheers,
Martijn
On Thursday, June 6, 2013 11:42:26 AM UTC-6, abta...@gmail.comwrote:
On Thursday, June 6, 2013 10:09:23 AM UTC-4, abta...@gmail.comwrote:
I'm trying to do some simple addition and multiplication
calculations within a Repeat group. The calculations function for the
first entry, but fails for every additional entry. Can calculations
function within repeats beyond the first entry? And if they can, how do
you configure the calculation?
Thanks,
Will
Apologies for not including more information. I'm attaching the
.xls form of the code in question. Here is also a link to the web form
itself so the behavior can be viewed:
http://hlhy4.enketo.formhub.org/webformhttp://hlhy4.enketo.formhub.org/webform
I have a calculate (name "othertotalcost") that multiples the Total
Units (integer type with name "othertotal") by the Total Cost (decimal type
with name "othercost"). This calculation functions for the first entry
within the repeat, but if any additional entries are attempted, the
calculation fails.
--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to opendatakit-developers+**
unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
.
--
Mitch Sundt
Software Engineer
University of Washington
mitche...@gmail.com
--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+**unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out
.
--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to a topic in the
Google Groups "ODK Developers" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/opendatakit-developers/7b3FohKkmRs/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.