Grails
  1. Grails
  2. GRAILS-6882

Add smart field rendering tags (like bean-fields plugin)

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      The bean-fields plugin (http://grails.org/plugin/bean-fields) provides tags that render input fields smartly, namely doing the following:

      • Rendering HTML <label> for the field with the appropriate attributes, and text from i18n or fallback to convention
      • Rendering fields errors inline by the field
      • Rendering of customizable "required" indicator
      • Customization of the layout of these decorated input fields using a template mechanism, where templates are retained for the duration of the request and can be modified during request processing
      • Rendering fields according to the constraints on the command/domain object, where possible.
      • Smart selection of HTML markup to use based on field type
      • Simple rendering of edit fields for list of properties of an object with one tag

      The plugin is well established and provides the basis for the work but there are some suggestions for improvement when pulling into core:

      • Adapt to use Grails naming conventions for field labels
      • Make it easier to define templates, preferably with named stylings/suites of templates. e.g. an artefact with a simple DSL for defining the GSP fragments, so that a form can specify templateName="standardForm" or similar, and all the field templates will be loaded from that suite. Something like this will improve performance also over using g:render to render common GSP that sets up the templates.
      • Improve performance where currently it delegates to existing grails tags, it may be a lot better to use functions in the grails taglibs and have the regular field tags call these also (rather than multiple tag invocations)
      • Examine retro-fitting this functionality to some or all of the existing field tags, such that when the beanName attribute is specified, it switches to smart behaviour. This would prevent a proliferation of similar tags. I think these tags should be in the "g" namespace, and this would avoid such problems. Most of the bean tags delegate to grails tags anyway so the attributes are largely orthogonal
      • Fix the naming/paradigm for overriding "required indicator" when rendering fields, there is confusion about how to force a field to appear mandatory, and I have never been happy about this requiredField attribute name. Look at adding "required" attribute to override required or not, and "requiredIndicator" to override the default required indicator (note the presence of "constraints" attribute override means you can achieve this currently with dummy constraints)
      • Issues with input field not having a template in the same way as other field types

        Issue Links

          Activity

          Hide
          Graeme Rocher added a comment -

          +1 but I think we should keep it as a separate "required" plugin that way we can fix any issues outside the lifecycle of Grails itself

          Show
          Graeme Rocher added a comment - +1 but I think we should keep it as a separate "required" plugin that way we can fix any issues outside the lifecycle of Grails itself
          Hide
          Marc Palmer added a comment -

          Things I've remembered that is problematic in bean fields that need tweaking:

          • use of "requiredField" to set per-field required indicator. To suppress indicator you have to set this to a blank string, naming is ambiguous. Add "requiredIndicator" for the string used, and "required" for flag indicating to show or not
          • input field does not have a customizable template
          • Look at possibility of using the body of the tag as the field template, so you can write ad-hoc templates inline.
          Show
          Marc Palmer added a comment - Things I've remembered that is problematic in bean fields that need tweaking: use of "requiredField" to set per-field required indicator. To suppress indicator you have to set this to a blank string, naming is ambiguous. Add "requiredIndicator" for the string used, and "required" for flag indicating to show or not input field does not have a customizable template Look at possibility of using the body of the tag as the field template, so you can write ad-hoc templates inline.
          Hide
          Marc Palmer added a comment - - edited

          Discussion with Rob Fletcher throws up these thoughts:

          • What tag namespace? "field" I think. <field:auto> <field:form> <field:select>, or even better just <field:PROPERTYNAMEHERE type="overriddenTypeNameHere">
          • Configurable per-class and property field templates/types. e.g. grails.fields.Book.author = 'longtext' and elsewhere "longtext" is defined as a field type ('input') plus a bunch of templates/args
          • Support for out of the box default behaviours that are switchable/compatible between (X)HTML and HTML5
          • Look at augmenting g:form so that the bean name and properties can be specified there, to eliminate need for <bean:required> and <bean:withForm>
          • Clean up the data passed to templates, make it uniform for all template types, include boolean for required/add in constraints info (e.g. for HTML5 number fields)
          • Examine options for convention-based loading of template GSPs (and how to prep these up so they themselves can call other tags in their impls e.g. invoke YUI date pickers etc)
          • Allow UI plugins to provide a set of templates that automatically mix in their UI paradigms, i.e. install jquery-ui and <bean:date> automatically switches to using jquery's Date Picker
          • Re-examine existing core field tags, refine them and perhaps templatize them too / merge all the concepts so that we have templatable regular fields. Or just stop BF relying on them and reimpl that stuff directly in the default templates. This would perform better - but customization of layout should not require re-implementation of this, so add field templating separately. The old g:xxxx field tags could then be deprecated.
          Show
          Marc Palmer added a comment - - edited Discussion with Rob Fletcher throws up these thoughts: What tag namespace? "field" I think. <field:auto> <field:form> <field:select>, or even better just <field:PROPERTYNAMEHERE type="overriddenTypeNameHere"> Configurable per-class and property field templates/types. e.g. grails.fields.Book.author = 'longtext' and elsewhere "longtext" is defined as a field type ('input') plus a bunch of templates/args Support for out of the box default behaviours that are switchable/compatible between (X)HTML and HTML5 Look at augmenting g:form so that the bean name and properties can be specified there, to eliminate need for <bean:required> and <bean:withForm> Clean up the data passed to templates, make it uniform for all template types, include boolean for required/add in constraints info (e.g. for HTML5 number fields) Examine options for convention-based loading of template GSPs (and how to prep these up so they themselves can call other tags in their impls e.g. invoke YUI date pickers etc) Allow UI plugins to provide a set of templates that automatically mix in their UI paradigms, i.e. install jquery-ui and <bean:date> automatically switches to using jquery's Date Picker Re-examine existing core field tags, refine them and perhaps templatize them too / merge all the concepts so that we have templatable regular fields. Or just stop BF relying on them and reimpl that stuff directly in the default templates. This would perform better - but customization of layout should not require re-implementation of this, so add field templating separately. The old g:xxxx field tags could then be deprecated.
          Hide
          Marc Palmer added a comment -

          The conventions for GSP templates could work like this:

          grails.fieldtemplates.view.path = '/myfieldtemplates'
          grails.fields.Book.author = 'longtext'
          

          Then in the tags we do the equivalent of:

          g:render(template:config.fieldtemplates.view.path+'/'+config.fields[className][propertyName])
          
          Show
          Marc Palmer added a comment - The conventions for GSP templates could work like this: grails.fieldtemplates.view.path = '/myfieldtemplates' grails.fields.Book.author = 'longtext' Then in the tags we do the equivalent of: g:render(template:config.fieldtemplates.view.path+'/'+config.fields[className][propertyName])
          Hide
          Marc Palmer added a comment - - edited

          More tweaks:

          • Why do we require valueOverride instead of reusing "value" attribute? Overriding the actual value is useful (e.g. in password fields) but I don't know why we had to go for valueOverride in the past. Also if you include value="xxx" it is passed through and two written. We need to adapt the attribute handling to merge attributes with those supplied, and write out only one set, such that values supplied by the user override any applied by bean-fields
          • Change name of bean:require to something that can not be confused with bean:required/requiredIndicator
          • Improve error handling such that if a bean has "constraints" property but it is still a Closure. This happens if you add @Validateable but don't add to the packages to scan, and results in confusing errors.
          Show
          Marc Palmer added a comment - - edited More tweaks: Why do we require valueOverride instead of reusing "value" attribute? Overriding the actual value is useful (e.g. in password fields) but I don't know why we had to go for valueOverride in the past. Also if you include value="xxx" it is passed through and two written. We need to adapt the attribute handling to merge attributes with those supplied, and write out only one set, such that values supplied by the user override any applied by bean-fields Change name of bean:require to something that can not be confused with bean:required/requiredIndicator Improve error handling such that if a bean has "constraints" property but it is still a Closure. This happens if you add @Validateable but don't add to the packages to scan, and results in confusing errors.
          Hide
          Mukhamad Ikhsan added a comment -

          Suggestion : add compatibility in datePicker&timePicker for joda time.

          Show
          Mukhamad Ikhsan added a comment - Suggestion : add compatibility in datePicker&timePicker for joda time.
          Hide
          James Lang added a comment -

          Marc Palmer mentioned on Grails user a few weeks ago that Robert Fletcher was doing some work on this for 2.0 release.

          Is bean fields plugin what it is (i.e. remains in its present excellent, but flawed state) and no alternative will be available, or can grails community look forward to some movement on this front for 2.0 RC-1 or 2.0 final?

          Show
          James Lang added a comment - Marc Palmer mentioned on Grails user a few weeks ago that Robert Fletcher was doing some work on this for 2.0 release. Is bean fields plugin what it is (i.e. remains in its present excellent, but flawed state) and no alternative will be available, or can grails community look forward to some movement on this front for 2.0 RC-1 or 2.0 final?
          Hide
          Marc Palmer added a comment -

          No further effort of mine will be put into bean-fields other than any critical bug fixes that emerge. The time I have will be put into helping with the new code Rob is writing.

          However there is no ETA, other than we all want it done ASAP. It's unpaid work.

          Show
          Marc Palmer added a comment - No further effort of mine will be put into bean-fields other than any critical bug fixes that emerge. The time I have will be put into helping with the new code Rob is writing. However there is no ETA, other than we all want it done ASAP. It's unpaid work.
          Hide
          James Lang added a comment -

          Understood re: non-core staff doing grails work completely pro bono. Just trying to get an idea where things are at. Too bad Bean fields or some version of it is not in core as it is the forms equivalent of GORM, which is to say, vital.

          Show
          James Lang added a comment - Understood re: non-core staff doing grails work completely pro bono. Just trying to get an idea where things are at. Too bad Bean fields or some version of it is not in core as it is the forms equivalent of GORM, which is to say, vital.
          Hide
          Marc Palmer added a comment -

          Yes, well the new stuff is planned to be a "core" contrib, but this line is not clearly defined. Basically there is a core paid S2 team, but we still contrib as we can to "core" plugins e.g. Resources has no paid maintainer.

          Show
          Marc Palmer added a comment - Yes, well the new stuff is planned to be a "core" contrib, but this line is not clearly defined. Basically there is a core paid S2 team, but we still contrib as we can to "core" plugins e.g. Resources has no paid maintainer.
          Hide
          James Lang added a comment -

          If it makes it into core for 2.0 there will be many grails developers kicking azz (forms are the single most time consuming process in web devel).

          Anyway, did not know that anyone was paid apart from Spring staff members graeme, burt, peter and jeff (these are the ones I know of at least). Actually surprised you are not working for Spring...

          Show
          James Lang added a comment - If it makes it into core for 2.0 there will be many grails developers kicking azz (forms are the single most time consuming process in web devel). Anyway, did not know that anyone was paid apart from Spring staff members graeme, burt, peter and jeff (these are the ones I know of at least). Actually surprised you are not working for Spring...
          Hide
          Graeme Rocher added a comment -

          The 'fields' plugin implements this feature (see http://grails.org/plugin/fields), I'm not convinced it is needed in core. Now that the scaffolding plugin has been split out of core even less

          Show
          Graeme Rocher added a comment - The 'fields' plugin implements this feature (see http://grails.org/plugin/fields ), I'm not convinced it is needed in core. Now that the scaffolding plugin has been split out of core even less
          Hide
          cdeszaq added a comment -

          I agree. The fields plugin handles this well, and it's better to leave it in an independent plugin, rather than tie it to the core. It would be nice to add a bit to the core docs, however, that points people to the fields plugin for this functionality. (or any other plugins that do similarly)

          Show
          cdeszaq added a comment - I agree. The fields plugin handles this well, and it's better to leave it in an independent plugin, rather than tie it to the core. It would be nice to add a bit to the core docs , however, that points people to the fields plugin for this functionality. (or any other plugins that do similarly)

            People

            • Assignee:
              Marc Palmer
              Reporter:
              Marc Palmer
            • Votes:
              23 Vote for this issue
              Watchers:
              19 Start watching this issue

              Dates

              • Created:
                Updated:
                Last Reviewed:

                Development