[bv-dev] Javascript export of bean validation rules

Matt Benson mbenson at apache.org
Fri Jun 29 12:44:03 EDT 2012


On Fri, Jun 29, 2012 at 11:40 AM, Gunnar Morling <gunnar at hibernate.org> wrote:
> Just to add my 2c: I guess it should be rather straight-forward to
> export the standard constraints (@Size etc.) from a given model, e.g.
> using the meta data API which we already have. These info could be
> transferred to the client (e.g. using JSON) where a dedicated JS
> engine could validate the constraints according to the BV rules.
>
> Another story are custom constraints which contain custom Java
> validation code. One idea here could be to offer an API for
> implementing custom constraints in JS. Or one follows GWT's example
> and transforms Java to JS (I think there is support for client-side
> validation of BV constraints based on that approach built into GWT).

Yes; I had already found myself wondering whether Google/GWT provided
any reusable-outside-of-GWT mechanisms for translating simple Java
code to JS.

Matt

>
> --Gunnar
>
>
> 2012/6/29 Hardy Ferentschik <hardy at hibernate.org>:
>>
>> On Jun 28, 2012, at 6:07 PM, Edward Burns wrote:
>>
>>>>>> MI> On Thu, 28 Jun 2012 10:15:14 +0200, Hardy Ferentschik <hardy at hibernate.org> said:
>>>
>>> HF> On Jun 28, 2012, at 6:59 AM, Michael Isvy wrote:
>>>
>>> MI> I was discussing this topic with Emmanuel Bernard by email and
>>> MI> Emmanuel suggested that we move this conversation to this
>>> MI> mailing-list, so here I am :).
>>>
>>> MI> The idea would be to propose a javascript export of the bean
>>> MI> validation rules.
>>>
>>> HF> What exactly do you want to export? An JavaScript implementation of
>>> HF> the default constraints? Do you have already some concrete ideas?
>>>
>>> When I saw this idea right here, moments ago, my first thought was to
>>> specify a JSON format for validation rules and require the existence of
>>> some tool that you could point at a bunch of java code that happens to
>>> have JSR-303 annotations on it and the tool would generate that JSON.
>>> The JSON format would be designed such that the fidelity of the rules
>>> would be mostly maintained such that a corresponding piece of code on
>>> the client side could slurp it down and carry out the rules.
>>
>> I am not sure I am following you. JSON is really just a transport protocol for some data, right?
>> Where is the actual validation logic? Or is this what you want to generate via the tool?
>>
>> The best thing right now would be some prototype or pseudo code/workflow.
>>
>> --Hardy
>>
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev


More information about the beanvalidation-dev mailing list