Should forms be arranged in layouts too ?

jide's picture

Hi there !

There is an ongoing discussion at on whether SCOTCH should allow forms to be arranged in layouts.

To sum up, this has begun because we now want the node form to be a 2 columns layout. While discussing this, we realized that SCOTCH could eventually be used to put form parts into layouts, instead of some custom form API / markup / CSS tricks.

Having this possibility would be really nice, forms could benefit from layouts in a lot of places, not only the node form.

What do you think ?


From my point of view,

Bojhan's picture

From my point of view, definitly. It obviously depends to what extend layout parts get into Core, but we should not restrict ourselfs to only pages.

Please talk to @swentel

sun's picture

Please talk to @swentel before discussing this any further.

Daniel F. Kudwien
unleashed mind

I'll try to catch @swentel on

jide's picture

I'll try to catch @swentel on IRC.

Of course I want this, but as

swentel's picture

Of course I want this, but as Bojhan points out, a lot is going to depend on how fast Scotch gets layouts going in core. If we have a decent API which we can reuse for also managing forms (and also the display of entities for every view mode) that would be great, even if in the end we need to do this in contrib.

My experience dealing with this in contrib (note: I (co-)maintain first 2 modules)
- fieldgroup module: allows you to nest elements, from simple div wrappers to vertical/horizontal tabs. It does not use a template file but uses the concept of #groups (not #group we have in core now) and a post_render function to move all elements into the right place. How they float etc is then a matter of css.
- Display Suite (which comes with Field UI forms support) uses template files and a preprocess function which comes at the very end creating variables which map to regions and then sends them out to the template file. Extremely easy.
- Page manager: works fine but I don't use it very ofter as it lacks easy 'nesting' functionality - think 'Fieldgroup inception'

The benefit of these approaches:

  • it does not touch the form/form_state structure at all, so no problems with validate functions and so on. The example at in my opinion is bad, in the end a hook_form_alter should not be the answer to move elements around if people want to.
  • It can work for any form

So my ideal implementation for now, even if scotch can't make it for forms in time:

  • The node form's #theme key is by default 'form-2-column'.
  • Create a form-2-column.tpl with 2 regions
  • Create a form_2_column_preprocess function which takes a parameter, say #regions which keys are regions and value is an array of elements which need to rendered which can be found into $form or $variables['form'].

Of course, the name of the tpl etc can be debated.

Looking at the content add screen, it's not even a problem for Field UI at this point as all fields are in the left region, contrib can either add the concept of layouts later on via core/scotch or else, I'll port Display Suite to D8 :)

See (the form template) and (the preprocess function - it does a lot more specific things for DS but one should understand the idea)

Will try to come up with some more ideas later, need to sleep now:)

Patch ready for review

ry5n's picture

@swentel Thanks again for your input on this. I've put together a new patch for based on your suggestions but it's not complete and may not be quite right. Would you be willing to review it? It would be a great help.