Best practices for auto generated forms

Hi guys,

We are starting to develop a big project using meteor framework (because it’s so awesome!)

The challenge

One of our main requirements is to have forms that will be dynamically generated based on metadata and data only.
The metadata will include the schema of the form: which fields should be displayed, their type, etc.
The data will include the relevant entity’s data, which might change while the form is opened, and the form should reactively reflect the new data.

In addition, we have unique UI requirements. A form might have special controls, buttons in different areas of the form, with different look & feel, few hierarchic toolbars, maps, tables and more. Hence, we’ll need the freedom of defining our templates by ourselves.

Why Auto Form wasn’t good for us

The first thing that comes to mind is to use autoforms & simpleschema. While it is a great solution we feel it doesn’t give us the necessary UI freedom we need:

  • Display read only fields without the real control (just a label)
  • Display few inline components (not necessarily according to bootstrap columns)
  • Display icons, special buttons with icons and text
I have created a simplified example, with two read only fields and some example icons to illustrate the challenges we are facing. In real life, the form will include different components in different states and layouts.
We were thinking how to establish these requirements in meteor and blaze and we realized that we can’t loop through the data and different metadata in the same time, for example if we have a label and control with data – the label and control type will be defined according to the metadata, but the component data will be updated according to the entity’s data collection.
Of course awesome performance and UX is a must, we want things to be reactive the meteor way (not re-rendering the entire form on a change of data for example)

Our intermediate solution

Our current suggested solution is to create a merged collection (client side only) where each document will already contain all the needed data and metadata. Then, create a few general helper fields based on the different sections of the form and return the relevant data structure to the template html specific section. When observing a change to the entity’s data we will update our client side collection, and the direct change in the UI will be reflected immediately. This solution appears in this repository

Even though this might work, we are not satisfied with this solution, since it’s cumbersome, not efficient (?) and general, and doesn’t match the meteor philosophy.

What do you suggest?

We would be grateful if you could look into this project example and write here (in this forum) or edit it (directly in github), and add any suggestions which are clean, smart and efficient, that we can use in our application design.

Many thanks for your willingness and time! :slight_smile:

Tamar

Unfortunately, I think your intermediate solution is currently the best way to go. Meteor has no support for UI components. A UI component is a bag containing original data, transformed data, configuration data and states. With Meteor, you need to implement all this by hand. I found having a local collection observing the original collection is the best way to manage transformed data.