JSF 2.0 - Bean Validation, Unified EL and other specs

[Jan-Kees van Andel]

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. ;-)

What do you guys think? Useful addition for "JSF 2.1"?

Regards,
Jan-Kees van Andel

[Martin Marinschek-3]

Hi Jan-Kees,

for now, our last ressort ist code duplication. For the future, you
should file an issue against the spec, I would say.

regards,

Martin

On 10/25/09, Jan-Kees van Andel <jankeesvanandel@...> 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. ;-)
>
> What do you guys think? Useful addition for "JSF 2.1"?
>
> Regards,
> Jan-Kees van Andel
>

--

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

[Ryan Lubke]

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@...
> For additional commands, e-mail: dev-help@...
>
>    

[Jan-Kees van Andel]

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@...>:

> 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@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

[Matthias Wessendorf-4]

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@...> 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@...>:
>> 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@...
>>> For additional commands, e-mail: dev-help@...
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
Matthias Wessendorf

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

[Ed Burns]

>>>>> On Tue, 27 Oct 2009 18:06:04 -0700, Matthias Wessendorf <matzew@...> said:

MW> Hi Jan-Kees,
MW> thanks for creating this ticket. I'd like to see something like this.
MW> Sounds (to me) very useful...

Note that there is a precedent for doing this kind of discovery without
requiring a Java language signature: the way properties are conveyed to
the standard XML parsers in Java.  I would rather avoid introducing a
signature for this because it needs to be very fluid over time.

Ed

--
| ed.burns@...  | office: 408 884 9519 OR x31640
| homepage:         | http://ridingthecrest.com/

[Matthias Wessendorf-4]

On Tue, Nov 3, 2009 at 4:24 PM, Ed Burns <Ed.Burns@...> wrote:

>>>>>> On Tue, 27 Oct 2009 18:06:04 -0700, Matthias Wessendorf <matzew@...> said:
>
> MW> Hi Jan-Kees,
> MW> thanks for creating this ticket. I'd like to see something like this.
> MW> Sounds (to me) very useful...
>
> Note that there is a precedent for doing this kind of discovery without
> requiring a Java language signature: the way properties are conveyed to
> the standard XML parsers in Java.  I would rather avoid introducing a
> signature for this because it needs to be very fluid over time.

fair enough, so let's keep it to be part of the implementation.
In myfaces we have several non public classes, big issue here
(in this particular) case is that we actually have to duplicate the
code. Oh well :-)

-M

>
> Ed
>
> --
> | ed.burns@...  | office: 408 884 9519 OR x31640
> | homepage:         | http://ridingthecrest.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

--
Matthias Wessendorf

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

[Ed Burns]

>>>>> On Tue, 03 Nov 2009 16:29:22 +0100, Matthias Wessendorf <matzew@...> said:

MW> On Tue, Nov 3, 2009 at 4:24 PM, Ed Burns <Ed.Burns@...> wrote:
>>>>>>> On Tue, 27 Oct 2009 18:06:04 -0700, Matthias Wessendorf <matzew@...> said:
>>
MW> Hi Jan-Kees,
MW> thanks for creating this ticket. I'd like to see something like this.
MW> Sounds (to me) very useful...
>>
>> Note that there is a precedent for doing this kind of discovery without
>> requiring a Java language signature: the way properties are conveyed to
>> the standard XML parsers in Java.  I would rather avoid introducing a
>> signature for this because it needs to be very fluid over time.

MW> fair enough, so let's keep it to be part of the implementation.
MW> In myfaces we have several non public classes, big issue here
MW> (in this particular) case is that we actually have to duplicate the
MW> code. Oh well :-)

I'm not saying we can't have an API, I'm just saying that the API
doesn't have to be encoded using Java language signatures such as an
interface.  This is a broader question of allowing the JSF runtime to
expose metadata, such as configuration and capabilities.  There is lots
of prior art on how to do this without using Java language signatures.

Ed

--
| ed.burns@...  | office: 408 884 9519 OR x31640
| homepage:         | http://ridingthecrest.com/