bean fields core integration

This page is for the discussion of proposed merging of a successor to the bean-fields plugin into Grails core.

Levels of modularity

1. The top-level GSP, e.g. a scaffolded create.gsp or edit.gsp. This is responsible for selecting the fields to be used and laying them out in relation to one another.
2. The markup surrounding each input. This would include label tags, any surrounding div or other container, per-field error messages, etc. This would be the same for the majority of fields in a project but needs to be customisable for special cases.
3. The input itself. The input rendered should be appropriate to the property type, e.g. select for enums, checkbox for booleans, etc. However, this needs to be customisable on a per-field basis and a per-type basis across the project. i.e. if I want to use radio inputs for a particular enum instead of a select I should be able to configure that once and have it used in any form that renders an input for that enum type.

Use cases

Scaffolding

Grails scaffolding could use a modular, convention-driven way to render a form for a domain instance. The existing create.gsp and edit.gsp iterate over the persistent properties and instead of using the monolithic renderEditor.template can use a tag such as <bean:field bean="${domainInstance}" property="foo"/>. The exact markup this renders can be customised on a per-property basis falling back to a default with automatic input type selection based on the property type.

Extensibility by plugins

A good example is the Joda-Time plugin being able to register default input rendering for the types it supports which gets picked up so that <bean:field bean="${domainInstance}" property="jodaLocalDateProperty"/> renders the correct input with the same surrounding markup in terms of labels, mandatory indicators, etc. as any other field. Again it should be possible for a user to override how this is done.

Embedded properties

Currently these are not handled by scaffolding and it's problematic to do so within the limitations of renderEditor.template. It would be useful to have recursive rendering so that the properties of embedded types could be grouped inside a fieldset for example.

HTML5 constraints

The bean-fields plugin currently adds mandatory indicators but with HTML5 we can mark fields up with the required boolean attribute. Also there are other constraint-type attributes such as pattern, min, max and range that could be automatically rendered on inputs where appropriate. This implies we probably need access to the ConstrainedProperty instance inside the templates and a standard way of converting that to HTML attributes.

Mandatory indicators

bean-fields allows for adding a mandatory indicator but it can be a bit inflexible if you want to do something like adding a class to the surrounding div element and using CSS content generation to apply the indicator. Supporting this kind of flexibility is essential. CSS can also use the :required and :optional pseudo-classes in current browsers so hardcoding asterisk characters in the markup is increasingly non-optimal.