You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Kito Mann <ki...@virtua.com> on 2012/02/25 00:10:03 UTC
MockCompositeValueExpression
Does anyone know why the constructor to MockCompositeValueExpression in
MyFaces-Tests calls the superclass's constructor like so?
super("#{}", expectedType);
I'm thinking this is a bug, and that it should pass the actual expression:
super(expression, expectedType);
Let me know if I'm not missing something, and I'll create a JIRA issue.
___
Kito D. Mann | twitter: kito99 | Author, JSF in Action
Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter:
jsfcentral
+1 203-404-4848 x3
* Listen to the latest headlines in the JSF and Java EE newscast:
http://blogs.jsfcentral.com/roller/editorsdesk/category/JSF+and+Java+EE+Newscast
* Sign up for the JSFCentral newsletter: http://oi.vresp.com/?fid=ac048d0e17
Re: MockCompositeValueExpression
Posted by Matt Benson <gu...@gmail.com>.
On Fri, Feb 24, 2012 at 5:23 PM, Kito Mann <ki...@virtua.com> wrote:
> On Fri, Feb 24, 2012 at 6:21 PM, Matt Benson <gu...@gmail.com> wrote:
>>
>> On Fri, Feb 24, 2012 at 5:10 PM, Kito Mann <ki...@virtua.com> wrote:
>> > Does anyone know why the constructor to MockCompositeValueExpression in
>> > MyFaces-Tests calls the superclass's constructor like so?
>> >
>> > super("#{}", expectedType);
>> >
>> > I'm thinking this is a bug, and that it should pass the actual
>> > expression:
>> >
>> > super(expression, expectedType);
>> >
>> > Let me know if I'm not missing something, and I'll create a JIRA issue.
>>
>> Kito,
>> The super constructor will attempt to parse what it is given, but
>> since a composite expression may embed multiple #{...} constructs
>> among literal text sequences, this parsing would fail. It is for this
>> reason that the super constructor is passed a dummy expression.
>>
>
> This makes sense. However, isLiteral() is returning false in this case when
> it shouldn't, and I believe getExpressionString() is hardcoded to "#{}" as
> well.
>
Ah, then it sounds like the patch should compensate for these. :)
Matt
>>
>> Thanks,
>> Matt
>>
>> > ___
>> >
>> > Kito D. Mann | twitter: kito99 | Author, JSF in Action
>> > Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and
>> > consulting
>> > http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info |
>> > twitter:
>> > jsfcentral
>> > +1 203-404-4848 x3
>> >
>> > * Listen to the latest headlines in the JSF and Java EE
>> >
>> > newscast: http://blogs.jsfcentral.com/roller/editorsdesk/category/JSF+and+Java+EE+Newscast
>> > * Sign up for the JSFCentral newsletter:
>> > http://oi.vresp.com/?fid=ac048d0e17
>> >
>
>
Re: MockCompositeValueExpression
Posted by Kito Mann <ki...@virtua.com>.
On Fri, Feb 24, 2012 at 6:21 PM, Matt Benson <gu...@gmail.com> wrote:
> On Fri, Feb 24, 2012 at 5:10 PM, Kito Mann <ki...@virtua.com> wrote:
> > Does anyone know why the constructor to MockCompositeValueExpression in
> > MyFaces-Tests calls the superclass's constructor like so?
> >
> > super("#{}", expectedType);
> >
> > I'm thinking this is a bug, and that it should pass the actual
> expression:
> >
> > super(expression, expectedType);
> >
> > Let me know if I'm not missing something, and I'll create a JIRA issue.
>
> Kito,
> The super constructor will attempt to parse what it is given, but
> since a composite expression may embed multiple #{...} constructs
> among literal text sequences, this parsing would fail. It is for this
> reason that the super constructor is passed a dummy expression.
>
>
This makes sense. However, isLiteral() is returning false in this case when
it shouldn't, and I believe getExpressionString() is hardcoded to "#{}" as
well.
> Thanks,
> Matt
>
> > ___
> >
> > Kito D. Mann | twitter: kito99 | Author, JSF in Action
> > Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and
> consulting
> > http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info |
> twitter:
> > jsfcentral
> > +1 203-404-4848 x3
> >
> > * Listen to the latest headlines in the JSF and Java EE
> > newscast:
> http://blogs.jsfcentral.com/roller/editorsdesk/category/JSF+and+Java+EE+Newscast
> > * Sign up for the JSFCentral newsletter:
> http://oi.vresp.com/?fid=ac048d0e17
> >
>
Re: MockCompositeValueExpression
Posted by Matt Benson <gu...@gmail.com>.
On Fri, Feb 24, 2012 at 5:10 PM, Kito Mann <ki...@virtua.com> wrote:
> Does anyone know why the constructor to MockCompositeValueExpression in
> MyFaces-Tests calls the superclass's constructor like so?
>
> super("#{}", expectedType);
>
> I'm thinking this is a bug, and that it should pass the actual expression:
>
> super(expression, expectedType);
>
> Let me know if I'm not missing something, and I'll create a JIRA issue.
Kito,
The super constructor will attempt to parse what it is given, but
since a composite expression may embed multiple #{...} constructs
among literal text sequences, this parsing would fail. It is for this
reason that the super constructor is passed a dummy expression.
Thanks,
Matt
> ___
>
> Kito D. Mann | twitter: kito99 | Author, JSF in Action
> Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
> http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter:
> jsfcentral
> +1 203-404-4848 x3
>
> * Listen to the latest headlines in the JSF and Java EE
> newscast: http://blogs.jsfcentral.com/roller/editorsdesk/category/JSF+and+Java+EE+Newscast
> * Sign up for the JSFCentral newsletter: http://oi.vresp.com/?fid=ac048d0e17
>