Skip to content
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

Provide indication of missing support for form vocab features? #5

Open
josephguillaume opened this issue Dec 10, 2022 · 2 comments
Open

Comments

@josephguillaume
Copy link

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.

@smessie
Copy link
Member

smessie commented Feb 14, 2023

I've added a warning in bc310c8

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.

@josephguillaume
Copy link
Author

Thanks. I appreciate the extra background information and clarity around the intended scope of the proof of concept.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants