myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthias Wessendorf <mat...@apache.org>
Subject Re: JSF 2.0 - Bean Validation, Unified EL and other specs
Date Wed, 28 Oct 2009 01:06:04 GMT
Hi Jan-Kees,

thanks for creating this ticket. I'd like to see something like this.
Sounds (to me) very useful...

-M

On Tue, Oct 27, 2009 at 12:09 PM, Jan-Kees van Andel
<jankeesvanandel@gmail.com> wrote:
> Just to be complete...
>
> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=657
>
> /JK
>
>
> 2009/10/27 Ryan Lubke <Ryan.Lubke@sun.com>:
>> On 10/25/09 10:57 AM, Jan-Kees van Andel wrote:
>>>
>>> Hey (CC MyFaces Dev),
>>>
>>> For MyFaces, I have implemented the first version of Bean Validation
>>> support. But my implementation had a TCK issue, because I had some
>>> non-specified public fields. These fields indicated the runtime
>>> availability of some libraries.
>>> See: http://issues.apache.org/jira/browse/MYFACES-2386 for the issue.
>>>
>>> To fix it, I've moved the public fields to a separate, package-private
>>> class (still in the API), to hide them from end users and fix TCK
>>> issues.
>>> But the problem with this solution is that the fields are used in more
>>> than one package (currently "validate" and "component". Probably more
>>> to come), giving me only one option: Code duplication.
>>>
>>> I personally hate code duplication, which leads me to the question: Is
>>> it a good idea to put an API in the spec which contains the
>>> information I'm providing in my current class?
>>>
>>> Initially I wrote this message because I hate code duplication, but
>>> there might be another benefit, since 3th party libraries may also
>>> want to check the existence of certain libraries. Especially Bean
>>> Validation and Web Beans may have impact on framework/component
>>> authors. I think some API like this is quite important, because JSF
>>> (since 2.0) doesn't live on its own anymore, but interacts with other
>>> libraries as well.
>>>
>>> My implementation
>>>
>>> (http://svn.apache.org/viewvc/myfaces/core/trunk/api/src/main/java/javax/faces/validator/_ExternalSpecifications.java?revision=829526&view=markup)
>>> currently works for MyFaces, but the official API may need to be a bit
>>> more reusable/extensible.
>>> I was thinking of something simple:
>>> public interface FacesEnvironment /* This name probably sucks */ {
>>>     public boolean isBeanValidationAvailable();
>>>     public boolean isUnifiedELAvailable();
>>>     // ...
>>> }
>>>
>>> An interface might be overkill, but the EG may work out the details. ;-)
>>>
>>
>> Specifics such as interfaces aside, this seems like a useful concept.  I
>> would recommend
>> logging an issue against the spec [1] for 2.1.
>>
>> [1] https://javaserverfaces-spec-public.dev.java.net
>>>
>>> What do you guys think? Useful addition for "JSF 2.1"?
>>>
>>> Regards,
>>> Jan-Kees van Andel
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@javaserverfaces.dev.java.net
>>> For additional commands, e-mail: dev-help@javaserverfaces.dev.java.net
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@javaserverfaces.dev.java.net
>> For additional commands, e-mail: dev-help@javaserverfaces.dev.java.net
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help@javaserverfaces.dev.java.net
>
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf

Mime
View raw message