Re: [bv-dev] Javascript export of bean validation rules

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! 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. 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(a)oracle.com | office: +1 407 458 0017 | homepage: | http://ridingthecrest.com/ | 14 Business days til JSF 2.2 Public Review to EG