[ http://issues.apache.org/jira/browse/MYFACES-625?page=comments#action_12365298 ]
Martin Marinschek commented on MYFACES-625: ------------------------------------------- I checked with the RI, but they are doing the same.... so you should initialize stuff with empty-strings if you got problems with this behaviour. regards, Martin > 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: Nightly > > 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, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > 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 <[EMAIL PROTECTED]> 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. > > > > > > > > > > > > [EMAIL PROTECTED] 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
