You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The GitHub repository clearly labels this as a proof of concept, and the available form fields are clearly shown, but it would be useful to also indicate in the demo that the form vocabs do support elements not included in this tool, and perhaps even provide a warning when unsupported field types are found when loading an existing form.
Related to this, if I understand correctly, the supported elements are being loaded by class from the store rather than by "following your nose" from the root form object. This means that information about order of subelements is being ignored, and that fields from multiple different forms in one document would be mixed together.
I agree that it would even be better to give warnings when unsupported field types are detected, but doing so would require more work. Especially because ember-solid is used for loading and writing data, things are a bit less easy customizable.
fields from multiple different forms in one document would be mixed together
Yes, that's unfortunately true, http://rdf.danielbeeke.nl/form/form-dev.ttl# however requires this by design, it only supports one form per file because the fields are not linked to the form by triples but just by the fact that they are in the same file.
This code was made with this in mind and later extended to support the other vocabularies.
I agree that it would be better to change this for the other supported vocabularies so we don't need the assumption that all forms are in separate files.
The GitHub repository clearly labels this as a proof of concept, and the available form fields are clearly shown, but it would be useful to also indicate in the demo that the form vocabs do support elements not included in this tool, and perhaps even provide a warning when unsupported field types are found when loading an existing form.
Related to this, if I understand correctly, the supported elements are being loaded by class from the store rather than by "following your nose" from the root form object. This means that information about order of subelements is being ignored, and that fields from multiple different forms in one document would be mixed together.
https://github.com/smessie/FormGenerator/blob/d03c2d67b6af90d93d3795f01360bebe86cf07b8/app/controllers/index.js#L43
This is also an example of implicit semantics, which should be avoided:
https://twitter.com/RubenVerborgh/status/1582357537864945665
Apologies if I've misunderstood how this code works.
The text was updated successfully, but these errors were encountered: