Uploaded image for project: 'Spring Roo'
  1. Spring Roo
  2. ROO-254

enums cannot be entered in web interface

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.0.RC2
    • Fix Version/s: 1.0.0.RC3
    • Component/s: WEB MVC
    • Labels:
      None
    • Environment:
      any

      Description

      The new enum facility does not work with the web-interface. The enumerator field appears as two empty drop-downs. See attached screenshot.

        Issue Links

          Activity

          Hide
          paul.chapman Paul Chapman added a comment -

          Actually manually created enums cause the same error in RC1.

          Show
          paul.chapman Paul Chapman added a comment - Actually manually created enums cause the same error in RC1.
          Hide
          sschmidt Stefan Schmidt added a comment -

          Paul,

          Can you please attach the complete script you used to reproduce this problem? I tried this with the current Roo trunk (rev 347) and the simplest enum possible and its values were presented in a dropdown (although a custom editor is needed).

          Thanks,
          Stefan

          Show
          sschmidt Stefan Schmidt added a comment - Paul, Can you please attach the complete script you used to reproduce this problem? I tried this with the current Roo trunk (rev 347) and the simplest enum possible and its values were presented in a dropdown (although a custom editor is needed). Thanks, Stefan
          Hide
          13yo Tobias Kaatz added a comment -

          I've created the ENUM with the following roo-script (Version 1.0.0.RC2):

          test.roo

            enum type --name ~.domain.RoleEnum
            enum constant --name ROLE_USER
            enum constant --name ROLE_REPORTER
            enum constant --name ROLE_ADMIN
            field enum userrole --type ~.domain.RoleEnum --class ~.domain.Users --enumType STRING --notNull

          The resulting dropdown field is comparable to the one Paul added.

          Show
          13yo Tobias Kaatz added a comment - I've created the ENUM with the following roo-script (Version 1.0.0.RC2): test.roo enum type --name ~.domain.RoleEnum enum constant --name ROLE_USER enum constant --name ROLE_REPORTER enum constant --name ROLE_ADMIN field enum userrole --type ~.domain.RoleEnum --class ~.domain.Users --enumType STRING --notNull The resulting dropdown field is comparable to the one Paul added.
          Hide
          balex Ben Alex added a comment -

          Stefan, further to our earlier discussion I traced SFW SimpleTypeConverter and it handles enums successfully via TypeConverterDelegate.convertIfNecessary(String propertyName, Object oldValue, Object newValue, Class<T> requiredType, PropertyDescriptor descriptor, MethodParameter methodParam) performing a construction of the enum via TypeConverterDelegate.attemptToConvertStringToEnum(Class<?> requiredType, String trimmedValue, Object currentConvertedValue).

          After reviewing the FireBug POST payload and reading SPR-3389 I am not sure SFW is operating correctly by default (given the error it was reporting as of Roo SVN rev 387 is "Failed to convert property value of type java.lang.String[] to required type com.springsource.vote.Gender for property gender" - note String[]). You might like to ask Scott if he concurs.

          In the meantime to support a Roo 1.0.0.RC3 release next week, the simplest solution I can see is to introduce an @InitBinder method along the lines of:

          	@InitBinder
          	public void ChoiceController.initBinder(WebDataBinder binder) {
          		binder.registerCustomEditor(Gender.class, new PropertyEditorSupport() {
          			 public String getAsText() { return (getValue() == null ? "" : ((Enum<?>) getValue()).name()); }
          			 public void setAsText(String text) throws IllegalArgumentException {
          				 setValue(Enum.valueOf(Gender.class, text));
          			 }
          		});
          	}

          The above results in a successful bind and should suffice to close this bug for Roo 1.0.0.RC3 pending more complete resolution with SFW 3.0.0.RC2 refactored binding support. You might wish to consider abandoning the present editor creation and inline them using the above syntax, particularly given the pending removal of editors generally. That way people starting new Roo projects with RC3 need not have editor types in their project that will be removed in RC4.

          Show
          balex Ben Alex added a comment - Stefan, further to our earlier discussion I traced SFW SimpleTypeConverter and it handles enums successfully via TypeConverterDelegate.convertIfNecessary(String propertyName, Object oldValue, Object newValue, Class<T> requiredType, PropertyDescriptor descriptor, MethodParameter methodParam) performing a construction of the enum via TypeConverterDelegate.attemptToConvertStringToEnum(Class<?> requiredType, String trimmedValue, Object currentConvertedValue). After reviewing the FireBug POST payload and reading SPR-3389 I am not sure SFW is operating correctly by default (given the error it was reporting as of Roo SVN rev 387 is "Failed to convert property value of type java.lang.String[] to required type com.springsource.vote.Gender for property gender" - note String[]). You might like to ask Scott if he concurs. In the meantime to support a Roo 1.0.0.RC3 release next week, the simplest solution I can see is to introduce an @InitBinder method along the lines of: @InitBinder public void ChoiceController.initBinder(WebDataBinder binder) { binder.registerCustomEditor(Gender.class, new PropertyEditorSupport() { public String getAsText() { return (getValue() == null ? "" : ((Enum<?>) getValue()).name()); } public void setAsText(String text) throws IllegalArgumentException { setValue(Enum.valueOf(Gender.class, text)); } }); } The above results in a successful bind and should suffice to close this bug for Roo 1.0.0.RC3 pending more complete resolution with SFW 3.0.0.RC2 refactored binding support. You might wish to consider abandoning the present editor creation and inline them using the above syntax, particularly given the pending removal of editors generally. That way people starting new Roo projects with RC3 need not have editor types in their project that will be removed in RC4.
          Hide
          sschmidt Stefan Schmidt added a comment -

          Ben,

          I had a quick chat with Scott and it turns out this is a bug in SWF (see SPR-6190). This problem does not appear when using a nightly snapshot ie. setting <spring.version>3.0.0.BUILD-SNAPSHOT</spring.version> in the pom.xml. So we have several choices here:

          1. Wait for a SWF 3 RC2 release

          2. Provide a workaround for Roo until we can use RC2
          a. do that by changing all property editors to the anonymous inner class style as shown above
          b. do that by providing extra property editors for Enums

          3. do nothing and let users who use Enums point to a nightly snapshots (point out the open bug in the known issues section), followed by a fast release as soon as SWF 3 RC2 is released.

          Personally, my least favorite approach to this is to introduce a second style of type conversion as discussed above (and noted in option 2.a) and then break it again with Roo RC4 (in favor of the new converter / formatter API). If we really want to provide a workaround we should provide a normal property editor (Roo style). I think though that pointing users to the nightly snapshot if they want to use enums in the view should be sufficient though (option 3).

          Cheers,
          Stefan

          Show
          sschmidt Stefan Schmidt added a comment - Ben, I had a quick chat with Scott and it turns out this is a bug in SWF (see SPR-6190 ). This problem does not appear when using a nightly snapshot ie. setting <spring.version>3.0.0.BUILD-SNAPSHOT</spring.version> in the pom.xml. So we have several choices here: 1. Wait for a SWF 3 RC2 release 2. Provide a workaround for Roo until we can use RC2 a. do that by changing all property editors to the anonymous inner class style as shown above b. do that by providing extra property editors for Enums 3. do nothing and let users who use Enums point to a nightly snapshots (point out the open bug in the known issues section), followed by a fast release as soon as SWF 3 RC2 is released. Personally, my least favorite approach to this is to introduce a second style of type conversion as discussed above (and noted in option 2.a) and then break it again with Roo RC4 (in favor of the new converter / formatter API). If we really want to provide a workaround we should provide a normal property editor (Roo style). I think though that pointing users to the nightly snapshot if they want to use enums in the view should be sufficient though (option 3). Cheers, Stefan
          Hide
          balex Ben Alex added a comment -

          I totally concur with you, Stefan. Given RC2 is only days away anyhow, it's reasonable to simply point users affected by this to BUILD-SNAPSHOT or 3.0.0.RC2 in their <spring.version> of the project POM. I suggest you close this bug as it doesn't require any further changes in Roo itself now that we've confirmed SPR-6190 exists. I've also linked the two issues together, so people who find SPR-6190 will be able to see the Roo 1.0.0.RC3 position on it if they're using Roo.

          Show
          balex Ben Alex added a comment - I totally concur with you, Stefan. Given RC2 is only days away anyhow, it's reasonable to simply point users affected by this to BUILD-SNAPSHOT or 3.0.0.RC2 in their <spring.version> of the project POM. I suggest you close this bug as it doesn't require any further changes in Roo itself now that we've confirmed SPR-6190 exists. I've also linked the two issues together, so people who find SPR-6190 will be able to see the Roo 1.0.0.RC3 position on it if they're using Roo.
          Hide
          sschmidt Stefan Schmidt added a comment -

          Closing this bug ticket as all changes necessary on the Roo side to enable Enums in the Web tier are now checked in. As mentioned above there is a Spring Framework 3 RC1 which will be resolved with the release of Spring 3 RC2. For Roo users who wish to expose Enum types in the Web layer we suggest using BUILD-SNAPSHOT in the generated pom.xml file.

          -Stefan

          Show
          sschmidt Stefan Schmidt added a comment - Closing this bug ticket as all changes necessary on the Roo side to enable Enums in the Web tier are now checked in. As mentioned above there is a Spring Framework 3 RC1 which will be resolved with the release of Spring 3 RC2. For Roo users who wish to expose Enum types in the Web layer we suggest using BUILD-SNAPSHOT in the generated pom.xml file. -Stefan

            People

            • Assignee:
              sschmidt Stefan Schmidt
              Reporter:
              paul.chapman Paul Chapman
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: