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