[jsr-314-open] Fwd: So what's left for 2.0?
by Pete Muir
Begin forwarded message:
> From: Dan Allen <dan.j.allen(a)gmail.com>
> Date: 11 March 2009 15:19:09 GMT
> To: Pete Muir <pmuir(a)bleepbleep.org.uk>
> Subject: Re: So what's left for 2.0?
>
> On Wed, Mar 11, 2009 at 10:20 AM, Andy Schwartz <andy.schwartz(a)oracle.com
> > wrote:
> Gang -
>
> Seems like we've still got a few loose ends that we either need to
> finish up for 2.0, or, if not, agree to punt on until 2.1. Based on
> recent email threads, these include:
>
> 1. State saving
>
> Martin had raised concerns about compatibility between the new tree
> visitor-based state saving implementation and the jstl tags. It
> sounded like Martin had a patch - but not sure whether the patch
> addresses these problems fully. Also not sure whether we are
> providing delta state saving. Can anyone clarify what the plan is
> for 2.0?
>
> 2. f:ajax/f:validateBean wrapping behavior
>
> For consistency I think we want to move f:validateBean over to a
> wrapping strategy that is closer to f:ajax, but want to hear Dan's
> take on this. (Dan - I can help walk you through the f:ajax
> implementation if you have questions about this.)
>
> I'm fine with this. It will take out some ambiguity and it aligns
> with <s:validateAll> which we have used in Seam. We should still
> support the validator nested within EditableValueHolder of course as
> an override, which is consistent with <f:ajax> too. I think the next
> step is to define in text the override strategy. I can do this if
> you want me to move forward with it. (The disable attribute on
> validator should be renamed to disabled or vice-versa for <f:ajax>;
> I like the verb better)
>
> If we go with the nesting strategy, I want to move forward with my
> idea of making the branch validator a prototype that is cloned on to
> each child EditableValueHolder. That way we can support validators
> that are StateHolders (i.e., have properties like regex).
>
> -Dan
>
> --
> Dan Allen
> Senior Software Engineer, Red Hat | Author of Seam in Action
--
Pete Muir
http://www.seamframework.org
http://in.relation.to/Bloggers/Pete
16 years, 8 months
[jsr-314-open] Fwd: [NEW] <f:ajax> and <f:validateBean> - consistent wrapping solution needed?
by Pete Muir
Begin forwarded message:
> From: Dan Allen <dan.j.allen(a)gmail.com>
> Date: 11 March 2009 14:41:25 GMT
> To: Pete Muir <pmuir(a)bleepbleep.org.uk>
> Subject: Re: [NEW] <f:ajax> and <f:validateBean> - consistent
> wrapping solution needed?
>
>
>
> How does <f:validateBean> deal with this case? For example:
>
> <f:validateBean>
> <h:inputText>
> <f:validateLength/>
> </h:inputText>
> </f:validateBean>
>
> Is a bean validator added to the inputText in addition to the length
> validator?
>
> Yes. But we also support <f:validateBean disabled="true"/>
> (Actually, the attribute name is disable so we should align this).
>
> -Dan
>
> --
> Dan Allen
> Senior Software Engineer, Red Hat | Author of Seam in Action
--
Pete Muir
http://www.seamframework.org
http://in.relation.to/Bloggers/Pete
16 years, 8 months
Re: [jsr-314-open] [426-BeanValidation] Default Enablement Change
by Martin Marinschek
Hi Ed,
if you ask for introduction of change 1, you should also ask for 2 - 1
without 2 doesn't make
much sense, right?
FWIW, for me Emmanuel's statement makes much sense - convention over
configuration, and a way to overrule convention by configuration is
all we should need!
regards,
Martin
On 3/10/09, Ed Burns <Ed.Burns(a)sun.com> wrote:
>>>>>> On Fri, 06 Mar 2009 12:41:16 -0800, Ed Burns <Ed.Burns(a)Sun.COM> said:
>
> EB> Change 1 Default default validator
> EB> Change 2 Default value for VALIDATE_EMPTY_FIELDS
> EB> Change 3 isDefault on @FacesValidator
>
> I have taken Change 1 to the EE architecture team to ask for guidance,
> since, as Emmanuel points out, our decision on this point is an
> opportunity to influence the programming model used for EE6.
>
> I'll let you know how it goes today.
>
> Ed
>
> --
> | ed.burns(a)sun.com | office: 408 884 9519 OR x31640
> | homepage: | http://ridingthecrest.com/
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
16 years, 8 months
Re: [jsr-314-open] [NEW] <f:ajax> and <f:validateBean> - consistent wrapping solution needed?
by Andy Schwartz
Hi Sergey -
Sergey Smirnov wrote On 3/10/2009 2:12 PM ET:
>
> <h:panelGrid>
> <!-- Turn on Ajax for the two input texts -->
> <f:ajax event="valueChange">
> <h:inputText value="foo"/>
> <h:inputText value="bar"/>
> </f:ajax>
> </h:panelGrid>
>
> How many columns will be rendered : two or one?
Two. <f:ajax> is not a component, so does not influence the component
tree hierarchy. The above is just a convenience for:
> <h:panelGrid>
>
> <h:inputText value="foo">
> <f:ajax event="valueChange">
> </h:inputText>
>
> <h:inputText value="bar">
> <f:ajax event="valueChange">
> </h:inputText>
>
> </h:panelGrid>
Andy
16 years, 8 months
[jsr-314-open] [NEW] <f:ajax> and <f:validateBean> - consistent wrapping solution needed?
by Andy Schwartz
Gang -
In JSF 2.0 we are introducing two core tags that wrap/enhance component
subtrees: f:ajax and f:validateBean.
f:ajax is used to enable Ajax behavior for a subtree, eg:
> <h:panelGroup>
> <!-- Turn on Ajax for the two input texts -->
> <f:ajax event="valueChange">
> <h:inputText value="foo"/>
> <h:inputText value="bar"/>
> </f:ajax>
> </h:panelGroup>
f:validateBean is used to enable bean validation for a subtree, eg:
> <h:panelGroup>
> <!-- Turn on bean validation for the two input texts -->
> <f:validateBean validationGroups="Group1, Group2"/>
> <h:inputText value="foo"/>
> <h:inputText value="bar"/>
> </f:validateBean>
> </h:panelGroup>
Of course, both tags can also be used in their nested form to enable
Ajax/bean validation on a single component.
We currently use different implementation strategies for the "wrapping"
behavior.
f:ajax uses a handler execution-time solution. AjaxHandler maintains a
stack that keeps track of the current nested state of <f:ajax> tags.
Before apply child handlers, AjaxHandler pushes the current Ajax-related
info onto this stack. When child/descendent handlers are applied,
ComponentTagHandlerDelegateImpl checks this stack to get at the current
Ajax-related state and performs the necessary work to wire up an
AjaxBehavior to the component. Finally, after child handlers have been
processed, AjaxHandler pops the stack, and we're done.
The end result of the f:ajax solution is that once handlers have
finished executing, we have a fully configured component tree. No
further processing is necessary to apply "inherited" Ajax behavior.
f:validateBean uses a solution which is split between tag/handler
execution-time, validation-time and render-time.
BeanValidatorHandler/ValidatorTagHandlerDelegateImpl set up well known
properties on the parent component's attribute map (eg.
BeanValidator.VALIDATION_GROUPS_KEY,
UIInput.DEFAULT_VALIDATOR_IDS_KEY). These are used during later
lifecycle phases (eg. BeanValidator.validate(), UIInput.encodeEnd()) to
determine which inherited validators to apply and how these validators
should be configured (eg. what validation groups to use).
The end result of the f:validateBean solution is that the handlers only
do part of the job - we need to do additional work during later
lifecycle phases to take advantage of the information that has been
stored away by the handlers.
While these two different strategies may at first seem like
implementation details, and thus not especially significant, the choice
of implementation does have impact on both our API and on spec'ed
behavior (or, on behavior that should be defined by the spec).
In terms of API, for f:validateBean the choice of implementation leaks
through a bit into the API in the form of the property keys that are
used to communicate between the handler implementations and the
component/validator implementations.
In terms of behavior, the different implementation strategies and up
with subtly different results which may cause confusion.
For example, in the following f:ajax case:
> <h:panelGroup>
>
> <!-- Turn Ajax on for this one -->
> <f:ajax event="valueChange">
> <h:inputText value="foo"/>
> </f:ajax>
>
> <!-- But not for this one -->
> <h:inputText value="bar"/>
>
> </h:panelGroup>
This should work as expected. That is, Ajax should be enabled for the
"foo" inputText, but not for the "bar" input text.
In a similar f:validateBean case:
> <h:panelGroup>
>
> <!-- Turn bean validation on for this one -->
> <f:validateBean validationGroups="Group1, Group2"/>
> <h:inputText value="foor"/>
> </f:validateBean>
>
> <!-- But not for this one -->
> <h:inputText value="bar"/>
>
> </h:panelGroup>
Unless I am missing something in the spec/implementation, I believe that
the validation-related properties are going to end up being attached to
the parent panelGroup when the BeanValidatorHandler is applied. Which,
if I understand this correctly, means that the validation will be
applied to both the "foo" and the "bar" inputText. If this is the case,
this is definitely not the desired behavior.
I suspect that similar problems would arise when we've got multiple
<f:validateBean> under a single parent, eg:
> <h:panelGroup>
>
> <!-- Turn on Group1 validation for this one -->
> <f:validateBean validationGroups="Group1"/>
> <h:inputText value="foo"/>
> </f:validateBean>
>
> <!-- Turn on Group2 validation for this one -->
> <f:validateBean validationGroups="Group2"/>
> <h:inputText value="bar"/>
> <f:validateBean/>
>
> </h:panelGroup>
Though I haven't had a chance to test this out - just based on code
inspection seems like this would be a problem. (Though our <f:ajax>
implementation strategy handles this case just fine.)
Since there may be other subtle inconsistencies, it would make sense to
try to unify our implementation strategies across these two core tags.
Of course, I am biased towards the <f:ajax> approach. Seems to have
better behavior in terms of targeting only the wrapped subtrees, has
less exposure in the public API, and also just seems cleaner to me to
produce a fully configured component tree as a result of handler execution.
Looking at the code, I didn't notice anything that would make it
difficult to re-factor the <f:validateBean> code to use a handler-time
strategy like <f:ajax>. I think our users would benefit from the
consistency. Any thoughts on whether we should/can go this route? Did
I miss anything in the <f:validteBean> behavior that would prevent us
from using a handler-time solution?
Andy
16 years, 8 months
Re: [jsr-314-open] Why do we disallow EL for h:dataTable "var" attribute?
by Kito Mann
Same here.
Sent from my iPhone
http://www.jsfcentral.com
http://www.Virtua.com
On Mar 7, 2009, at 9:53 PM, Gavin King <gavin(a)HIBERNATE.ORG> wrote:
> Right. I don't understand what this could possibly be useful for.
>
> On Fri, Mar 6, 2009 at 11:21 AM, Simon Lessard
> <Simon_Lessard(a)dmr.ca> wrote:
>> Hi all,
>>
>> Although I guess it would be technically possible (yet weird and
>> most likely very complicated) to support EL for the var attribute,
>> it wouldn't make much sense as 'var' is used as a variable name for
>> iteration purpose. In much senses, it's like a really short lived
>> managed bean and we don't support dynamic managed bean names
>> either. I wonder how the EL would have to look like to support such
>> feature (scope[myBean.varName].attribute?) and what kinf od use
>> case it would solve.
>>
>>
>> Regards,
>>
>> ~ Simon
>>
>> ________________________________
>>
>> From: JSR 314 Open Mailing list on behalf of Ed Burns
>> Sent: Fri 3/6/2009 10:55 AM
>> To: JSR-314-OPEN(a)JCP.ORG
>> Subject: Why do we disallow EL for h:dataTable "var" attribute?
>>
>>
>>
>> Someone on JSR-314-COMMENTS asked this question and I don't recall
>> the
>> answer, but I trust there's a good one since it's baked into the
>> spec.
>>
>> Any ideas?
>>
>> Ed
>> --
>> | ed.burns(a)sun.com | office: 408 884 9519 OR x31640
>> | homepage: | http://ridingthecrest.com/
>>
>
>
>
> --
> Gavin King
> gavin.king(a)gmail.com
> http://in.relation.to/Bloggers/Gavin
> http://hibernate.org
> http://seamframework.org
16 years, 8 months
Re: [jsr-314-open] [426-BeanValidation] Default Enablement Change
by Pete Muir
Hi Ed,
I don't object per-se to this change, but it doesn't seem necessary to
me.
1) We don't control which validators are the default from faces-
config.xml (which @FacesValidator mirrors) but from Application, so
it's not like we are missing an XML counterpart in annotations
2) The use case I see for default validators is not one where which
validators are defaulted by the validator, but by the application
(e.g. application1 uses bean validation and so wants that as the
default, application2 doesn't, but does uses MyCustomDomainValidator)
On 6 Mar 2009, at 20:49, Ed Burns wrote:
> One more.
>
> Change 3
>
> We have a @FacesValidator annotation. We need to add an attribute
> to it
> that declares that the validator should be added as a default
> validator. I'll do that as well.
>
>
>
>
> --
> | ed.burns(a)sun.com | office: 408 884 9519 OR x31640
> | homepage: | http://ridingthecrest.com/
--
Pete Muir
http://www.seamframework.org
http://in.relation.to/Bloggers/Pete
16 years, 8 months
[jsr-314-open] Fwd: [426-BeanValidation] Default Enablement Change
by Pete Muir
Begin forwarded message:
> From: Emmanuel Bernard <emmanuel.bernard(a)jboss.com>
> Date: 6 March 2009 21:03:51 GMT
> To: Ed Burns <Ed.Burns(a)Sun.COM>
> Cc: Pete Muir <pmuir(a)redhat.com>, Dan Allen <dan.j.allen(a)gmail.com>
> Subject: Re: [426-BeanValidation] Default Enablement Change
>
> Hi Ed,
> What are you reasons for not allowing this "auto" mode by default
> (both for the default validator and the validate empty fields?
>
> We initially had something like you proposed but we decided to align
> with JPA to get a better cleaner alignment of the Java programmatic
> model at large (SE and EE). I can understand your uneasiness (I was
> a bit initially too) but I think it's for the greater of JSF and the
> platform, esp wrt ease of use.
> We are at an interesting tipping point. BV is not in applications
> yet so we can define the best defaults for the present and the
> future. It will be too late to move forward after that. Remember, if
> BV is not in the classpath, nothing changes. If someone wants to
> force the old legacy approach, it's two properties away.
>
> Emmanuel
>
> On Mar 6, 2009, at 15:47, Dan Allen wrote:
>>
>>
>> ---------- Forwarded message ----------
>> From: Ed Burns <Ed.Burns(a)sun.com>
>> Date: Fri, Mar 6, 2009 at 3:41 PM
>> Subject: [426-BeanValidation] Default Enablement Change
>> To: JSR-314-OPEN(a)jcp.org
>>
>>
>> Change 1
>>
>>
>> When sitting down to move the content out of Appendix C and into the
>> spec proper, I came across this statement, currently in setion
>> 2.3.2 of
>> Appendix C.
>>
>> If Beans Validation is present in the environment (i.e., the
>> javax.validation.Validation class is available on the classpath),
>> the
>> validator with javax.faces.Bean is considered the default
>> validator if
>> no default validators are defined.
>>
>> I would like to remove this statement and replace it with.
>>
>> If running in a container that supports Beans Validation, adding the
>> validator with id "javax.faces.Bean" to the default-validator
>> section
>> enables Beans Validation integration.
>>
>> Change 2
>>
>> In section 11.1.3, where we declare the context-params and how to
>> handle
>> them, this text appears:
>>
>> * javax.faces.VALIDATE_EMPTY_FIELDS -- If this param is set, and
>> calling
>> toLowerCase().equals("true") on a String representation of its value
>> returns true, all submitted fields will be validated. This is
>> necessary to allow the model validator to decide whether null or
>> empty
>> values are allowable in the current application. If the value is
>> "false", null or empty values will not be passed to the
>> validators. If
>> the value is the string "auto", the runtime must check if JSR-303
>> Beans Validation is present in the current environment. If so, the
>> runtime must proceed as if the value "true" had been specified. If
>> JSR-303 Beans Validation is not present in the current environment,
>> the runtime most proceed as if the value "false" had been specified.
>>
>> I would like to add the following after the last sentance above.
>> If the
>> param is not set, the system must behave as if the param was set with
>> the value "false"
>>
>> ACTION: please reply my 0900 EST Monday 20090309.
>>
>> Thanks,
>>
>> Ed
>>
>> --
>> | ed.burns(a)sun.com | office: 408 884 9519 OR x31640
>> | homepage: | http://ridingthecrest.com/
>>
>>
>>
>> --
>> Dan Allen
>> Senior Software Engineer, Red Hat | Author of Seam in Action
>>
>> http://mojavelinux.com
>> http://mojavelinux.com/seaminaction
>>
>> NOTE: While I make a strong effort to keep up with my email on a
>> daily
>> basis, personal or other work matters can sometimes keep me away
>> from my email. If you contact me, but don't hear back for more than
>> a week,
>> it is very likely that I am excessively backlogged or the message was
>> caught in the spam filters. Please don't hesitate to resend a
>> message if
>> you feel that it did not reach my attention.
>
--
Pete Muir
http://www.seamframework.org
http://in.relation.to/Bloggers/Pete
16 years, 8 months
Re: [jsr-314-open] Why do we disallow EL for h:dataTable "var" attribute?
by Simon Lessard
Hi all,
Although I guess it would be technically possible (yet weird and most likely very complicated) to support EL for the var attribute, it wouldn't make much sense as 'var' is used as a variable name for iteration purpose. In much senses, it's like a really short lived managed bean and we don't support dynamic managed bean names either. I wonder how the EL would have to look like to support such feature (scope[myBean.varName].attribute?) and what kinf od use case it would solve.
Regards,
~ Simon
________________________________
From: JSR 314 Open Mailing list on behalf of Ed Burns
Sent: Fri 3/6/2009 10:55 AM
To: JSR-314-OPEN(a)JCP.ORG
Subject: [jsr-314-open] Why do we disallow EL for h:dataTable "var" attribute?
Someone on JSR-314-COMMENTS asked this question and I don't recall the
answer, but I trust there's a good one since it's baked into the spec.
Any ideas?
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
16 years, 8 months
Re: [jsr-314-open] [ADMIN] JSF 2.0 Spec Snapshot
by Pete Muir
Ed,
Here are some questions:
* is delta state saving in this revision? The state saving stuff is
still in an appendix, and I find it hard to check.
* Issue 450 (https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=450
) still hasn't been merged into the spec - I've asked about this one
multiple times. Can we get this merged in?
* the big changes due to view parameters don't appear to be merged in?
Otherwise, the areas I have been involved in look good:
* exception handling
* bean validation
On 5 Mar 2009, at 03:39, Ed Burns wrote:
>>>>>> On Wed, 04 Mar 2009 18:52:19 -0800, Ed Burns <Ed.Burns(a)Sun.COM>
>>>>>> said:
>
> EB> I've uploaded a new spec snapshot to [1] and exploded it to [2].
> EB> This one is perilously close to the Proposed Final Draft we'll be
> EB> handing to the JCP. Roger and I still need to do some cleanup.
>
> EB> FWIW, the nightly build of Mojarra fully implements this version
> of the
> EB> spec!
>
> This snapshot includes Facelet tag handlers for Behavior, Converter,
> Validator and UIComponents. If you're interested in this one
> specifially, you can start browsing with [1].
>
> Ed
>
>
> [1] https://javaserverfaces-spec-public.dev.java.net/nonav/snapshots/jsf-spec...
>
>
>
> --
> | ed.burns(a)sun.com | office: 408 884 9519 OR x31640
> | homepage: | http://ridingthecrest.com/
--
Pete Muir
http://www.seamframework.org
http://in.relation.to/Bloggers/Pete
16 years, 8 months