hi Rajeenthini, the proposed jquery-validation would a realy helpful feature. But even more helpful would it be to validate on client-side in sync with server-side-validation. The data would be secure and consistent through server-side-validation. And at the same time the user experience would be great.
In jaggeryjs framework codebase there are rhino and hostobjects used. Would it not a good idea to try using jquery-validation for server-side validation and sync the rules and methods to the client? The development workflow could like: 1. client-side development and test cycle 2. deploy on jaggery-server-side and test client+server-side validation What do you think? best regards Manfred e.g. some thoughts about client-/server-side validation from: http://blogs.lessthandot.com/index.php/webdev/client-side-vs-server-side-validation-in-web-applications/ Client-Side > But when we look at how well it achieves the purpose, we find it has a lot > of gaps: > > - Yes – It prevents bad values for users with good intent > > > - Yes – It helps the good intent user correct their value without the > overhead of a server round-trip > > > - No – It prevents bad values when a script fails to load (like jQuery) > > > - No – It prevents bad values as a result of malicious editing of the > web form (developer tools) > > > - No – It prevents bad values submitted directly to the endpoint (ex: > Cross-Site > Request Forgery > <https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29> > ) > > > - No – It prevents bad values when accessed in frames > <https://www.owasp.org/index.php/Cross_Frame_Scripting> > > > - No – It prevents bad values when data is altered via aMan-in-the-middle > attack <https://www.owasp.org/index.php/Man-in-the-middle_attack> > > Server-Side > So how does this stack up against the client-side method? > > - Yes – It prevents bad values for users with good intent > > > - No – It helps the good intent user correct their value without the > overhead of a server round-trip > > > - Yes – It prevents bad values when a script fails to load (like > jQuery) > > > - Yes – It prevents bad values as a result of malicious editing of the > web form (developer tools) > > > - Yes – It prevents bad values submitted directly to the endpoint (ex: > Cross-Site > Request Forgery > <https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29> > ) > > > - Yes – It prevents bad values when accessed in frames > <https://www.owasp.org/index.php/Cross_Frame_Scripting> > > > - Yes – It prevents bad values when data is altered via a Man-in-the-middle > attack <https://www.owasp.org/index.php/Man-in-the-middle_attack> > > 2015-04-08 6:53 GMT+02:00 Rajeenthini Satkunam <rajeenth...@wso2.com>: > Hi all, > > *purpose & Research* > > I am currently working on a task that do client-side validation for the > Enterprise Store - Publisher.As for now we have server-side validation by > asset RXT. For example it checks whether the field is required or readonly > as well as validation for URL.I would like to propose a design for > pluggable client-side validation using JQuery validator. > > JQuery validation plugin makes simple client-side form validation easy and > gives plenty of customization options. > > Advantages of JQuery validation plugin > > - Set of validation methods > - Default error messages > - It's providing API for writing our own methods > - I18n support -(Error messages can be translated into 37 other > languages) > > *Proposed Design view* > > > > - Include another property called client-side-validation in asset.js > - define a custom validation called validations.js in the js folder > > Here I can explain with the example > > fields: { > provider: { > readonly: true > }, > name: { > name: { > name: 'name', > label: 'Name' > }, > updatable: false, > validation: function () { > } > }, > version: { > name: { > label: 'Version' > } > }, > createdtime: { > hidden: true > *client_side_validation* : { > > "name" : "*time_validator*", > > "params" : { "K1" : V1 , "K2" : v2 }, > > "sucess_message" : "validation sucess", > > "error_message" : "validation unsucess" > } > > } > } > > And the custom validator method in validations.js file > > jQuery.validator.addMethod(name,method[,message]) > > jQuery.validator.addMethod("*time_validator*",method,message); > > So when the function call by proper validation name It will be validate > the field which satisfy the validations regarding to that function and will > give proper success message or error message. > > please find the references about jQuery validator[1] > [1] - http://jqueryvalidation.org/ > > Please share your thoughts. > > -- > > *Thank You.* > > *Rajeenthini Satkunam* > > *Associate Software Engineer | WSO2* > > > *E:rajeenth...@wso2.com <rajeenth...@wso2.com>* > > *M :+94770832823 <%2B94770832823> * > > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
