feat(#305):Select one for map - xforms-engine #478
Conversation
|
| type DerivedItemLabel = ClientTextRange<'item-label', 'form-derived'>; | ||
| export interface BaseItem { |
There was a problem hiding this comment.
Start in this file
This is the simple base item for Rank and Select.
Select's item will include geometry and metadata. The latter contains everything defined in the choice sheet from an XLS form, except for the value's column (usually called "name", but it can be another column), itextId, and geometry, to prevent duplicate data in Select's item.
| @@ -101,6 +102,8 @@ const createItemsetItemLabel = ( | |||
| interface ItemsetItem { | |||
There was a problem hiding this comment.
If rank and <item> require geometry and metadata, then we can use only this interface and remove BaseItem.
I think <item> needs geometry and metadata, but rank does not.
There was a problem hiding this comment.
Correct, there is no situation in which the frontend needs additional properties on rank items. Those additional properties might be used in choice filters or calculations but that's all handle engine-side.
| defaultValue: '', | ||
| }); | ||
|
|
||
| const nodeElements = itemNode |
There was a problem hiding this comment.
The itemNode already includes everything from the choice sheet. Here, we follow the same approach as with "value" (L123).
| @@ -144,6 +166,8 @@ const createItemset = ( | |||
| return { | |||
There was a problem hiding this comment.
This is where the data is extracted, and the Vue client receives:
| import type { ItemsetElement } from '../../../lib/dom/query.ts'; | ||
| import { getValueElement } from '../../../lib/dom/query.ts'; | ||
| import { ItemsetGeometryExpression } from '../../expression/ItemsetGeometryExpression.ts'; |
There was a problem hiding this comment.
These expressions (ItemsetGeometryExpression, ItemsetMetadataExpression, ItemsetNodesetExpression, and ItemsetValueExpression) could be removed and replaced with DependentExpression directly.
While ItemsetLabelDefinition can stay, it has more complexity to encapsulate.
| this.value = new ItemsetValueExpression(this, valueExpression); | ||
| this.geometry = new ItemsetGeometryExpression(this); | ||
|
|
||
| this.metadataExclusions = ['itextId', this.value.expression, this.geometry.expression]; |
There was a problem hiding this comment.
As noted earlier, I aim to exclude anything already exposed as a class attribute to prevent data duplication and simplify the Vue client’s looping and rendering work.
| .filter((node) => node.nodeType === 'static-element'); | ||
| const metadata = itemset.getMetadataExpressions(nodeElements).map((meta) => { | ||
| return { | ||
| label: meta.elementName, |
There was a problem hiding this comment.
Is this translatable or does it have media? Otherwise it will need to be a TextRange
There was a problem hiding this comment.
These are the values of additional properties, right? Currently these are not translatable -- each property/column is independent from the others.
latin-panda
changed the title
| get value(): string; | ||
| export interface SelectItem extends BaseItem { | ||
| geometry?(): string; | ||
| metadata?: Array<{ label: string; value(): string }>; |
There was a problem hiding this comment.
properties or additionalProperties?
geometry could also simply be an additionalProperty.
But that makes me think -- in what format is the geometry value right now when items are from a geoJSON file? Ideally the engine exposes a consistent format so the client doesn't have to do any conversion.
If geometry is made into its own concept, we should use a type to describe/validate/represent the structure rather than a raw string.
There was a problem hiding this comment.
I haven't had a chance to think about this in detail quite yet. I think the key question is what to expose to the client. Some of the big questions I see:
- Is
geometrya first-class concept? In JavaRosa/Collect, it's not something JR knows about, it's just passed as part of an "additional properties" list and Collect pulls it out. - What format should the geometry value be exposed in? In Collect/JR, it's always in ODK format, even when from geoJSON
Closes #305
WIF
I have verified this PR works in these browsers (latest versions):
What else has been done to verify that this works as intended?
Why is this the best possible solution? Were any other approaches considered?
How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?
Do we need any specific form for testing your changes? If so, please attach one.
What's changed