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.