Yes, I am using a <h:commandButton> with its attribute immediate=false.
After sending my initial email, this is what I noticed ...

When I had <t:inputCalendar> with its attribute readonly=true, the text
portion of the control was not editable (correct behavior) but I could
click the calendar portion of the control and choose a different date,
which was then reflected in the text portion of the control
(questionable behavior???) but was not updated in the backing bean. Once
the page re-loaded, the inputCalendar controls were set to the original
dates again. My guess is that since the control was set to
readonly="true", that might have been why its value was not being
updated in the backing bean??? Once I made readonly=false, the backing
bean was able to access the updated value. The only bad thing is that
now I have to add a converter and/or validator. Does somebody know if
the behavior with readonly=true is actually a bug or is that really how
it is supposed to work?

- Usman

-----Original Message-----
From: simon [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 01, 2008 9:04 AM
To: MyFaces Discussion
Subject: Re: inputCalendar not saving value into backing bean


On Wed, 2008-04-30 at 12:27 -0400, Malik, Usman wrote:
> Hi,
> 
> I have a simple form with a drop-down list (storeNum), couple of 
> inputCalendar fields (minDate and maxDate) and a submit button. All 3 
> controls are tied to a backing bean ... the drop-down list is tied to
a 
> String variable and the 2 calendar fields are tied to Date variables 
> (all have getter/setter methods). All 3 controls are set to some 
> initial value that I set in the backing bean programmatically. I also 
> have a submit button in the form that has its action set to a function

> in the same backing bean as above. The function returns a blank string

> at the end, so after all the processing the JSF navaigation should 
> re-load the same page.
> 
> I am still a newbie at JSF but I believe that when I click the submit 
> button, all the tied variables in the backing bean should be updated 
> with the latest on-screen values, and then the action function should 
> be executed. Inside the action function, I simply check the values of 
> all my tied variables (storeNum, minDate, maxDate) before returning an

> empty string. The problem I am running into is that if I change any of

> the dates on-screen, they are not updated in the backing bean when I 
> interrogate them in the action function. However, the storeNum 
> variable IS updated correctly when I interrogate it in the action 
> function.
> 
> Is the problem just in my understanding of the JSF model or something 
> else is at play here? Any help would be much appreciated. Btw, I have 
> tried the relevant example at Irian 
> [http://www.irian.at/myfacesexamples/calendar.jsf] and if I add an 
> action function and interrogate the date values, they are having the 
> same problem in that example too!

Hmm..

By "submit button", I presume you mean an h:commandButton.

What you are seeing would be the expected behaviour if your
commandButton had immediate=true set. In that case, the action method
will be invoked before the properties that the other input controls
reference. 

A common mistake is for a page to not have an h:messages tag; then when
validation fails on a field it isn't obvious. But in your case, the
action for the button is running, which would not happen if validation
was failing.

If you definitely are not setting the immediate flag, then I suggest
including the actual JSF page in your next email so we can have a look. 

Regards,
Simon

NOTE: The information in this email may be confidential and legally
privileged. If you are not the intended recipient, you must not
read, use or disseminate the information; please advise the sender
immediately by reply email and delete this message and any
attachments without retaining a copy. Although this email and any
attachments are believed to be free of any virus or other defect
that may affect any computer system into which it is received and
opened, it is the responsibility of the recipient to ensure that it
is virus free and no responsibility is accepted by RGIS, LLC for
any loss or damage arising in any way from its use.

Reply via email to