Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.1.3
    • Fix Version/s: 2.0.10, 2.1.4
    • Component/s: General
    • Labels:
    • Environment:
      Linux 2.6.32-33-generic
      on Google AppEngine Server 1.5.4

      Description

      use of f:ajax tage generets 'this._onWarning is not a function' Error

        Activity

        Hide
        NT Playić added a comment -

        has been updated to subversion

        Show
        NT Playić added a comment - has been updated to subversion
        Hide
        Leonardo Uribe added a comment -

        f:ajax works as expected. The issue was open without provide a use case were this tag could fail. So, there is no evidence about in which case it fails and no patch, so I close this one as invalid.

        Show
        Leonardo Uribe added a comment - f:ajax works as expected. The issue was open without provide a use case were this tag could fail. So, there is no evidence about in which case it fails and no patch, so I close this one as invalid.
        Hide
        Werner Punz added a comment -

        Hi since this error is thrown at the javascript side I want to reinvestigate it. Since I am working on the scripts this week anyway, I will reopen it for further investigation.

        Show
        Werner Punz added a comment - Hi since this error is thrown at the javascript side I want to reinvestigate it. Since I am working on the scripts this week anyway, I will reopen it for further investigation.
        Hide
        Werner Punz added a comment -

        Hello I checked the latest codebase, if the error was there according to my code it should not happen anymore in the latest codebase so give the svn trunk a chance.
        I will check the tags quickly, but for the trunk it should be save to use it without the problem. I also did not have the problem at the trunk, so I need further usecases for investigation.

        Show
        Werner Punz added a comment - Hello I checked the latest codebase, if the error was there according to my code it should not happen anymore in the latest codebase so give the svn trunk a chance. I will check the tags quickly, but for the trunk it should be save to use it without the problem. I also did not have the problem at the trunk, so I need further usecases for investigation.
        Hide
        Werner Punz added a comment -

        Ok reopening this issue again, I found a codepart, which could trigger that error, if you call encodeSubmittableFields without any valid parent form, then you can run into this error.
        I think this could be related to what the user runs into, maybe he forgot the form or is calling one way or the other the function without any request context. I will file the bugfix i do for encodesubmittable fields here as well.
        Hence I reopen the issue.

        Show
        Werner Punz added a comment - Ok reopening this issue again, I found a codepart, which could trigger that error, if you call encodeSubmittableFields without any valid parent form, then you can run into this error. I think this could be related to what the user runs into, maybe he forgot the form or is calling one way or the other the function without any request context. I will file the bugfix i do for encodesubmittable fields here as well. Hence I reopen the issue.
        Hide
        Werner Punz added a comment -

        ok I added some code changes to the ajax utils, if you call getViewState without a form you should now get an error instead, and the error calling routine definitely is there.
        I also overhauled this entire subsystem so that getViewState is called instead of our internal routines, which allowes the routine to be decorated.

        Show
        Werner Punz added a comment - ok I added some code changes to the ajax utils, if you call getViewState without a form you should now get an error instead, and the error calling routine definitely is there. I also overhauled this entire subsystem so that getViewState is called instead of our internal routines, which allowes the routine to be decorated.

          People

          • Assignee:
            Werner Punz
            Reporter:
            NT Playić
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development