[jira] Updated: (MYFACES-625) ValueChangeListeners are fired for a change from a null value to an empty String

["Howard Abrams (JIRA)" <de...@myfaces.apache.org>]

     [ http://issues.apache.org/jira/browse/MYFACES-625?page=all ]

Howard Abrams updated MYFACES-625:
----------------------------------

    Fix Version: 1.1.3

> ValueChangeListeners are fired for a change from a null value to an empty String
> --------------------------------------------------------------------------------
>
>          Key: MYFACES-625
>          URL: http://issues.apache.org/jira/browse/MYFACES-625
>      Project: MyFaces
>         Type: Bug
>   Components: Implementation
>     Versions: 1.1.0
>  Environment: Windows XP / Linux; Oracle OC4J 10.1.2
>     Reporter: Daniel Löbbe
>      Fix For: 1.1.3

>
> Conversion from the MailingList:
> Interesting!
> it might be this or the valueChangeListener should not be fired for a change from a null to an empty String.
> Please open a jira-issue on this and include our discussion.
> regards,
> Martin
> On 9/26/05, Daniel.Loebbe@bertelsmann.de <Da...@bertelsmann.de> wrote:
> >
> > Hi,
> >
> > your explanations sound reasonable, but do not really help us. For most of the input fields, we do not use a value binding to a java beans field, but bind the components themselves (e.g. HTMLInputText). And those are initialized by their default constructors (new HTMLInputText()) without setting any value.
> >
> > Therefore for me it seems, that the MyFaces implementation sets the default value value of these components to null instead of an empty String. Setting the value to "" after the submit without any user input is not consistent then.
> >
> > Bye, Daniel
> >
> >
> >
> >
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Martin Marinschek [mailto:martin.marinschek@gmail.com]
> > Gesendet: Montag, 26. September 2005 09:19
> > An: MyFaces Discussion
> > Betreff: Re: Migration to 1.1.0 causes ValueChangeListener problems
> >
> > Sorry for ignoring your post,
> >
> > here the answer:
> >
> > MyFaces 1.0.9 had a TCK compatibility bug with respect to setting nulls back to the backend, instead of an empty string.
> >
> > I still haven't checked though if a value change listener ought to be fired in this case. I would suppose that not, but will need to check the RI what it does in this case.
> >
> > Fancy checking it out and open a jira issue if we don't do as the RI does?
> >
> > regards,
> >
> > Martin
> >
> > On 9/26/05, Boris Klug <bo...@debeka.de> wrote:
> > > Hi!
> > >
> > > I had the same problem. I figured out that we set most values to 
> > > null, not to an empty String (""). After submitting the form, the 
> > > value was an empty String, so the value changed and the events get fired.
> > >
> > > We changed the initial value to an empty String and now I no longer 
> > > get the valueChangedEvents.
> > >
> > > See my posting here:
> > > http://www.mail-archive.com/users%40myfaces.apache.org/msg09062.html
> > >
> > > I asked there if this is the normal behaviour but got no answer.
> > >
> > >
> > >
> > > Daniel.Loebbe@bertelsmann.de wrote:
> > > > Hi,
> > > >
> > > > I upgraded our app simply by replacing the jars of the 1.0.9 
> > > > version against the new ones (configuration changes have not been necessary).
> > > > Almost everything of the application works fine but:
> > > >
> > > > When a form is submitted, all methods which are registered as 
> > > > valueChangeListener are called, even if the concerning UIInput has 
> > > > no value or the value has not been changed.
> > > >
> > > > Since we have many valueChangeListeners on some pages and perform 
> > > > some complex stuff in them, the business logic does not work any longer.
> > > >
> > > > Thanks fpr help,
> > > >
> > > > Daniel
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> > Your JSF powerhouse -
> > JSF Trainings in English and German
> >
> >
> --
> http://www.irian.at
> Your JSF powerhouse -
> JSF Trainings in English and German

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira