Fix issue #17: Wire dependencies and handle command objects in remote validation #26
Conversation
…/command object in JQueryRemoteValidationController.
|
Thanks for sent me the fix. My old laptop just busted and R.I.P. There will be delay for release of the fix till I got my new laptop :( |
|
I had also been working on #17 but I wasn't sure how to submit a pull request. Assuming I cloned this repo, can I just do a commit -a -m"Fixed fooness" ? Thanks jon |
* New algorithm for determining the error code to use for client-side error messages. Instead of approximating the same error codes that grails uses, we now use the same codes as grails. This allows code that uses server-side validation using messages in the message bundle to use the same codes for messages on the client and the server. For example, previously, a message with the code className.propertyName.minSize.notmet would be successfully retrieved for a constraint violation of the minSize constraint on the server, but would not be used for client-side validation. The useLegacyMessageCodes setting can be used to get the old behavior. * For remote validation, there was a buggy attempt to avoid sending the error message if it was "known". The problem was that just the default message code was checked for the constraint name instead of the message code actually used. We now just always lookup the message rather than attempting to optimize. * Allow custom validators to have their client-side javascript validation function name differ from the server-side constraint name as is the case with the standard grails constraints. * Use the default error code, default error message, and failure code when generating error messages for custom constraints.
|
Can we please look at pulling this fork into master and putting out a new release? I spent quite a bit of time on this, updated the docs with the changes, etc. It's been 9 months since I committed, and it would be very helpful to have this stuff in the official release of this plugin. My project relies on these changes working, and I believe others would benefit as well. Thanks, --Jon |
|
Hi Jon, Appreciate your contributions and sorry for the slow response. I am on a business trip abroad now till end of the month and will find time to merge your changes and release new version once I back home. // Chee Kin |
3 participants
I also ran into the issue reported in issue #17. My fix is nearly identical to the one proposed by Pascal in the comments for issue #17. The code now wires up spring dependencies into the newly created validatable object before doing the validation which is what would normally be the case for a command object on the server side. Also, it checks to see if the object is a domain object or not before calling isAttached() on it since isAttached() won't be present on command objects. It looks like maybe Pascal never sent you a pull request. Can you please pull this fix in?