BTW - a value change event does not mean the data has been changed.
What I mean by this is that the valueChangeEvent is fired during
validation, not updating. This means that there is no guarantee that
the updateModel method of the component will ever be executed, and
thus your database would now be corrupted with incorrect data.
I think there is a sandbox component for value change events to be
fired during the update model phase instead.
Also, why not use your setter property to be "notified" of when data changes?
In terms of why you are getting the message, your dates are not the same.
..validate: previousValue: 2007-01-02 00:00:00.0 convertedValue: Tue
Jan 02 00:00:00 EST 2007
As you can see, they are different. If they were the same, the *exact*
same output would be displayed. It doesn't look like the previous
value is a Date at all. Is it a java.sql.Date or something? Also does
it have a timezone (odd that one isn't being printed).
It looks as if you are comparing apples and oranges...
-Andrew
On 7/8/07, Vladimir Isakovich <[EMAIL PROTECTED]> wrote:
Andrew,
I had no problem with 'correcting' null/"" valueChangeEvent issue in my app,
but I'm facing a weird problem with date fields always firing
valueChangeEvent. What's wrong? I recall you as saying 'nobody is using this
event'. Then what should I use? My goal is avoiding calls to DB for every
row, only calling with really updated rows.
I have them inside dataTable, but for making it simpler, I'll use just one
field in this code excerpt. On the page:
<t:inputText value="#{order.orderDate}"
valueChangeListener="#{ customers.orderChanged}" id="orderDate">
<f:convertDateTime type="date"
dateStyle="default" timeZone="EST"/>
</t:inputText>
After placing some System.out in UIInput.validate() as follows:
public void validate(FacesContext context)
{
if (context == null) throw new
NullPointerException("context");
Object submittedValue = getSubmittedValue();
System.out.println("...validate: submittedValue: "+submittedValue);
if (submittedValue == null) return;
Object convertedValue = getConvertedValue(context, submittedValue);
if (!isValid()) return;
validateValue(context, convertedValue);
if (!isValid()) return;
Object previousValue = getValue();
System.out.println("...validate: previousValue: "+previousValue+ "
convertedValue: "+convertedValue);
setValue(convertedValue);
setSubmittedValue(null);
if (compareValues(previousValue, convertedValue))
{
queueEvent(new ValueChangeEvent(this, previousValue,
convertedValue));
}
}
I see in my log:
...validate: submittedValue: Jan 2, 2007
...validate: previousValue: 2007-01-02 00:00:00.0 convertedValue: Tue Jan 02
00:00:00 EST 2007
And as a result I'm gettin the valueChange Event.
thanks
vlad
On 7/7/07, Andrew Robinson <[EMAIL PROTECTED]> wrote:
> I you change a component's code and that component is reusable, then
> you will affect its behavior everywhere you use it. That was all I was
> saying.
>
> In terms of affecting the value change event for one component on a
> page, it wouldn't hurt anything that I am aware of. Most of the time
> valueChangeEvents are not used.
>
> On 7/7/07, Vladimir Isakovich <[EMAIL PROTECTED]> wrote:
> > You've lost me. What you mean by 'Depends on who is listening for the
> > events'? I thought - #{myBean.someMethod} is.
> > Am I missing something?
> >
> > And there is no garantee from introducing a bug with any new code - this
is
> > our life. Testing is always a part of dev. But how is it relevant to
what
> > we're discussing?
> >
> > vlad
> >
> >
> > On 7/7/07, Andrew Robinson < [EMAIL PROTECTED]> wrote:
> > > Depends on who is listening for the events. Can you guarantee that
> > > there will be no bugs in your code from doing this?
> > >
> > > On 7/6/07, Vladimir Isakovich < [EMAIL PROTECTED]> wrote:
> > > > Andrew,
> > > > could you give me an example (use case) when I'm sending out a null
> > value,
> > > > then on submit get "" back, and there is any harm of stopping
> > > > valueChangeEvent from being fired.
> > > >
> > > > I can't come up with one.
> > > >
> > > > Sure, I may write some logic or a converter wraper in order to
prevent
> > this
> > > > unwanted event, I just was pointing to the fact that I was expected
this
> > > > from non altered framework.
> > > >
> > > > vlad
> > > >
> > > > On 7/6/07, Andrew Robinson < [EMAIL PROTECTED]> wrote:
> > > > > null has a special meaning, and thus why null != "" in terms of
> > > > > UIInput. Null means that the value was not submitted at all. ""
means
> > > > > the value was submitted with no value. Thus why you need to
convert ""
> > > > > to null if that is what you wish. If the renderer converted "" to
> > > > > null, then there would never be an update of the model.
> > > > >
> > > > > If you want, write a chain converter or a converter wrapper that
> > > > > converts "" to null.
> > > > >
> > > > > It may look like:
> > > > >
> > > > > <h:inputText ...>
> > > > > <my:emptyToNullConverter wrapConverterId="javax.faces.Integer " />
> > > > > </h:inputText>
> > > > >
> > > > > then you can first check for "" and convert it to null, and if
not,
> > > > > delegate the check to the "inner converter"
> > > > >
> > > > > On 7/6/07, Vladimir Isakovich < [EMAIL PROTECTED]> wrote:
> > > > > > Although null and date are two separate issues, but I'm gettin
the
> > > > picture.
> > > > > > I may create my own converters and attach them to all my fields
as
> > I'm
> > > > > > pleased. But I'm trying to have some common services (if
thay're
> > > > missing in
> > > > > > the framework) in a single place, well this may be arguable
what's
> > > > better.
> > > > > > Sorry for annoyance, but still, why JSF would not check for
nulls
> > for me
> > > > > > (you've pointed the right method to be changed).
> > > > > >
> > > > > > With the date conversion I'll postpone the issue, I have to
spend
> > more
> > > > time
> > > > > > tracing it.
> > > > > >
> > > > > > vlad
> > > > >
> > > >
> > > >
> > >
> >
> >
>
