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

    rich:calendar and backing String property


      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

          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

            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.