This is an awesome project. It re-envisions Forms in a similar way to how Views re-envisioned SQL queries. Kudos for all the hard work to get this far.

The one serious limitation I have found so far in this project is that it does not use the Field API. Form fields do not have field definitions, and their data is not stored in the Field system. Thats OK for some use cases, but fatal for others. Here are some things we give up by skipping Field API:

  1. Views integration gets difficult and custom - #2769977: Use Views for the Submissions Results
  2. Rules integration is custom - #2779461: Add Actions and/or Rules support to submission handling
  3. Rest API/GraphQL/JSON API support gets difficult and custom
  4. No 'Add another value' feature - #2786675: Ability to insert an Add Another button to the forms/wizards
  5. Translation of submissions (this is not a big need)
  6. Token support is custom (already done)
  7. Form modes and display modes for submissions are gone. At least form modes would be useful. Any modules that do layout of fields/forms need custom integration (e.g. Panels, Display suite, ...).
  8. More stuff I have not thought of yet

I would really love to do entity building via YAML Form. Some stuff we would need:

  1. Form elements need to map to a Field API storage type
  2. The field storage needs to change based on changes in the UI. This is starting to sound like an alternate Field UI. I have no problem with that!

Have a look at the form.io project, which syncs an externally defined form definition (in JSON), with a Drupal entity. This is somewhat analogous to what we need here.

I'm sure it would be hard to move to Field API now, but also so powerful. Lets use this issue to discuss.

Comments

moshe weitzman created an issue. See original summary.

jrockowitz’s picture

Moshe, I am glad you are starting this discussion about leveraging the Field API within the YAML Form module. I would like to give some background information about the YAML Form module and why I did not (initially) use the Field API.

First off, I do feel that using Field API for a general form and survey building solution is a very important direction to focus on for Drupal 8. At the same time, I feel the adoption of Drupal 8 has been significantly impacted by the lack of a D8 port of Webforms.

So I decided to create a "re-envisioned" version of the Webform module for Drupal 8. My goal was and still is to build a powerful, easy to use, and flexible way to collect form and survey data. I also feel that Drupal needs to immediately start competing with the much larger Open Source and SAAS form builder market.

Simply put, Form API is a much simpler and more mature system than the Field API. Drupal's Form API is easier for a junior developer to understand and customize. The YAML Form module's usage of Form API has also made it easier for a site builder to build and customize a form/survey. The YAML Form module (and Form API) is intended to collect data while the Field API and its UX is currently focused on building websites and applications.

I know the benefits (and performance implications) of having submission data stored via the Field API. I am not sure that the YAML form module must use the Field API. I do see a lot of potential in having a YAML form work similar to a Form.io form where the "form/survey" acts as frontend to an entity with fields. Maybe a YAML form could initially start out with its current "basic" data storage approach that could be easily upsized to use Field API. Maintaining the basic data storage also addresses the potential performance issue with Field API maintaining 100's of fields on 100's of forms.

The below issues provide some more background information about the YAML Form, Webform , Field API, and Contact Storage module.

This comment is exactly the potential approach we are talking about... https://www.drupal.org/node/2075941#comment-9842689

moshe weitzman’s picture

I do see a lot of potential in having a YAML form work similar to a Form.io form where the "form/survey" acts as frontend to an entity with fields. Maybe a YAML form could initially start out with its current "basic" data storage approach that could be easily upsized to use Field API. Maintaining the basic data storage also addresses the potential performance issue when Field API maintaining 100's of fields on 100's of forms.

That sounds outstanding to me.

jrockowitz’s picture

So I started to plan out a YAML Form Field module using a Google Doc (https://docs.google.com/document/d/11xRWnFOLPvDGVw-oMgf0X5Rn32HctKVvFpcM...). This is still a work in progress but feel free to post comments and suggestions.

I might have come up with a great solution for the "100's of elements creating 100's of fields problem". Instead of automatically converting every YAML Form element to a field, site builders will have to select which elements should have corresponding fields. For example, if there is a form will 100's of survey questions, probably only a few of the form's general elements really need to be fields and available to the Views and/or Rules module, the remaining elements can remain as basic submission data stored in the Entity–attribute–value (EAV) table schema.

Another interesting thought is that a YAML Form's submission and elements could be mapped to any content entity. For example, a YAML Form could be used to create and edit nodes, block content, users, taxonomy terms, etc...

Also by not requiring every element to have a corresponding field, the YAML Form module will still be able to include some very unique "survey specific" elements and features, like Likert and Signature support, which currently do not have any equivalent Field Widgets and Formatters.

Obviously, this is not going to be a trivial amount of work. The work will have to be broken down into manageable tasks.

Stil, I think the key question we need to confirm is "Should the YAML Form module act as a facade (https://en.wikipedia.org/wiki/Facade_pattern) to the Field API?" or is a better approach to incorporate certain aspect of YAML Form module into the Field API or maybe both approaches need to happen at the same time.

ptsimard’s picture

So I don't have one specific point or solution but here are some ramblings related to my quest for a solution.

Another interesting thought is that a YAML Form's submission and elements could be mapped to any content entity. For example, a YAML Form could be used to create and edit nodes, block content, users, taxonomy terms, etc...

This sound quite interesting. Here is a current use-case project I'm evaluating YAML Form for:

A logged-in user need to fill a (draft-able) application form with many fields/files. The form requires the user to add himself as a primary Participant and needs to be able to add an arbitrary number of secondary Participants.

I solved this already in a proof of concept on D7 with 2 content types and Inline Entity Form and Workflow module:

  1. Application content type: includes general application-level fields and an entity reference field for the primary participant (cardinality 1) and another for the secondary participants (cardinality unlimited)
  2. Participant content type: defines all fields related to a person (address, phone, resume, etc)

So this works out well (albeit being a bit complex) and could probably be recreated in multiple ways in D8. Contact Storage or a bespoke solution, using paragraphs maybe for inline editing maybe. For group of repeatable fields, Paragraph seems to be taking over Field Collection (https://www.drupal.org/node/2784931). I wish YAML Form could do this but being Form API-based it seems to be the one dealbreaker limitation, and having to rely on composite elements vs multi sub fields.

YAML Form user friendly interface seems so appealing though and I wonder if it could be extended for such a use case when certain "fields" would be Field API fields and be used inline. But then wouldn't it be weird to have submissions that are half stored in fields and half stored as a form output? YAML Form already seems to "support: entity reference fields.

Still looking for that elusive Unicorn solution.

jrockowitz’s picture

@ptsimard The YAML Form module can already accomplish what you are describing because a YAML Form can be attached to a YAML Form Submission.

In your example, a user would create an Application and then when viewing the Application (aka submission) at the bottom of the page there would be the 'Add Participant form' (as a block). This solution would still require some custom code. Maybe a custom block or page that lists all the participants created for specific 'Application'.

The below video shows to create a Job Application and Evaluation system using the YAML Form block.
https://www.youtube.com/watch?v=CkRQMS6eJII

Keep in mind you should only use this approach if you really just collecting and exporting the information.

Another hybrid approach is the Application is a node (aka Entitiy) and the Participants are YAML Form submissions.

@ptsimard If you have any further questions PLEASE CREATE A NEW TICKET, so that we don't hijack this thread.

fenstrat’s picture

Project: YAML Form » Webform
Version: 8.x-1.x-dev » 8.x-5.x-dev
kirkilj’s picture

I second Moshe's comment and I'm very impressed with the Webform module. I'm investigating using it to populate existing entities as well, given all the functionality and flexibility it provides. I saw an issue someone posted in the D7 version to create a handler that would use a mapping to post a submission's data to an existing entity type. This could use a mapping table to indicate connections between Webform elements and the target entities Field API fields. I also have a requirement of eventual GraphQL support. In some ways, Webform would be the UI view-controller and the target entity would be the model/datastore that has business logic associated with it.. Another kicker is whether bidirectional data sync is required when a user updates the mapped entity and they'd like Webform to pick up the changes. Perhaps a hidden entity reference could be maintained in both directions. I assume it's all doable by comparing timestamps, dirty bits, etc., but I can appreciate the scope of work required in doing so. I'm just starting with Drupal and object-oriented PHP, so I'm afraid I couldn't participate meaningfully in furthering the discussion at the Drupal API level.