Entity forms

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
Anonymous's picture

Hey guys i'm being bold here. But i couldn't figure out where to add D8 feature request so i thought i gave it a shot here.

I was wondering if what the pro's and con's are of making forms more entity'ish..

Why not make "all" the forms based on this form.entity type. Adding field (and thus widgets) would be a breeze (from a UI perspective). In core there are a few "fixed" forms like:
- the login form
- the contact form
- the password forget form
- the comments form
- the modules forms (like rating of add to cart)
- e.t.c.

Changing these form's isn't that easy, for example:
- if you want to add some text to the contact form you, have to make a block, and position it in the right region on the right path..
- if you want to change the order on the node add /edit form fields you'll have to change the weight by using a form_alter

As i see it, a form submit would still invoke a hook of rule to handle the validation and submitting.

pro's
- site admins have more control over the forms
- it could be staged by using the configuration management
- modules could more easily hook into it
- it fits nicely into Dries frase "Do well, Do good"

con's
- it is a major change since all modules require some sort of form

what are your thoughts about it ???

i'm eager to help..

Comments

I'm not quite following the

lex0r's picture

I'm not quite following the idea you described, could you plz answer what is wrong with coding of additional form behavior you need for your specific purposes?

I think it is always possible to make something easier from developer's point of view, but that may hurt the whole idea and balance between easiness of use and flexibility.

There is certainly nothing

willembressers's picture

There is certainly nothing wrong with coding additional form behavior.. For me (as a developer) it's quite easy to do.. But there are limitations...

There are the system forms, content forms and "user" forms. All have their different usabilities. The user forms (comments / login / etc) is what the anonymous will see and require more visual interaction aspects whereas the same forms for authenticated users require more access and control aspects.

Also a site manager (not nesseccarly the admin) cant control the forms much (out of the box).

As i see it, a form entity will force modules to use this entity and give developers more flexibility and managers more control.

For example: adding a field to a bundle would also add a form field instance to the form entity. but then managers could more easily control the form. A site manager would then see an extra tab "manage form" to the content type (just like "manage fields") and control the settings of the widgets per form type (content / front end).

I think the easiness between use and flexibility could come from defaulting as much as possible, but also make it more configurable.

I'm not entirely sure I

cleaver's picture

I'm not entirely sure I understand what you are proposing, but I do think the form API could use a major overhaul. For me, the change to the form system would be to make it object-oriented. This would be more of an API change and would be for developers and not usability (and therefore out of scope for this group).

A better form API would make usability enhancements such as what you suggest easier, but still would not get around the hook_form_alter() on their own. The ability to override forms from core would be like adding a UI to hook_form_alter(). I'd see that as something you could try out in a contrib module. It would be quite complex, however, as you have both the hook_form_alter, but also hook_theme to deal with.

I'm not saying that we should

willembressers's picture

I'm not saying that we should get rid of the hook_alter "au contraire", it's awesome..

What i'm trying to say is to add more abstraction to it. so that developers can control forms at an higher level..

This could result in an contrib modules that:
- add management tabs to forms.
- make forms stage able (into config files)
- facilitating custom webforms
- adding different displays (view modes) to forms
- ...
based on the abstact layer

I would suggest 3 types of forms
- config forms, (that controls the config files directly)
- content forms (For adding/editing all sorts of entities)
- frontend forms (for more specific interaction)

Sort of like

Yep.. but then more baked

willembressers's picture

Yep.. but then more baked into core, so that developers can have also more cortrol over the core forms.

But since the D8 feature freeze deadline is passed, this topic could be closed (unless someone is still interested).

Usability

Group organizers

Group categories

UX topics

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week