Mailing-List: contact users-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Discussion" <users@myfaces.apache.org>
Received-SPF: pass (herse.apache.org: domain of andrew.rw.robinson@gmail.com
 designates 209.85.132.245 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=ttKJbEb2pXQSFUYDz5KIQoSpU/cYVckizzyvLIpsyEm+PwtHKRDD/iZ2O8NG73SYzcLQk91xIWd4f4WvCb2OV3zkaslVStdzdjNyktb2rstM2Pj6QX5WlVniLK9SVO/QV2KVEnhWucqapz3lvdAOeKi8+CT6WaRLEUJW5gAwAYY=
Message-ID: <bc36a6210707071154j7ea3bm857852b7f4466df0@mail.gmail.com>
Date: Sat, 7 Jul 2007 12:54:41 -0600
From: "Andrew Robinson" <andrew.rw.robinson@gmail.com>
To: "MyFaces Discussion" <users@myfaces.apache.org>
Subject: Re: ValueChangeListener challenges
In-Reply-To: <d4c9ef920707070759n170a9a3he206f88cf6af136f@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <11471319.post@talk.nabble.com>
	 <d4c9ef920707061523x303fa648g5421ef0cf39b7496@mail.gmail.com>
	 <bc36a6210707061531q6dc069b2n80b94e5ce910c29a@mail.gmail.com>
	 <d4c9ef920707061552w751af0f9h19cc106b6f3cf1f8@mail.gmail.com>
	 <bc36a6210707061600q6165d28at945566aeefeb1a1e@mail.gmail.com>
	 <d4c9ef920707061612k1c0a5a8flff314481daacd851@mail.gmail.com>
	 <bc36a6210707061655s38f26afch586622c7235812fe@mail.gmail.com>
	 <d4c9ef920707061830q1e14d23cke043635d4190c072@mail.gmail.com>
	 <bc36a6210707070632p233dc615h19782978ad881d99@mail.gmail.com>
	 <d4c9ef920707070759n170a9a3he206f88cf6af136f@mail.gmail.com>

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