Hi herrmann, Thanks for your suggestion.As well as now I am only concerning most on the client-side validation and user experience.So I have proposed the above design.I will look into this link that you have provide well.
On Wed, Apr 8, 2015 at 10:50 PM, Manfred Herrmann < [email protected]> wrote: > 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 <[email protected]>: > >> 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:[email protected] <[email protected]>* >> >> *M :+94770832823 <%2B94770832823> * >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Thank You.* *Rajeenthini Satkunam* *Associate Software Engineer | WSO2* *E:[email protected] <[email protected]>* *M :+94770832823 *
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
