Commons Validator
  1. Commons Validator
  2. VALIDATOR-109

[validator] Built-in JavaScript incompatible with modern AJAX techniques

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.1.1 (alpha)
    • Fix Version/s: 1.3.0 Release
    • Component/s: None
    • Labels:
      None
    • Environment:

      Operating System: other
      Platform: Other

      Description

      I just tried applying the prototype[1] JavaScript library to my project and
      discovered that its mechanism of adding an "extends" function to the base
      JavaScript object causes the validation routines in Commons Validator to break
      because they don't know what to do with the "extends" member.

      Matt Raible reported a similar problem against JSON[2]

      [1]http://prototype.conio.net/
      [2]http://oss.metaparadigm.com/list-archives/json-rpc-java/2005-February/000049.html

      I know there have been big potential changes to the validator JS for a while;
      maybe this is a further motivator.

        Issue Links

          Activity

          Hide
          Martin Cooper added a comment -

          Yes, Prototype is evil. Not only does it add a property to Object, it also adds
          properties to other fundamental JavaScript types, such as Array. This is very
          antisocial behaviour for a toolkit, and pretty much hoses any usage of the 'for
          ... in ...' construct in existing JavaScript code, unless that code was very
          carefully written to work around exactly that behaviour.

          Another big issue with Prototype is that it is not namespaced. All of its
          classes are defined directly within the global JavaScript namespace, and it
          defines some classes with names that are quite likely to exist in application
          code (e.g. Form, Field). This has the potential for creating serious havoc,
          especially in portal / portlet environments.

          Of course, one of the big issues with the Commons Validator JavaScript code is
          that it too is not namespaced. ;-( That's something that needs fixing. It's not
          that hard to fix, but the changes would introduce new rules for people writing
          custom validators. It's most definitely do-able, though, and needs to be done.

          Prototype's increasing popularity, ironically, makes it decreasingly likely that
          the serious deficiencies will be rectified, since that would mean breaking lots
          of existing code. So I guess for Commons Validator, at least, we'll need to code
          around those deficiencies. That too can be done - it's just a pain in the butt,
          adds more code, and shouldn't be necessary.

          Personally, I'm going to focus my client-side efforts on Dojo[1], a properly
          written toolkit that doesn't have these kinds of problems, and I wish the folks
          who want to use Prototype, and its derivatives, the best of luck.

          [1] http://dojotoolkit.org/

          Show
          Martin Cooper added a comment - Yes, Prototype is evil. Not only does it add a property to Object, it also adds properties to other fundamental JavaScript types, such as Array. This is very antisocial behaviour for a toolkit, and pretty much hoses any usage of the 'for ... in ...' construct in existing JavaScript code, unless that code was very carefully written to work around exactly that behaviour. Another big issue with Prototype is that it is not namespaced. All of its classes are defined directly within the global JavaScript namespace, and it defines some classes with names that are quite likely to exist in application code (e.g. Form, Field). This has the potential for creating serious havoc, especially in portal / portlet environments. Of course, one of the big issues with the Commons Validator JavaScript code is that it too is not namespaced. ;-( That's something that needs fixing. It's not that hard to fix, but the changes would introduce new rules for people writing custom validators. It's most definitely do-able, though, and needs to be done. Prototype's increasing popularity, ironically, makes it decreasingly likely that the serious deficiencies will be rectified, since that would mean breaking lots of existing code. So I guess for Commons Validator, at least, we'll need to code around those deficiencies. That too can be done - it's just a pain in the butt, adds more code, and shouldn't be necessary. Personally, I'm going to focus my client-side efforts on Dojo [1] , a properly written toolkit that doesn't have these kinds of problems, and I wish the folks who want to use Prototype, and its derivatives, the best of luck. [1] http://dojotoolkit.org/
          Hide
          Niall Pemberton added a comment -

          IMO the way client side validations are done by "type" is wrong anyway. It
          should validate by field, as the server side validations are done and this
          issue is another good reason to change it.

          At some point I intend to get back to doing something with COM-1729.

          Show
          Niall Pemberton added a comment - IMO the way client side validations are done by "type" is wrong anyway. It should validate by field, as the server side validations are done and this issue is another good reason to change it. At some point I intend to get back to doing something with COM-1729 .
          Hide
          Niall Pemberton added a comment -

          Laurie posted on the struts user list that the yet-to-be-release 1.4 version of
          prototype seems to be OK:

          http://www.mail-archive.com/user%40struts.apache.org/msg36844.html
          http://www.mail-archive.com/user%40struts.apache.org/msg36848.html

          Show
          Niall Pemberton added a comment - Laurie posted on the struts user list that the yet-to-be-release 1.4 version of prototype seems to be OK: http://www.mail-archive.com/user%40struts.apache.org/msg36844.html http://www.mail-archive.com/user%40struts.apache.org/msg36848.html
          Hide
          Philippe Mouawad added a comment -

          I created a bug with id 37594 and submitted a patch that solves this issue.
          If you're interested go to the bug and see patches or completes JS files.

          Philippe.

          Show
          Philippe Mouawad added a comment - I created a bug with id 37594 and submitted a patch that solves this issue. If you're interested go to the bug and see patches or completes JS files. Philippe.
          Hide
          Martin Cooper added a comment -
              • COM-2577 has been marked as a duplicate of this bug. ***
          Show
          Martin Cooper added a comment - COM-2577 has been marked as a duplicate of this bug. ***
          Hide
          Philippe Mouawad added a comment -

          Created an attachment (id=17015)
          Correction to JS files of the library starting from version 1.1.4

          Here are the correction made on your Javascript:

          Scope too large for your variables:

          • oCreditCard, oByte,oDate
          • Replaced == true by === true, same for == 0
          • parse replaced by parse(x, 10)

          I'am using prototype.js in conjunction with the validator but I am facing the
          following problem,
          this library adds a field extends to objects so for (var x in oRequired) will
          iterate over 4 fields instead of 3
          and encounter x = 'extends' and oRequired[x][0] will be undefined breaking the
          rest.

          What I did was to add matchValidationVariable () function with the following
          code that checks that the variable
          oRequired[x][0] is not undefined and that the name of x matches your variable
          names ('^a[0-9]*$'):
          function matchValidationVariable(variable, value)

          { var theRegexp = new RegExp('^a[0-9]*$'); return ((typeof value[0] !== undefined) && (theRegexp.exec(variable) !== null)); }
          Show
          Philippe Mouawad added a comment - Created an attachment (id=17015) Correction to JS files of the library starting from version 1.1.4 Here are the correction made on your Javascript: Scope too large for your variables: oCreditCard, oByte,oDate Replaced == true by === true, same for == 0 parse replaced by parse(x, 10) I'am using prototype.js in conjunction with the validator but I am facing the following problem, this library adds a field extends to objects so for (var x in oRequired) will iterate over 4 fields instead of 3 and encounter x = 'extends' and oRequired [x] [0] will be undefined breaking the rest. What I did was to add matchValidationVariable () function with the following code that checks that the variable oRequired [x] [0] is not undefined and that the name of x matches your variable names ('^a [0-9] *$'): function matchValidationVariable(variable, value) { var theRegexp = new RegExp('^a[0-9]*$'); return ((typeof value[0] !== undefined) && (theRegexp.exec(variable) !== null)); }
          Hide
          Philippe Mouawad added a comment -

          Created an attachment (id=17016)
          Patch from version 1.1.4 (JS files)

          Same content a zip files but at patch format.

          Show
          Philippe Mouawad added a comment - Created an attachment (id=17016) Patch from version 1.1.4 (JS files) Same content a zip files but at patch format.
          Hide
          Philippe Mouawad added a comment -

          Created an attachment (id=17025)
          Javascript patch to version 1.2.0

          This is the patch to current version in the Subversion and in the Subversion
          format.

          Show
          Philippe Mouawad added a comment - Created an attachment (id=17025) Javascript patch to version 1.2.0 This is the patch to current version in the Subversion and in the Subversion format.
          Hide
          Niall Pemberton added a comment -

          Philippe, thanks for the patch - I implemented something slightly different,
          testing if its an array of length 3. Tried this out with Prototype 1.3.1 and it
          worked fine.

          http://svn.apache.org/viewcvs?rev=367089&view=rev

          This should be available in the next nightly build to test out (i.e. one dated
          9th Jan or later):

          http://cvs.apache.org/builds/jakarta-commons/nightly/commons-validator/

          Closing as FIXED (I'll open a new bug for the namespaced issue).

          Show
          Niall Pemberton added a comment - Philippe, thanks for the patch - I implemented something slightly different, testing if its an array of length 3. Tried this out with Prototype 1.3.1 and it worked fine. http://svn.apache.org/viewcvs?rev=367089&view=rev This should be available in the next nightly build to test out (i.e. one dated 9th Jan or later): http://cvs.apache.org/builds/jakarta-commons/nightly/commons-validator/ Closing as FIXED (I'll open a new bug for the namespaced issue).
          Hide
          Niall Pemberton added a comment -

          COM-2697 opened for the namespace issue

          Show
          Niall Pemberton added a comment - COM-2697 opened for the namespace issue
          Hide
          Niall Pemberton added a comment -

          Re-openned and the set to "Resolved Fixed" again to correct "resolution" which was lost in Bugzilla --> JIRA conversion

          Show
          Niall Pemberton added a comment - Re-openned and the set to "Resolved Fixed" again to correct "resolution" which was lost in Bugzilla --> JIRA conversion

            People

            • Assignee:
              Niall Pemberton
              Reporter:
              Joe Germuska
            • Votes:
              1 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development