"BT-60-Lot" in notice subtype 16.json seems to be located under the incorrect nodeId #799
Comments
|
Looking further into this issue I find that the nodeId: For notice type 16 in SDK version 1.9.1 i find the following fields has a wrong nodeId on their parent: I've built my code assuming that there was consistency between the information given in field.json about the xml structure and the nodeId values given in the notice-types. Maybe I made a wrong assumption? |
bertrand-lorentz
added
the
notice-types
|
You mention that you are trying to "convert a physical model into a visual model", so I assume that you're trying to prefill a form based on the information in an XML notice. The information in the notice-types is consistent with the information on the XML structure given in fields.json is consistent for the nodes where it really matters: the repeatable nodes. The closest repeatable parent node for "BT-60-Lot" is "ND-Lot", so the XML will only ever contain one occurence of "BT-60-Lot" in each "ND-Lot". To put the value from the XML in the right place, you just need to find the right occurence of "GR-Lot" in the form, and go the single place that corresponds to "BT-60-Lot". When we have associated non-repeatable nodes with display groups (GR-...) in notices-types, it was to help loosely relate sections of the XML (elements that contain other elements) with what a user see on the screen, in particular to indicate when a complete section of the form has not been filled in. |
|
Hi Bertrand. Thank you for quick reply, and the great work with the SDK it's a pleasure to work with! You're correct in your assumption that I'm trying to prefill a form based on the information in an XML notice. I see your point about the repeatable nodes being the most essential to get right, and thank you for the reference to the relevant documentation. I might not have looked closed enough about the importance of repeatable vs. non-repeatable groups. I've implemented by code by using the visitor pattern on the notice-type, and at the same time navigating through the XML following the nodeId information and the xmlStructure from fields.json. This is why the inclusion of Working with the eforms-notice-editor (branch: Removing the line |
I'm trying to convert a physical model into a visual model as defined by the notice editor sample project, using the 'TEDEFO-2456-use-of-fields-attribute-information' branch as a base.
Problem:
But some of the fields are not getting translated correctly. I'm working with the file: https://github.com/OP-TED/eForms-SDK/blob/develop/examples/notices/cn_24_minimal.xml#L138 and BT-60-Lot: XML node: "cbc:FundingProgramCode" is not working. I'm using the relative XPath to navigate the physical model.
I'm finding that there might be an issue in the notice type definition of notice subtype 16.
In fields.json: "BT-60-Lot" has the parentNodeId: "ND-LotTenderingTerms" https://github.com/OP-TED/eForms-SDK/blob/develop/fields/fields.json#L26932. "ND-LotTenderingTerms" is a direct child of "ND-Lot": https://github.com/OP-TED/eForms-SDK/blob/develop/fields/fields.json#L408
In 16.json (and possibly others), "BT-60-Lot" the nearest parent "nodeId" is "ND-LotTenderingProcess", also a direct child of "ND-Lot": https://github.com/OP-TED/eForms-SDK/blob/develop/fields/fields.json#L289
Suspected solution
Since "BT-60-Lot" is placed under the wrong nodeId, I'm finding that the processing doesn't work. I'd expect "BT-60-Lot" to be placed under "ND-LotTenderingTerms" or perhaps "ND-Lot" instead.
The text was updated successfully, but these errors were encountered: