[bv-dev] Javascript export of bean validation rules

[Edward Burns]

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?

EB> When I saw this idea right here, moments ago, my first thought was to
EB> specify a JSON format for validation rules and require the existence of
EB> some tool that you could point at a bunch of java code that happens to
EB> have JSR-303 annotations on it and the tool would generate that JSON.
EB> The JSON format would be designed such that the fidelity of the rules
EB> would be mostly maintained such that a corresponding piece of code on
EB> the client side could slurp it down and carry out the rules.

HF> I am not sure I am following you. JSON is really just a transport
HF> protocol for some data, right?  Where is the actual validation
HF> logic? Or is this what you want to generate via the tool?

It's possible to encode JavaScript functions in JSON.  That's what I was
thinking of here.  I don't want to write that code myself, though!

>>>>> On Sat, 30 Jun 2012 12:02:19 +0200, Gerhard Petracek <gerhard.petracek at gmail.com> said:

GP> 3 years ago we started to brainstorm such an idea for bv+jsf and we
GP> came up with 10 very basic requirements.  however, there are too
GP> many different ideas out there how it should work and each of them
GP> isn't trivial (+ has some issues).  since validation via
GP> ajax-requests doesn't have most issues we identified with a
GP> client-side approach and it's available in jsf already, we stopped
GP> working on it.

>>>>> On Sun, 1 Jul 2012 11:28:14 +0200, Emmanuel Bernard <emmanuel at hibernate.org> said:

EmmanualB> See below the proposal Pete Muir, Gerhard and I wrote for
EmmanualB> client side JSF back in 2008. This proposal did not go
EmmanualB> further at the time because we felt it would be too much for
EmmanualB> a v1 of the JSF-BV integration.  It does not involve sending
EmmanualB> the metadata via JSON but rather specify how to write the
EmmanualB> piece of Javascript responsible to validate a given value for
EmmanualB> a given constraint and let the client side web framework wire
EmmanualB> this altogether.

That works too.  In any case, it's perfectly acceptable to decline to
satisfy a use-case in the spec, leaving it for non-spec technology to
satisfy.  It's funny, JSON is also creeping its way into JSF 2.2, but
the majority of experts seem to prefer to leave it out.

Ed

-- 
| edward.burns at oracle.com | office: +1 407 458 0017
| homepage:               | http://ridingthecrest.com/
| 14 Business days til JSF 2.2 Public Review to EG