myfaces-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Robinson" <andrew.rw.robin...@gmail.com>
Subject Re: ValueChangeListener challenges
Date Sun, 08 Jul 2007 18:34:09 GMT
There is a package in sandbox:

org.apache.myfaces.custom.valueChangeNotifier

Looks like Mario Ivankovits is the author. I didn't see any
documentation for it though.

That will give you change events during the update model.

Another choice, is to queue the results of the events in the backing
bean (IDs of changed Objects for example) and then in an action or
actionlistener, apply the changes to the DB.

Anyone else with a better approach?

On 7/8/07, Vladimir Isakovich <ivlad10@gmail.com> wrote:
> 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:
> org.apache.myfaces.custom.date.HtmlInputDate$UserData@15e6d4a
> ...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 <andrew.rw.robinson@gmail.com> 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 <ivlad10@gmail.com> 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 <andrew.rw.robinson@gmail.com > 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 <ivlad10@gmail.com> 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 < andrew.rw.robinson@gmail.com>
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 < ivlad10@gmail.com> 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 < andrew.rw.robinson@gmail.com>
> 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 < ivlad10@gmail.com>
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
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>

Mime
View raw message