2 Replies Latest reply on Mar 25, 2010 10:46 AM by sage.sam

    rich:calendar and backing String property

    sage.sam

      I've figured out how to use the standard rich:calendar tag with a backing Date field, and it works great!

       

      I have a bit of an esoteric requirement though to populate a backing String field as a date.  As I don't really want to force the user to enter dates manually in the proper format, I'd like to use the rich:calendar to handle this.

       

      Is there a way to populate a backing bean instance field via the calendar, or do I have to provide get/set methods that deal with the field as a Date?

       

      Is there a way to do this with the Calendar model?

       

      Any information is appreciated.

        • 1. Re: rich:calendar and backing String property
          ilya_shaikovsky

          calendar accepts string objetc as a value and has built-in converter. It just should use the same pattern as defined for calendar.

          1 of 1 people found this helpful
          • 2. Re: rich:calendar and backing String property
            sage.sam

            I found one minor issue, in that my bean value was getting set to an empty string ("") instead of to a null value and that caused the calendar to fail its parse.  This makes sense, though it could perhaps be handled more gracefully.

             

            Once I corrected this problem, the calendar control renders correctly.  However, setting the value back to the bean fails.

             

            Here's the result -- On my UI, I get the following message:

             

            secure/admin/ImRoleEdit.xhtml @54,26  value="#{imRoleHome.instance.roleDescription}":  java.lang.IllegalArgumentException: java.lang.ClassCastException@2b35c7

            Yes, I know this looks odd... As a proof of concept on this, I've been modifying my role editing  screen.  Yes, I know this makes no sense, it was just convenient for  proof of concept work since it is inordinately simple. =)

             

            The same error occurs whether I use the default date pattern or specify my own.
            Preliminary testing shows that if I create my own converter, then I can avoid the ClassCastException and make it work properly!  I just needed some confirmation that this was workable.