You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@bval.apache.org by Nick Chalko <nc...@google.com> on 2010/07/20 01:37:43 UTC
Bean Validation for GWT
I am working on JSR-303 support for the Google Web Tool Kit (gwt).
I am interested in using the apache bean validation as a starting
point and I want to get your feed back.
GWT does not support Reflection so any code that uses reflection would
have to be changed GWT code
I see a few ways this could be approached
Add a gwt subproject that works on the GWT specific parts
Fork the code and tune for GWT.
What is your take on this?
Is there any interest?
Do you think we can reasonably isolate the reflection code so this
will run on GWT.
R,
Nick
Re: Bean Validation for GWT
Posted by Gerhard Petracek <ge...@gmail.com>.
hi carlos,
there is a bv-api we should use. i suggested it in the eg because i saw
exactly such use-cases. (myfaces extval already uses it.)
if we start such a module, we should just use the bv-api. we also need such
a module for a new myfaces extval add-on (see [1]).
my idea was to impl. a portable js-bv-engine. so we can use it for projects
like myfaces extval as well as a gwt module.
regards,
gerhard
[1] https://issues.apache.org/jira/browse/EXTVAL-89
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/7/22 Carlos Vara <ba...@gmail.com>
> Not really. A JSR303 validator would also need to hunt for annotations in
>> a given class, as well as using reflection-based tricks to generate proxies
>> for XML-declared validation constraints. All in all it would seem that a
>> unified interface with various implementations would be the appropriate
>> mechanism to get interoperability between GWT and libraries that typically
>> use reflection in Java runtime environments.
>>
>
> True. The good news is that the "validation" part only uses the reflection
> API when it has to invoke getters. On the other way, the "parsing" phase
> relies heavily on reflection.
>
> Doing the parsing only on the server (on init, as this is a do once step),
> and having a way of transferring the validation metadata to the client
> (javascript) to perform the validation there would look like the easiest
> approach to me. Infact, I think bval-core has functionality for the metadata
> transfer, but Roman may correct me on this.
>
> Regards,
> Carlos
>
>
>
>> > I will down load and start poking around in the code.
>> >
>> >
>> > My second question is, Is there interest a bval-gwt subproject?
>> >
>>
>> I didn't want to speak for the community, but given Donald's input, I
>> would agree: the more the merrier.
>>
>> -Matt
>>
>> > R,
>> > nick
>>
>>
>
Re: Bean Validation for GWT
Posted by Carlos Vara <ba...@gmail.com>.
>
> Not really. A JSR303 validator would also need to hunt for annotations in
> a given class, as well as using reflection-based tricks to generate proxies
> for XML-declared validation constraints. All in all it would seem that a
> unified interface with various implementations would be the appropriate
> mechanism to get interoperability between GWT and libraries that typically
> use reflection in Java runtime environments.
>
True. The good news is that the "validation" part only uses the reflection
API when it has to invoke getters. On the other way, the "parsing" phase
relies heavily on reflection.
Doing the parsing only on the server (on init, as this is a do once step),
and having a way of transferring the validation metadata to the client
(javascript) to perform the validation there would look like the easiest
approach to me. Infact, I think bval-core has functionality for the metadata
transfer, but Roman may correct me on this.
Regards,
Carlos
> > I will down load and start poking around in the code.
> >
> >
> > My second question is, Is there interest a bval-gwt subproject?
> >
>
> I didn't want to speak for the community, but given Donald's input, I would
> agree: the more the merrier.
>
> -Matt
>
> > R,
> > nick
>
>
Re: Bean Validation for GWT
Posted by Nick Chalko <nc...@google.com>.
On Tue, Jul 20, 2010 at 1:07 PM, Gerhard Petracek
<ge...@gmail.com> wrote:
> hi,
> there is already such a project [1]. imo we should contact the project team.
> regards,
> gerhard
>
I have talked to chris about it and used gwt-validation.
It is from before the finalization of the JSR and diverged in some key points.
Since bval is already passing the TCK, I thought it might be a better
starting point.
Chris have you looked at the apache bval project yet?
r,
Nick
Re: Bean Validation for GWT
Posted by Gerhard Petracek <ge...@gmail.com>.
hi,
there is already such a project [1]. imo we should contact the project team.
regards,
gerhard
[1] http://code.google.com/p/gwt-validation/
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/7/20 Matt Benson <gu...@gmail.com>
>
> On Jul 20, 2010, at 9:39 AM, Nick Chalko wrote:
>
> > On Tue, Jul 20, 2010 at 6:44 AM, Matt Benson <gu...@gmail.com>
> wrote:
> >> Hi Nick--so, the GWT alternative to reflection would be some form of
> >> javascript inspection, or do they provide an API over that? I never got
> >> around to giving GWT a try, so I am completely unfamiliar with how it
> works
> >> beyond a vague awareness that everything compiles to javascript (if
> that's
> >> even correct). It sounds like you're saying the entire app, including
> >> bytecodes from third-party libraries, is ported and it all runs
> client-side,
> >> with reflection being a (the?) java API that is conspicuously
> unavailable.
> >> My initial reaction to this is that it this would seem likely to cause
> >> problems working with many Java libraries. To go beyond Bean Validation
> >> here, it sounds like a reflection analogue of slf4j might be in order,
> >> whereby a secondary "reflection" API is defined, with implementation
> jars
> >> provided at runtime. Applications/libraries wanting to provide support
> for
> >> environments where java.reflect reflection is unavailable, but some
> >> alternative exists, could then code to the redefined API. It happens
> that I
> >> have contributed for some years to a library that includes such an API,
> and
> >> have given thought over the years to incubating an overhaul of it at
> Apache
> >> (targeted for Commons). If I've not guessed badly on any of the
> >> fundamentals, this would seem a reasonable direction to take.
> >>
> >> -Matt
> >>
> >
> > Matt,
> >
> > GWT use Differed binding
> > (
> http://code.google.com/webtoolkit/doc/1.6/FAQ_Client.html#What_is_Deferred_Binding?
> ).
> > My main question was, how isolated is the code that need reflection.
> > My assumption is should only be needed in the code that actually
> > validates an object graph.
> >
>
> Not really. A JSR303 validator would also need to hunt for annotations in
> a given class, as well as using reflection-based tricks to generate proxies
> for XML-declared validation constraints. All in all it would seem that a
> unified interface with various implementations would be the appropriate
> mechanism to get interoperability between GWT and libraries that typically
> use reflection in Java runtime environments.
>
> > I will down load and start poking around in the code.
> >
> >
> > My second question is, Is there interest a bval-gwt subproject?
> >
>
> I didn't want to speak for the community, but given Donald's input, I would
> agree: the more the merrier.
>
> -Matt
>
> > R,
> > nick
>
>
Re: Bean Validation for GWT
Posted by Matt Benson <gu...@gmail.com>.
On Jul 20, 2010, at 9:39 AM, Nick Chalko wrote:
> On Tue, Jul 20, 2010 at 6:44 AM, Matt Benson <gu...@gmail.com> wrote:
>> Hi Nick--so, the GWT alternative to reflection would be some form of
>> javascript inspection, or do they provide an API over that? I never got
>> around to giving GWT a try, so I am completely unfamiliar with how it works
>> beyond a vague awareness that everything compiles to javascript (if that's
>> even correct). It sounds like you're saying the entire app, including
>> bytecodes from third-party libraries, is ported and it all runs client-side,
>> with reflection being a (the?) java API that is conspicuously unavailable.
>> My initial reaction to this is that it this would seem likely to cause
>> problems working with many Java libraries. To go beyond Bean Validation
>> here, it sounds like a reflection analogue of slf4j might be in order,
>> whereby a secondary "reflection" API is defined, with implementation jars
>> provided at runtime. Applications/libraries wanting to provide support for
>> environments where java.reflect reflection is unavailable, but some
>> alternative exists, could then code to the redefined API. It happens that I
>> have contributed for some years to a library that includes such an API, and
>> have given thought over the years to incubating an overhaul of it at Apache
>> (targeted for Commons). If I've not guessed badly on any of the
>> fundamentals, this would seem a reasonable direction to take.
>>
>> -Matt
>>
>
> Matt,
>
> GWT use Differed binding
> (http://code.google.com/webtoolkit/doc/1.6/FAQ_Client.html#What_is_Deferred_Binding?).
> My main question was, how isolated is the code that need reflection.
> My assumption is should only be needed in the code that actually
> validates an object graph.
>
Not really. A JSR303 validator would also need to hunt for annotations in a given class, as well as using reflection-based tricks to generate proxies for XML-declared validation constraints. All in all it would seem that a unified interface with various implementations would be the appropriate mechanism to get interoperability between GWT and libraries that typically use reflection in Java runtime environments.
> I will down load and start poking around in the code.
>
>
> My second question is, Is there interest a bval-gwt subproject?
>
I didn't want to speak for the community, but given Donald's input, I would agree: the more the merrier.
-Matt
> R,
> nick
Re: Bean Validation for GWT
Posted by Donald Woods <dw...@apache.org>.
Definite interest in a bval-gwt subproject, as long as the bval-core and
bval-jsr303 code still passes the JSR-303 TCK and we don't impact
performance when compared to the RI.... :-)
-Donald
On 7/20/10 10:39 AM, Nick Chalko wrote:
> On Tue, Jul 20, 2010 at 6:44 AM, Matt Benson <gu...@gmail.com> wrote:
>> Hi Nick--so, the GWT alternative to reflection would be some form of
>> javascript inspection, or do they provide an API over that? I never got
>> around to giving GWT a try, so I am completely unfamiliar with how it works
>> beyond a vague awareness that everything compiles to javascript (if that's
>> even correct). It sounds like you're saying the entire app, including
>> bytecodes from third-party libraries, is ported and it all runs client-side,
>> with reflection being a (the?) java API that is conspicuously unavailable.
>> My initial reaction to this is that it this would seem likely to cause
>> problems working with many Java libraries. To go beyond Bean Validation
>> here, it sounds like a reflection analogue of slf4j might be in order,
>> whereby a secondary "reflection" API is defined, with implementation jars
>> provided at runtime. Applications/libraries wanting to provide support for
>> environments where java.reflect reflection is unavailable, but some
>> alternative exists, could then code to the redefined API. It happens that I
>> have contributed for some years to a library that includes such an API, and
>> have given thought over the years to incubating an overhaul of it at Apache
>> (targeted for Commons). If I've not guessed badly on any of the
>> fundamentals, this would seem a reasonable direction to take.
>>
>> -Matt
>>
>
> Matt,
>
> GWT use Differed binding
> (http://code.google.com/webtoolkit/doc/1.6/FAQ_Client.html#What_is_Deferred_Binding?).
> My main question was, how isolated is the code that need reflection.
> My assumption is should only be needed in the code that actually
> validates an object graph.
>
> I will down load and start poking around in the code.
>
>
> My second question is, Is there interest a bval-gwt subproject?
>
> R,
> nick
>
Re: Bean Validation for GWT
Posted by Nick Chalko <nc...@google.com>.
On Tue, Jul 20, 2010 at 6:44 AM, Matt Benson <gu...@gmail.com> wrote:
> Hi Nick--so, the GWT alternative to reflection would be some form of
> javascript inspection, or do they provide an API over that? I never got
> around to giving GWT a try, so I am completely unfamiliar with how it works
> beyond a vague awareness that everything compiles to javascript (if that's
> even correct). It sounds like you're saying the entire app, including
> bytecodes from third-party libraries, is ported and it all runs client-side,
> with reflection being a (the?) java API that is conspicuously unavailable.
> My initial reaction to this is that it this would seem likely to cause
> problems working with many Java libraries. To go beyond Bean Validation
> here, it sounds like a reflection analogue of slf4j might be in order,
> whereby a secondary "reflection" API is defined, with implementation jars
> provided at runtime. Applications/libraries wanting to provide support for
> environments where java.reflect reflection is unavailable, but some
> alternative exists, could then code to the redefined API. It happens that I
> have contributed for some years to a library that includes such an API, and
> have given thought over the years to incubating an overhaul of it at Apache
> (targeted for Commons). If I've not guessed badly on any of the
> fundamentals, this would seem a reasonable direction to take.
>
> -Matt
>
Matt,
GWT use Differed binding
(http://code.google.com/webtoolkit/doc/1.6/FAQ_Client.html#What_is_Deferred_Binding?).
My main question was, how isolated is the code that need reflection.
My assumption is should only be needed in the code that actually
validates an object graph.
I will down load and start poking around in the code.
My second question is, Is there interest a bval-gwt subproject?
R,
nick
Re: Bean Validation for GWT
Posted by Matt Benson <gu...@gmail.com>.
Hi Nick--so, the GWT alternative to reflection would be some form of
javascript inspection, or do they provide an API over that? I never
got around to giving GWT a try, so I am completely unfamiliar with
how it works beyond a vague awareness that everything compiles to
javascript (if that's even correct). It sounds like you're saying
the entire app, including bytecodes from third-party libraries, is
ported and it all runs client-side, with reflection being a (the?)
java API that is conspicuously unavailable. My initial reaction to
this is that it this would seem likely to cause problems working with
many Java libraries. To go beyond Bean Validation here, it sounds
like a reflection analogue of slf4j might be in order, whereby a
secondary "reflection" API is defined, with implementation jars
provided at runtime. Applications/libraries wanting to provide
support for environments where java.reflect reflection is
unavailable, but some alternative exists, could then code to the
redefined API. It happens that I have contributed for some years to
a library that includes such an API, and have given thought over the
years to incubating an overhaul of it at Apache (targeted for
Commons). If I've not guessed badly on any of the fundamentals, this
would seem a reasonable direction to take.
-Matt
On Jul 19, 2010, at 6:37 PM, Nick Chalko wrote:
> I am working on JSR-303 support for the Google Web Tool Kit (gwt).
> I am interested in using the apache bean validation as a starting
> point and I want to get your feed back.
>
> GWT does not support Reflection so any code that uses reflection would
> have to be changed GWT code
>
> I see a few ways this could be approached
>
> Add a gwt subproject that works on the GWT specific parts
> Fork the code and tune for GWT.
>
> What is your take on this?
> Is there any interest?
> Do you think we can reasonably isolate the reflection code so this
> will run on GWT.
>
> R,
> Nick