[jsr-314-open] BeanValidator cannot resolve composite component values
by Lincoln Baxter, III
I've logged an issue for this:
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1360
When baseClass is:
class com.sun.faces.el.CompositeComponentAttributesELResolver
$ExpressionEvalMap
BeanValidator.isResolvable(...) returns false because ExpressionEvalMap
is a Map -- and never attempts to traverse the composite component.
This is a big problem with Bean Validation support, since probably the
most attractive feature of JSF2 is composite components, and this means
BeanValidation will not function at all within any composite components.
// case 1, base classes of Map, List, or Array are not
resolvable
if (null != baseClass) {
if (Map.class.isAssignableFrom(baseClass) ||
Collection.class.isAssignableFrom(baseClass) ||
Array.class.isAssignableFrom(baseClass)) {
failureMessage = "Unable to validate expression " +
valueExpression.getExpressionString() +
" using Bean Validation. Expression
evaluates to a Map, List or array.";
result = false;
}
}
This can be reproduced by using the following component, and an Object
annotated with JSR303 annos.
Consuming page: (I've also tried "value" as the for="..." attribute
value with no success)
<h:form>
<a:comp id="test" value="${bean.test.text}">
<f:validateBean for="#{bean.test}"/>
</a:comp>
</h:form>
Example component:
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:a="http://java.sun.com/jsf/composite/ajax"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:composite="http://java.sun.com/jsf/composite">
<composite:interface>
<composite:attribute name="value" required="true"
type="Object" />
<composite:editableValueHolder name="value" targets="value" />
</composite:interface>
<composite:implementation>
<h:message id="inputErr" for="input"/><br/>
<h:inputText id="input" value="#{cc.attrs.value}" >
<f:ajax execute="@this" render="@this inputErr" />
</h:inputText>
</composite:implementation>
</html>
Example Object:
public class ValidationCriteria
{
@Size(min=4, max=255)
private String text;
public String getText()
{
return text;
}
public void setText(final String validation)
{
this.text = validation;
}
}
ExampleBean
@ManagedBean
public class Bean
{
private ValidationCriteria test = new ValidationCriteria();
public ValidationCriteria getTest()
{
return test;
}
}
--
Lincoln Baxter, III
Co-Founder of OcpSoft
Creator of:
PrettyFaces: URL rewriting for JSF
PrettyTime: Java elapsed timestamp formatting
15 years, 2 months
[jsr-314-open] [C036-ElInResources] CLOSED:
by Ed Burns
>>>>> On Sun, 04 Oct 2009 19:46:28 -0700, Alaxander Smirnov <asmirnov(a)exadel.com> said:
AS> I think processing of EL expressions should not be part of
AS> Resource#getInputStream, at least, not for generic resource.
AS> It would be better to move implementation into resource Renderer, and
AS> provide some meta-information which should be used for particular
AS> resource. That would clear divide responsibility between Resource object
AS> that should only load content from library, and Renderer that knows how
AS> to send that content to a client.
I understand the seductive pull of the "resource renderer" concept here
but I must point out that we tried to design the resource handler system
that way intially and threw it out in favor of our current, more flat,
approach. Rather than have per-content-type Renderers, we just went
with a system that made it easy to decorate the ResourceHandler and
override createResource() to take action based on the request content
type. Because my interest in this issue *right now* is to have
something put into the ChangeLog that applies to 2.0, I don't want to
entertain this concept any more on this thread.
LB> ACTION: Please vote +1 or -1 on OPTION ELEvaluatedInCSSOnly
>>>>> On Fri, 02 Oct 2009 20:44:56 +0000, lincolnbaxter(a)gmail.com said:
LB> +1
JD> +1
JL> +1
TG> +1
Since there appears to be support for this option, this is the one I
will codify in the "proposed change" section of the ChangeLog. Although
I like Imre's suggestion of using a CSS at-rule to tell the system to
scan for EL or not, I think it's overkill considering these files are
cached by the system anyway. Threfore, the text in
Resource.getInputStream() will include
The implementation must ensure that EL expressions that are included in
CSS resources are evaluated as the stream is being read. This enables
CSS resources to refer to other CSS resources in resource libraries, for
example: @import url(#resource['this:layout.css']}); Users must be aware
of the implications of caching when including EL expressions in this
way.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years, 2 months
Re: [jsr-314-open] #{cc} semantics
by Ryan Lubke
On 10/8/09 5:51 PM, Martin Marinschek wrote:
> I know I am way late with my post, but I (sure) also agree with Andy.
> Can we take this up as an issue against the implementation, and
> eventually a clarification to the spec?
>
> Ryan, what do you think?
>
We've made the necessary changes to Mojarra to support Andy's suggestion
and have
added a line item to the MR change log [1] (see C034).
[1] http://wiki.java.net/bin/view/Projects/Jsf2MR1ChangeLog
> Leonardo, can you do the same in MyFaces?
>
> regards,
>
> Martin
>
> On Thu, Sep 17, 2009 at 6:12 PM, Kito Mann<kito.mann(a)virtua.com> wrote:
>
>> +1
>> ---
>> Kito D. Mann -- Author, JavaServer Faces in Action
>> http://twitter.com/kito99 http://twitter.com/jsfcentral
>> JSF 2 Seminar Oct 6th: http://www.regonline.com/jsf2seminar
>> JSF Summit Conference Dec 1st-4th in Orlando: http://www.jsfsummit.com
>> http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
>> +1 203-404-4848 x3
>>
>>
>> On Tue, Sep 15, 2009 at 6:34 PM, Andy Schwartz<andy.schwartz(a)oracle.com>
>> wrote:
>>
>>> Ryan, All -
>>>
>>> Breaking this topic off into a separate thread, though I am impressed with
>>> the length of the "<h:dataTable> binding vs. ui:repeat" thread. :-)
>>>
>>> Ryan Lubke wrote:
>>>
>>>> On 9/7/09 6:06 PM, Andy Schwartz wrote:
>>>>
>>>>> Thanks Lincoln. I haven't had time to debug this, but I have a theory
>>>>> about what might be happening. In your sample:
>>>>>
>>>>>
>>>>>> <a:editText value="#{cc.attrs.task.text}"
>>>>>> rendered="#{!cc.attrs.disabled}">
>>>>>> *<f:actionListener for="submit"
>>>>>> action="#{taskController.saveTaskAjax(cc.attrs.story, cc.attrs.task)}" /> *
>>>>>> </a:editText>
>>>>>>
>>>>> We expect "cc" to resolve to the containing composite component (ie. to
>>>>> the<socialpm:taskBlock> component). I wouldn't be surprised if what is
>>>>> actually happening is that "cc" is being resolved to the<a:editText>
>>>>> composite component instead.
>>>>>
>>>> Yep, that's what is happening.
>>>>
>>>>> One reason why I suspect this might be happening is that I know that
>>>>> Ryan has investigated/resolved similar problems not too long ago.
>>>>>
>>>> The problem we resolved was the passing of #{cc.attrs} attributes between
>>>> nested composite components.
>>>> For this case, the spec recommends using cc.parent.attrs.story and
>>>> cc.parent.attrs.task, where parent resolves
>>>> to the nearest composite component parent of the current composite
>>>> component.
>>>>
>>> I am concerned about this behavior. It isn't clear to me whether the spec
>>> is explicit about this behavior, or whether this is something that happens
>>> to fall out of the implementation. Either way, the current behavior seems
>>> counterintuitive to me, and, well... wrong.
>>>
>>> My feeling is that when a composite component author uses a #{cc}
>>> expression in a composite component implementation, eg:
>>>
>>> <composite:implementation>
>>> <h:outputText value="#{cc.attrs.value}">
>>> </composite:implementation>
>>>
>>> The correct behavior (the behavior expected by the composite component
>>> author) is to resolve the #{cc} expression relative to where the expression
>>> is defined - not relative to where it happens to end up in the component
>>> tree. So, for example, I believe that these three uses of the
>>> #{cc.attrs.value} expression should all evaluate to the same value:
>>>
>>> <composite:implementation>
>>>
>>> <!-- 1. Expression directly in the implementation -->
>>> <h:outputText value="#{cc.attrs.value}">
>>>
>>> <!-- 2. Expression in non-composite component facet -->
>>> <bar:someJavaComposite>
>>> <f:facet name="someFacet">
>>> <h:outputText value="#{cc.attrs.value}">
>>> </f:facet>
>>> </bar:someJavaComponent>
>>>
>>> <!-- 3. Expression in composite component facet -->
>>> <foo:someCompositeComponent>
>>> <f:facet name="someFacet">
>>> <h:outputText value="#{cc.attrs.value}">
>>> </f:facet>
>>> </foo:someCompositeComponent>
>>>
>>> </composite:implementation>
>>>
>>> The fact that the #{cc.attrs.value} expression evaluates the same in cases
>>> #1 and #2 but not in case #3 is non-obvious and is going to be confusing for
>>> our users. The fact that Lincoln and I were confused about this is a good
>>> indication that others will be as well.
>>>
>>> I am not happy with the work around of using #cc.parent.attrs, since this
>>> means that:
>>>
>>> 1. The user must recognize that the component in question is a composite
>>> component and code the expression differently. While at the moment it is
>>> fairly easy to determine whether a particular component is a composite or
>>> not (by looking at the namespace declaration), I think that we should strive
>>> to blur these lines rather than reinforce them. For example, I would like
>>> to see the ability to define a single tag library that consists of both
>>> composite and non-composite components, making the choice of component
>>> implementation more transparent to the user.
>>>
>>> 2. Once the user has coded the expression in a composite
>>> component-specific way, this introduces a dependency on the fact that the
>>> component in question is a composite component - a dependency that shouldn't
>>> be necessary for this particular case. Such dependencies inhibit
>>> flexibility. If in the future the provider of the composite component
>>> decides to switch to a Java-based component, this will break any code (or EL
>>> expression) that assumes that the component is a composite. We should keep
>>> such dependencies to a minimum.
>>>
>>> 3. This also introduces a subtle dependency on the composite component's
>>> implementation. What if the composite component implementation passes the
>>> expression along to yet another nested composite component? Does the user
>>> now need to specify an expression that pops out multiple levels of parents?
>>>
>>> While it is certainly trickier to deal with from an implementation
>>> perspective, I believe that it is very important that we re-consider the
>>> current behavior and consider spec'ing that #{cc} expressions always resolve
>>> relative to the context in which they are defined. I feel that the current
>>> behavior violates the principle of least surprise (both Lincoln and I were
>>> surprised) and also breaks encapsulation (ie. introduces
>>> implementation-specific dependencies).
>>>
>>> Leaving aside questions of how we might implement my preferred behavior
>>> for the moment... Does anyone have comments on which behavior makes sense
>>> from a spec/end user perspective?
>>>
>>> Andy
>>>
>>>
>>
>>
>
>
>
15 years, 2 months
Re: [jsr-314-open] <h:dataTable> binding vs. ui:repeat
by Ed Burns
>>>>> On Tue, 18 Aug 2009 08:08:31 +0200, Martin Marinschek <mmarinschek(a)apache.org> said:
MM> Hi Ed,
>> Which I still don't understand. Can you please explain explicitly?
MM> I sent a mail to Kin-Man that we can't pass parameters from the
MM> framework to the method-expression. So, we can now do:
MM> #{bb.action(myparam)}
MM> to call a method with signature:
MM> public String action(String myparam) {}
MM> but we can not do:
MM> #{bb.valueChangeListener(myparam)}
MM> to call a method with signature:
MM> public void valueChangeListener(ValueChangeEvent ev, String myparam) {}
MM> only with signature:
MM> public void valueChangeListener(String myparam) {}
MM> so what we loose is the ValueChangeEvent, which was provided by the
MM> JSF framework as a parameter to the invoke-call in the
MM> Method-Expression instance (we will only receive the parsed
MM> parameters).
Thanks. Now I understand your request.
MM> I already got mail by Kin-Man - he said this won't be included, we
MM> are too late.
MM> This effectively means we cannot use the new EL functionality to solve
MM> the problem that was discussed in this thread (using
MM> valueChangeListeners in a dataTable), and therefore, even though we
MM> can get rid of the f:setPropertyActionListener, we would still need an
MM> f:setPropertyValueChangeListener - a pity.
I agree that the feature you request is indeed valid. Can you please
file it in the uel.dev.java.net issue tracker?
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years, 2 months
Re: [jsr-314-open] #{cc} semantics
by Martin Marinschek
oh, well, apache.org the mail address has to be.
regards,
Martin
On Fri, Oct 9, 2009 at 2:51 AM, Martin Marinschek
<martin.marinschek(a)gmail.com> wrote:
> I know I am way late with my post, but I (sure) also agree with Andy.
> Can we take this up as an issue against the implementation, and
> eventually a clarification to the spec?
>
> Ryan, what do you think?
>
> Leonardo, can you do the same in MyFaces?
>
> regards,
>
> Martin
>
> On Thu, Sep 17, 2009 at 6:12 PM, Kito Mann <kito.mann(a)virtua.com> wrote:
>> +1
>> ---
>> Kito D. Mann -- Author, JavaServer Faces in Action
>> http://twitter.com/kito99 http://twitter.com/jsfcentral
>> JSF 2 Seminar Oct 6th: http://www.regonline.com/jsf2seminar
>> JSF Summit Conference Dec 1st-4th in Orlando: http://www.jsfsummit.com
>> http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
>> +1 203-404-4848 x3
>>
>>
>> On Tue, Sep 15, 2009 at 6:34 PM, Andy Schwartz <andy.schwartz(a)oracle.com>
>> wrote:
>>>
>>> Ryan, All -
>>>
>>> Breaking this topic off into a separate thread, though I am impressed with
>>> the length of the "<h:dataTable> binding vs. ui:repeat" thread. :-)
>>>
>>> Ryan Lubke wrote:
>>>>
>>>> On 9/7/09 6:06 PM, Andy Schwartz wrote:
>>>>>
>>>>> Thanks Lincoln. I haven't had time to debug this, but I have a theory
>>>>> about what might be happening. In your sample:
>>>>>
>>>>>> <a:editText value="#{cc.attrs.task.text}"
>>>>>> rendered="#{!cc.attrs.disabled}">
>>>>>> *<f:actionListener for="submit"
>>>>>> action="#{taskController.saveTaskAjax(cc.attrs.story, cc.attrs.task)}" /> *
>>>>>> </a:editText>
>>>>>
>>>>> We expect "cc" to resolve to the containing composite component (ie. to
>>>>> the <socialpm:taskBlock> component). I wouldn't be surprised if what is
>>>>> actually happening is that "cc" is being resolved to the <a:editText>
>>>>> composite component instead.
>>>>
>>>> Yep, that's what is happening.
>>>>>
>>>>> One reason why I suspect this might be happening is that I know that
>>>>> Ryan has investigated/resolved similar problems not too long ago.
>>>>
>>>> The problem we resolved was the passing of #{cc.attrs} attributes between
>>>> nested composite components.
>>>> For this case, the spec recommends using cc.parent.attrs.story and
>>>> cc.parent.attrs.task, where parent resolves
>>>> to the nearest composite component parent of the current composite
>>>> component.
>>>
>>> I am concerned about this behavior. It isn't clear to me whether the spec
>>> is explicit about this behavior, or whether this is something that happens
>>> to fall out of the implementation. Either way, the current behavior seems
>>> counterintuitive to me, and, well... wrong.
>>>
>>> My feeling is that when a composite component author uses a #{cc}
>>> expression in a composite component implementation, eg:
>>>
>>> <composite:implementation>
>>> <h:outputText value="#{cc.attrs.value}">
>>> </composite:implementation>
>>>
>>> The correct behavior (the behavior expected by the composite component
>>> author) is to resolve the #{cc} expression relative to where the expression
>>> is defined - not relative to where it happens to end up in the component
>>> tree. So, for example, I believe that these three uses of the
>>> #{cc.attrs.value} expression should all evaluate to the same value:
>>>
>>> <composite:implementation>
>>>
>>> <!-- 1. Expression directly in the implementation -->
>>> <h:outputText value="#{cc.attrs.value}">
>>>
>>> <!-- 2. Expression in non-composite component facet -->
>>> <bar:someJavaComposite>
>>> <f:facet name="someFacet">
>>> <h:outputText value="#{cc.attrs.value}">
>>> </f:facet>
>>> </bar:someJavaComponent>
>>>
>>> <!-- 3. Expression in composite component facet -->
>>> <foo:someCompositeComponent>
>>> <f:facet name="someFacet">
>>> <h:outputText value="#{cc.attrs.value}">
>>> </f:facet>
>>> </foo:someCompositeComponent>
>>>
>>> </composite:implementation>
>>>
>>> The fact that the #{cc.attrs.value} expression evaluates the same in cases
>>> #1 and #2 but not in case #3 is non-obvious and is going to be confusing for
>>> our users. The fact that Lincoln and I were confused about this is a good
>>> indication that others will be as well.
>>>
>>> I am not happy with the work around of using #cc.parent.attrs, since this
>>> means that:
>>>
>>> 1. The user must recognize that the component in question is a composite
>>> component and code the expression differently. While at the moment it is
>>> fairly easy to determine whether a particular component is a composite or
>>> not (by looking at the namespace declaration), I think that we should strive
>>> to blur these lines rather than reinforce them. For example, I would like
>>> to see the ability to define a single tag library that consists of both
>>> composite and non-composite components, making the choice of component
>>> implementation more transparent to the user.
>>>
>>> 2. Once the user has coded the expression in a composite
>>> component-specific way, this introduces a dependency on the fact that the
>>> component in question is a composite component - a dependency that shouldn't
>>> be necessary for this particular case. Such dependencies inhibit
>>> flexibility. If in the future the provider of the composite component
>>> decides to switch to a Java-based component, this will break any code (or EL
>>> expression) that assumes that the component is a composite. We should keep
>>> such dependencies to a minimum.
>>>
>>> 3. This also introduces a subtle dependency on the composite component's
>>> implementation. What if the composite component implementation passes the
>>> expression along to yet another nested composite component? Does the user
>>> now need to specify an expression that pops out multiple levels of parents?
>>>
>>> While it is certainly trickier to deal with from an implementation
>>> perspective, I believe that it is very important that we re-consider the
>>> current behavior and consider spec'ing that #{cc} expressions always resolve
>>> relative to the context in which they are defined. I feel that the current
>>> behavior violates the principle of least surprise (both Lincoln and I were
>>> surprised) and also breaks encapsulation (ie. introduces
>>> implementation-specific dependencies).
>>>
>>> Leaving aside questions of how we might implement my preferred behavior
>>> for the moment... Does anyone have comments on which behavior makes sense
>>> from a spec/end user perspective?
>>>
>>> Andy
>>>
>>
>>
>
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
15 years, 2 months
[jsr-314-open] DRY and form with JSF 2
by Damien Gouyette
Hello,
I have a lot of forms to do and i don't understand a point
<h:outputLabel value="client's birthdate" for="birthDateField"/>
<h:inputText id="birthDateField" label="client's birthdate"/>
<h:message for="birthDateField"/>
if i don't set label on inputText, i have an error message like :
formNew:birthDate: 'a' could not be understood as a date. Example:
12/09/2009 instead of
client's birthdate : 'a' could not be understood as a date. Example:
12/09/2009
Can you reuse outputLabel value if exists ?
Just for information, this message is the french error message when i
set a dateConverter on my inputText. (little bug)
Damien GOUYETTE
15 years, 2 months
Re: [jsr-314-open] revisiting the JSR-314 openness policy
by Ed Burns
>>>>> On Fri, 18 Sep 2009 12:00:28 +0100, Pete Muir <pmuir(a)redhat.com> said:
PM> On 18 Sep 2009, at 00:09, Dan Allen wrote:
>> Our first choice for request #1 is to allow all subscribed members
>> of the jsr-314-open list to post, with moderation of a person's
>> inaugural post (webbeans-dev uses this approach, for instance). The
>> second choice would be to have a separate list open to the
>> community. In either case, both lists should satisfy request #2.
PM> My preference would be for there to be two email lists, both with
PM> public, non-password-protected, archives. The first is the EG list.
PM> The second is the a discussion list. A regular member of the EG can
PM> post unmoderated to either list. Any subscriber can post to the
PM> discussion list. If a member of the community is an expert on a
PM> particular sub-topic, we should pull them into the EG list, using
PM> moderation to allow their posts through.
I like Pete's suggestion. Dan, is the lack of email gateway the only
roadblock to using the existing facility on the new jcp.org site?
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years, 2 months
[jsr-314-open] [C036-ElInResources] Vote favors DefaultToOptOut
by Ed Burns
First, let me say I think we need to quickly make a statement in the
ChangeLog about this because not having this feature, at least in CSS
resources, is a big shortcoming for Resource loading. Note that Mojarra
currently does have this in *all* resources and I requested Ryan to make
it for just CSS CSS resources to provide a solution for Ted Goddard's
immediate problem regarding the prototype JavaScript library.
EB> OPTION DefaultToOptOut
EB> With this option, we modify Resource.getInputstream() to state that EL
EB> evaluation in Resource files is disabled by default. For simplicity, I
EB> suggest the user convey their intention at a per-application granularity
EB> using a context-param.
This was the most popular option, but no-one was in favor of the context
param; everyone that voted wanted a finer grain solution.
AS> As Jim's email described, the caching behavior is intimately related to
AS> the question of how to handle EL evaluation in resources. I don't think
AS> that these two discussions really are separate matters.
Yes, I see your point that they are related. However, we chose to say
nothing about cache headers and resources in 2.0. Therefore, I think
what we say about cache headers and resources should wait for the next
JCP release of JSF.
On the other hand, as I said above, I think the absence of a way for
resources to refer to other resources is a missing feature. I intended
to specify it in Resource.getInputStream(), but I failed to do so
through an error on my part. Therefore, I'm going to place another
option on the table for inclusion in the ChangeLog.
OPTION ELEvaluatedInCSSOnly
With this option, we modify Resource.getInputStream() to state that EL
evaluation in CSS files is enabled by default. We will state that care
must be taken by the user to ensure that the EL expression always
evaluates to the same thing across multiple requests. We will state
that the user may decorate the ResourceHandler to get more flexibility.
ACTION: Please vote +1 or -1 on OPTION ELEvaluatedInCSSOnly
Thanks,
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years, 2 months
[jsr-314-open] [C036-ElInResources] Vote favors DefaultToOptOut
by Ed Burns
From: Imre Osswald <io(a)mx.jevelopers.com>
I don't think the evaluation should be restricted to resources only.
Even if it might be confusing that the expressions will/might only be
evaluated once (especially in production mode), there is great value
in being able to use "CSS-Vars" to customize the CSS, for example per
deployment.
But if every EL is evaluated, then we might need a way to switch
evaluation off. One example would be: .sillyExample:before { content:
"#{might.even.be.used.by.prototype}" };
As I don't see a big performance problem with parsing the css-
resouces, because of the caching by the browser and by jsf, I would
like to suggest to have the "switch" to turn evaluation on/off inside
of the files themselves. Possible solutions could be @-rules like:
@ELEvaluation "on" / "off"; or probably better "annotation-comments" /
* @ELEvalution on */
These could even be used in JS-files, where referencing relative
resources is not uncommon, and will therefore need resource-evaluation
too.
As for the defaults: I think ELEvaluationInCSSOnly (= "on") is a
sensible default, with context options to switch it globally on/off.
Especially until some sort of switch finds its way into the
specification.
Imre
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
15 years, 3 months
