-
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 dynamic defaults #338
Comments
@MartijnR, could you please double-check that I captured everything discussed about this feature? |
This all looks good to me. Thanks! |
Looking at this one next. |
@lognaturel is there existing regular expression to check for expression in the xlsform code that you're aware of? |
None that I'm aware of and that's definitely the tricky part. Perhaps there's a better strategy you can think of. I think it would be great to answer some of these questions about approach now. We probably should have a discussion about how/when to release, though. I don't believe Enketo has support for events and actions yet. Collect will only be getting The "good" news is that forms with this feature would entirely fail to load in old versions of Collect so at least there's no risk of the user thinking they're going to get a default but not getting one. Note also that using |
Looking at the code, I was thinking of expanding the Would it be a good approach to expand that dictionary and add something like
Thoughts @lognaturel ? Update: |
@lognaturel added first pass of the implementation. The conversion throw validation error which is expected, right? |
Wow, I just came here to say that pyxform should throw an error if it detects a dynamic default. But it looks like support will be added, which is even better! |
Yay, @joeflack4! Out of curiosity, what kind of dynamic default were you hoping to set? That is, is it top level, in a repeat? What type of value is it? Date, ...? Yes, @nribeka, the Validate failure is expected. It will need to be updated to JavaRosa 2.17.0. I propose that we add a warning like "not all form filling software support dynamic defaults so you should test the form with the software you plan to fill it with" or something like that. What do you think, @MartijnR, @joeflack4? |
Oh gosh, I wish I could think of an example right now. This has come up a number of times. I believe both Does any client support dynamic defaults? If so, I'm fine with just a warning. If not, I imagine that the conversion should just error out. That is, until it's well supported. |
Generally, I think it is the responsibility of the troublesome client to alert the user for something like this upon loading the form. However, in this case, detection is a little tricky in Enketo, so this warning would be very helpful! |
Well of course, the old tenet is something like 'fail early and loudly'. So in this case, the conversion validator used by the conversion tool is an ideal place. But of course people might not use that converter, or might use old software, so I think it's also good to catch on the client if possible. That also handles any other edge cases. |
Actually Enketo added support for this in December! 😀 🎉 |
Oh, fantastic! Then should we just not include a warning at all, then, @MartijnR? It could affect other clients or downstream tools so maybe we leave it in for one release as a courtesy? |
I think we might be alright without a warning here (though wouldn't really hurt to be sure). Note, it was Esri that sponsored this feature in Enketo, so they'll be welcoming this pyxform change (and wouldn't need the warning) (@tedrick). |
Add support for dynamic defaults by expanding what the exiting
default
column does. See the forum thread for discussion.If the contents of the default column are not a literal value, the expression is passed through to the
value
attribute of asetvalue
action triggered by theodk-instance-first-load
event. In the case of nodes that are not in repeats, this action is added as a child of themodel
and ideally right after thebind
for the node of the value it sets (this is not a hard requirement -- it can be anywhere in themodel
).In the case of repeats, the action is added as a child of the repeat form control (in the
body
) and the triggering event isodk-instance-first-load odk-new-repeat
.Given the following row from a survey sheet:
The following XForm content should be generated in the
model
:Given the following rows from a survey sheet:
The following XForm content should be generated in the
body
:I believe the best approach for identifying static vs. dynamic defaults will be to use a regular expression. It should be fine for static values to end up as the value for the
value
attribute so not a big deal if the regex catches some things that are not actually intended to be evaluated. However, there is the possibility that a user will want to literally use text that could be evaluated. For example, a user could want the literal string "today()" as a default and that would no longer be possible. We may want to add some kind of escape strategy for that case but I propose we wait until a user requests it because it seems unlikely to me.The text was updated successfully, but these errors were encountered: