Yes, but in Collect each repeat instance's summary would be on a different page. You'd accomplish this by wrapping the summary information in a repeat with a repeat_count. Instead of using fixed indexes to look up different values in the editable repeat, you'd use the position in the summary repeat (similar to this documentation). I can share an example if you need more details than that.
Most of the summary screens we've seen involve computations of some kind: sums, averages, values that were skipped (e.g. if not all plot names are represented). In this case, it looks like you want to show exactly the same data, is that right? Can you say more about your workflow and why you want to show this data in a read-only summary? Maybe there's a lot more to the form that wouldn't be included in the summary? @aly has recently worked on some mockups of a built-in summary screen so this is interesting to see.
I don't believe there's an approach that results in a consistent display, unfortunately. This has bothered me before but I don't think I've ever seen any other complaints about it! We have it tracked as part of a broader issue around styling between the Collect and Enketo in the Collect/Enketo differences tracker. I usually just use newlines and don't mind the vertical spacing in Collect. What's going on there is that Collect replaces the newline with a paragraph break.
The instance function is to specify which choice list or external file to look values up in. After the instance call, there's an expression to look values up like /root/item[name=${id}]/property. You can use this same kind of lookup in a repeat and that is what the indexed-repeat does under the hood.
An example from your form:
indexed-repeat(${plotname}, ${plotinfo}, 1)
can also be expressed as
${plotinfo}[position() = 1]/datagrp/plotname
or
/data/plotinfo[position() = 1]/datagrp/plotname
Notice that when you write expressions in this more raw way, you need to explicitly include any groups that contain the value you're interested in. You can read more about these kinds of expressions in the documentation.
This looks like it's related to a recent pyxform change. Are you sure that the form worked as expected in older versions? If it really did work, we can look deeper into it but the expression does not look correct to me because the second argument in quotes doesn't specify an index.
Here's how I would express it instead:
- Change the name of your
select_oneto select a plot toplotor something like that. - Add a
calculatewith nameplot_namein the repeat after the select one. - Give that calculate the calculation
jr:choice-name(${plot}, '${plot}') - Change the
pn1calculation to beindexed-repeat(${plotname}, ${plotinfo}, 1)(or${plotinfo}[position() = 1]/datagrp/plotname)
This puts the choice name lookup in the repeat which simplifies the expressions.