Reading ItemPicker's items values (dataRef objects) does not work in Geocortex Mobile
I want to run a workflow that I've previously run successfully in GVH. Now, I want to run it in Geocortex Mobile. Workflow has an Item Picker that is populated with items from a feature selection. With "Get Form Element Items From Features", I have not given a value field name, so the items should reference dataRef-objects from the features. With a ForEach, I loop through the ItemPicker's items, and try to read $forEach1.item.value.data.attributes["ATTRIBUTENAME"]. This has worked fine in the HTML5-viewer, but in Mobile, the workflow fails saying the data is null.
Does anyone have a solution to this?
-
Hi Jostein, thanks for pointing this out. It sounds like you've discovered a discrepancy between the TypeScript and .NET implementations of Get Form Element Items From Features. Ensure you've not set the "Value Field Name" input and try again. It seems when that's set, the value you get back is the value of that field, rather than the whole feature.
0 -
I had a look and the code looks similar, so another possible explanation might be if GVH is not able to find the value field but Mobile is. The answer should be to remove that input either way, as it sounds like you want the whole feature.
0 -
Thanks, Ken! The problem was not about getting the DataRef-objects as I anticipated. The problem was howto reference the feature's attributes. In GVH, I used $forEach1.item.value.data.attributes["ATTRIBUTENAME"]. To make it work in GXM, I had to take away the "data"-part, and use $forEach1.item.value.attributes["ATTRIBUTENAME"]
0 -
I'm glad you solved the issue. My apologies for not reading your initial post carefully enough. I see now that you did say you had not set the value field name.
I've logged this discrepancy as a bug and hope to address it at some point.
0 -
Ken Lyon We stumbled upon this post when researching similar behavior with one of our clients. Is this bug still relevant or has it been solved in the meantime?
0 -
ESRI Netherlands This is something we can't easily "fix" without breaking it for existing users. If we changed it to $forEach1.item.value.data.attributes then anyone using $forEach1.item.value.attributes in an existing workflow would start to get errors where they didn't before.
The only answer I could see that would work for both would be if we could somehow find a way to support both. This could be tricky though and I'm not sure how feasible it would be. We're more likely to document the difference than fix it.
0 -
Please fix this problem because now I have to write 2 versions of the same workflow. One for the mobile viewer and one for all the other usages of the workflow.
I think people will be more happy with only one workflow that works everywhere and accept the changes they have to make. You do have to point it out in the newest version of workflow that people have to change their existing workflows for mobile after you fixed the issue.
For us this is a really BIG showstopper in using VertiGIS Studio.
0 -
Luuk Schaminée there are so many differences between the viewers, so I think we'll have to live with having to make adjustments to the workflows from viewer to viewer. In most cases, I think it's not a big deal.
0 -
Luuk Schaminée I personally would love to be able to do what you're describing but one big limitation is that we can't assume that all workflows in production use are being actively maintained. Even if it would be a trivial change to update and save your workflow to keep it working, the consequences to those who don't make the change would impact the reliability of our software and people's confidence in it.
There is also the possibility that some workflows are not trivial to change and they could be broken in the process of changing them.
I don't like these discrepancies either, but on balance I've had to accept this as the safest course of action.
0
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
Kommentare
9 Kommentare