Use Field API

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.

• #2075941: Port Webform to Drupal 8
• #2582955: Contact module roadmap: 80% usecase of webforms in core
• #2473983: [meta] Evaluate Entity Field API Scalability

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

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.

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.

@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.

Moving to Webform queue, see #2827845: [roadmap] YAML Form 8.x-1.x to Webform 8.x-5.x.

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.

Owen Merill's D8 Webform and Webform Views Integration presentation is a good example of how a webform submission could be pushed to a node.

According to @larowlan in a comment on a blog post about webform and contact module, he states that one of the primary reasons to pick webform over core's contact module is that it does *not* use the Field API:

As a maintainer of contact in core and contact_storage in contrib I want to point out that there are some things that webform is better suited to - that contact module cannot do.
These are

* Forms with lots of fields. Each field is a config object and this can increase the size of your fieldmap, as well as the number of tables. Webform stores its data in a single table, Field API stores fields in one-table per field. There is obviously a storage and performance implication there (This is the same issue with entityform in D7).

* Multipage forms (although fieldgroup in contrib might power this for contact module)

* Lots and lots of forms. Each contact form is a new entity-type bundle so adding lots is equivalent to adding lots of content types. (This is the same issue with entityform in D7).

Seems like if you want a webform with all the power / flexibility / baggage of using Field API directly on an entity, you should leave webform alone and use the core contact module and Contact storage. If you need lots of fields and want something performant, keep using webform. ;)

Therefore, -1 to this issue, at least as I currently see it.

Hey there
I'm currently implementing a website with the Paragraphs, Webform and GraphQL module. Works fine, exepct for Webform as it's not possible to fetch fields with GraphQL. The only workaround I've found is to separately use Webform REST. However, it feels wrong to work with it when it actually should be usable with GraphQL.
Has anyone of you started working on something or found a workaround for using Webform with GraphQL?

There is a limit to how much can be supported in the core webform module for Drupal 8 which is why there is a Webform REST and a Webform Views module, this allows people to collaborate and build these integrations at a different and ideally faster pace.

This is an interesting discussion. Webform scales very well in its current incarnation and I wouldn't like to see that change.

We're starting to look at using Webform in a different way which leverages the speed and simplicity of webform's storage system. Previously we've used the data module for such purposes but for Drupal 8 we were considering writing a custom entity type.

However, with Webform @jrockowitz has done a lot of the hard work. And given the amount of support it gets from the community, webform could be a good base entity type.

Just a note that this is for an internal database system which would have a large amount of simple related data.

I think with the tagging of a stable release of Webform 8.x-5.x…this ship has sailed.