Formal approval for Phase 2 of 80% usecase of webforms in core

Thanks @pameela
Updating issue summary with the sign off table. I have added the signoff needed by a framework manager as the issue was tagged with Needs release manager review Feel free to update the issue summary if its not needed.

// Naveen

In order to provide sign-off here from a product management POV, I need a bit more context as to what these features mean in terms of end-user facing functionality. What are the problems currently? What will the list of features get us at the end? Why do we think that's the right stuff to work on, and in the right order?

What are the problems currently? What will the list of features get us at the end? Why do we think that's the right stuff to work on, and in the right order?

I think we covered all that during our call on Fri 3 Jun 2016 or Thu 2 Jun 2016 for @xjm and @webchick. These are all those issues we specifically discussed on the call with @webchick and @xjm. We just want to get the formal approval on that.

If you still need further information then we can setup another call.

Changing a status to get a reply.

Just wondering if the problem of scaling was discussed in the process.

It was mentioned by larowlan here about a year ago:

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

and:

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

Can't find discussion about this in the issue queues but it does seem to be one of the reasons people are choosing yamlform instead of contact + contact_storage.

@askibinski Many forms/fields is indeed an issue for contact & contact_storage, however I believe that would fall into the 20% usecase for webform (FYI yamlform looks set to rename to webform).

I think we covered all that during our call on Fri 3 Jun 2016 or Thu 2 Jun 2016 for @xjm and @webchick. These are all those issues we specifically discussed on the call with @webchick and @xjm.

is it possible to inform others or should @webchick and @xjm be the ones who are informed on calls only? You can imagine people will look at this, its a public posting and wonder what are the problems being solved, etc. That @webchick and @xjm have been told on a phone call sounds good, but not very informative unfortunately :/

In light of Webform being alive and kicking for D8, I wonder if that changes the desire/need for this. What do people think?

As maintainer of contact I still sure parts of contact storage should be updated in core at least, for example storage itself which is used in core tests

Webform showed incredible growth and some parts could be moved to core for sure!
- WebformElement - could be a foundation of "elements-NG" for core cos a lot code duplication
- WebformHandler - could be integration to core contact for submission where by default we have only "EMail" no storage

The WebformElement plugin acts as a wrapper around Core's Element plugin so that form and render elements can be integrated into Webform module. In many ways, the WebformElement plugin contains similar/duplicate code from FieldType and FieldWidget plugins.

The big difference between Drupal's Field API and Webform's Element API is Field API is focused on flexibility at the presentation layer while Webform's Element/Handler APIs are focused on flexibility at the data collection/form layer. I feel that Drupal's adoption of a front-end framework for the admin UI is going to significantly change Drupal's Form API. There are some nuances addressed by the WebformElement plugin that could help Form API. For example, the WebformElement plugin defines all of a form element's default and translatable properties. It also provides methods to determine if an element returns multiple and/or composite values.

WebformHandlers are very similar to the Rules module's Action plugins. The only benefit that WebformHandlers has over Rules is a simpler UI/UX. I think exploring bringing the Rules module into Core could solve how the Contact module manages and sends an email. Core would benefit from having a universal and customizable mechanism to send notifications. For example, many aspects of the user registration emails are hard-coded when they should/could be fully configurable via the Rules modules. It would be pretty awesome to be able to confirm user registrations via a Slack channel.

In summary, elements-NG is going to require a lot of thought and planning especially if Core is going to be leveraging a front-end framework like React. BTW, Drupal could learn a lot from Form.io's approach to building and distributing forms to multiple channels.

If Drupal Core was to improve the ability to send notifications, it would solve multiple changes faced by the Contact module or other modules. In theory, if any entity could send notifications, we may no longer need a dedicated Contact module, since any Entity could potentially act as Contact form especially if we then allowed backend-storage to be optional.

@jrockowitz thanx a lot for explanation! There's ongoing work about forms-ng #2913372: Allow forms to be defined in three segments: schema, UI, data

Looks we have 3 "actions" plugins - core, rules & webform)

Need review from product/release manager.