I’m investigating the use of jsonforms to create both web and PDF forms. The goal is providing a unique experience for creating forms that can be used to iteratively migrate from PDF forms to web forms.
As of now I’m using something like:
- type: Group
label: This section
description: |-
Long description providing hints to fill json forms.
I then render description in jsonforms.
Is there a better way to do it?
Hey, that project sounds great, good to encourage uptake by allowing for an iterative migration.
What drawbacks are you finding with your current approach? It’s difficult to make a suggestion without knowing the pain points of your current solution.
Currently this approach seems ok and if there is not another way to achieve this goal, it would be great to standardize it into jsonforms.io.
The pain point of this approach would be to move outside the stream of the jsonforms.io community and it would be great to understand if this use-case is of some interest for the community.
Hi @ioggstream, that’s super cool! I think the general approach of using the JSON schema and ui schema formats to generate pdf forms makes a lot of sense. It’s expressive enough to generate nice pdf forms and a transition to the web with JSON Forms is super easy afterwards!
I took a look at your POC and saw that at the moment your pdf generation is implemented in python. So the only overlapping parts of the pdf forms generation and JSON forms are actually the schema and ui schema formats. We’ll always adhere to the JSON Schema specification and our ui schema format is very stable and didn’t change for a long time. So as long as you stay compatible with these two formats you’ll always be able to use JSON Forms without much modification.
If I see it correctly you are manually creating an HTML form based on the given schema and ui schema and then transferring that to pdf. Now if you wanted to you could actually use JSON Forms itself to generate the HTML. One approach would be to implement your own renderer set (which you basically already did, but in python ), however you could maybe reuse one of the existing React renderers (material or vanilla) with React DOM Server’s renderToStaticMarkup. If that works you wouldn’t need to implement this step yourself which could save a lot of time.
Regarding your question: JSON Schema supports title and description fields on all elements which are used by JSON Forms to display nice titles and hints. So I would recommend to use these attributes as much as possible. You can also use the label attribute in the ui schema if that makes more sense for your workflow.
Regarding the notes in the POC about ref resolving and yaml:
We internally use the json-schema-ref-parser for ref resolving which is also able to resolve remote references. If this is something which you need then you can pass in a configuration for it.
JSON Forms itself is agnostic to the way your data is saved as it just takes in Javascript objects. Our react-seed uses .json files as this is the most straightforward way, but it could easily be adjusted to load .yaml files to (or connect to a REST server etc.)
To summarize: I very much like your approach and I think it’s a cool project. Let us know when you have any more questions / concerns etc. I’ll also gladly take a look again at some point
Thanks @sdirix . I’ll investigate on the StaticMarkup, though I’ve to check if that the resulting pdf has fillable forms.
For the rendering, label is not enough as that’s more a title than a free text field. For now I’ll use a custom description field and I’ll let you know.
and it would be great to understand if this use-case is of some interest for the community.
), however you could maybe reuse one of the existing React renderers (material or vanilla) with