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
> > > >
> > >
> > >
> >
>
>

Reply via email to