Yes, this is (about apples and oranges) what I'm trying to find. My backin
type is java.util.Date. May be this is a problem?
I just tried example with t:inputDate, and this is what I'm getting (much
nicer):
INFO %%%%%% entering APPLY_REQUEST_VALUES(2) in
org.apache.myfaces.lifecycle.LifecycleImpl
INFO %%%%%% entering PROCESS_VALIDATIONS(3) in
org.apache.myfaces.lifecycle.LifecycleImpl
...validate: submittedValue:
[EMAIL PROTECTED]
...validate: previousValue: Sun Jul 08 12:21:36 EDT 2007 convertedValue: Sun
Jul 08 12:21:36 EDT 2007
INFO %%%%%% entering UPDATE_MODEL_VALUES(4) in
org.apache.myfaces.lifecycle.LifecycleImpl
In the core of $UserData I see Calendar as a data holder.
Also, I think I'm missing some important part of my JSF education. May be I
should not use valuechangeEvent at all and rather wait for the updateModel
phase, but this way how am I going to stop those not really updated rows
from being sent to DB.
In my case there is a List<Customer> in my backing bean which is represented
by dataTable on the page. I'm using valueChangeEvent on every field for
catching those rows with updates, and then with my Submit button pointed to
save() method I'm sending only those rows to DB.
vlad
On 7/8/07, Andrew Robinson <[EMAIL PROTECTED]> wrote:
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
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>
