Page 1 of 3 123 LastLast
Results 1 to 10 of 25

Thread: [OPEN-1039] JsonReader bug in 3.2.1 that affects Ext.data.ArrayStore

    Thank you for reporting this bug. We will make it our priority to review this report.
  1. #1
    Ext JS Premium Member
    Join Date
    Jul 2009
    Posts
    27

    Default [OPEN-1039] JsonReader bug in 3.2.1 that affects Ext.data.ArrayStore

    Ext version tested:

    • Ext 3.2.1 (buggy)
    • Ext 3.1.0 (ok)



    Description:

    • Ext.data.ArrayStore fails to instantiate when field name begins with non-word char and also contains a '.' (or '[' for that matter)



    Test Case:

    Code:
    Ext.onReady(function() {
            var store = new Ext.data.ArrayStore({
              fields: [{"name":"*Mr. Smith"}]
            });
            alert('got here!');
          });
    Steps to reproduce the problem:

    • Run the code, see if the alert box shows up



    The result that was expected:

    • Alert box shows up



    The result that occurs instead:

    • No show - script execution fails with an error



    Possible fix:

    • Several options:


    1. Revert Ext.data.JsonReader.createAccessor to 3.1.0 version.
    2. Fix the code inside Ext.data.JsonReader.createAccessor.
    3. Use Ext.data.JsonReader.simpleAccess to replace Ext.data.JsonReader.createAccessor (this clearly was echoed by the Ext team member who left comment "TODO This isn't used anywhere?? Don't we want to use this where possible instead of complex #createAccessor?" on simpleAccess.

    But clearly the reason why #3 option wasn't already taken was the hack implemented in it was not available in simpleAccess, although there's almost certainly a better way to achieve that.
    Another important comment is that we've noticed multiple instances where "new" code in Ext 3.2.1 created bugs instead of improving the old working code. Another such instance was documented here. It was a bug (unfixed, though we thoroughly explained) in Ext.data.Store. I sincerely hope that more care be taken by the Ext team when rewriting existing working code.

  2. #2
    Sencha User Condor's Avatar
    Join Date
    Mar 2007
    Location
    The Netherlands
    Posts
    24,246

    Default

    Quick fix:
    Code:
    Ext.override(Ext.data.ArrayReader, {
      buildExtractors: Ext.emptyFn,
      extractValues: Ext.emptyFn
    });
    There are much better ways to solve this, but that would require a rather big rewrite of all the readers (which is being done for Ext 4).

  3. #3
    Ext JS Premium Member
    Join Date
    Jul 2009
    Posts
    27

    Default

    I'm fine with removing those functions, but there seems to be confusion even among Ext team members as to the importance of those functions, are you sure changing them to emptyFn is not going to affect any existing apps? For my own usage, I simply overrode createAccessor using 3.1.0 code.

  4. #4
    Sencha Premium User evant's Avatar
    Join Date
    Apr 2007
    Location
    Sydney, Australia
    Posts
    19,250

    Default

    Obviously it's a fairly strange use case, but technically valid nonetheless.

    I think the simplest change is to just modify the regex in createAccessor to only match "[" or "." at the start of the string.
    Twitter - @evantrimboli
    Former Sencha framework engineer, available for consulting.
    As of 2017-09-22 I am not employed by Sencha, all subsequent posts are my own and do not represent Sencha in any way.

  5. #5
    Ext JS Premium Member
    Join Date
    Jul 2009
    Posts
    27

    Default

    Quote Originally Posted by evant View Post
    Obviously it's a fairly strange use case
    Why is it strange? There could be many valid use cases that break 3.2.x. Field names like "2008.01", "?.?.?" would all break it. I don't see why "*Mr. Smith" would never be used as a column name either.

    Regardless, it's rather ridiculous trying to sugarcoat your bugs by criticizing the use case. Don't forget, your customer just did your job for you by spending the time to debug and create an easy-to-follow use case for you so you can fix it in no time. And you're obviously quite a grateful developer.

    Quote Originally Posted by evant View Post
    I think the simplest change is to just modify the regex in createAccessor to only match "[" or "." at the start of the string.
    Did you even read the source code? Clearly the source code went to the length to enable a hack like "myoptions.mykey" as expr (to create an accessor to 'obj'.myoptions.mykey), and your "solution" would break your own hack. If you think it doesn't matter if it's broken, then might as well replace createAccessor with simpleAccess.

  6. #6
    Sencha User Jamie Avins's Avatar
    Join Date
    Mar 2007
    Location
    Redwood City, California
    Posts
    3,661

    Default

    Please try to keep things calm. It's obviously just a case Evan didn't think of and wasn't taken into account. We're all human, we all make mistakes. We appreciate the report.

  7. #7
    Sencha Premium User evant's Avatar
    Join Date
    Apr 2007
    Location
    Sydney, Australia
    Posts
    19,250

    Default

    Perhaps I didn't make myself clear. When I was saying it's a strange use case, I was indicating that was why it probably wasn't considered. When was the last time you saw a database field called "*Mr. Smith". That generally tends to be data, not something that describes the data.

    Nonetheless, what I was suggesting was that only ".[" at the start of the string should be accepted for the regex matching, anything else would need to happen via a passed function for the mapping. I see a few options:

    1) Keep it as it is (obviously not desireable).
    2) What I suggested above
    3) Provide an option on the reader to allow/disallow anything other than the simple access method, once it has passed by the function checks.

    3 is probably the most flexible, because we would like to keep that functionality as it is quite useful.
    Twitter - @evantrimboli
    Former Sencha framework engineer, available for consulting.
    As of 2017-09-22 I am not employed by Sencha, all subsequent posts are my own and do not represent Sencha in any way.

  8. #8
    Sencha User Condor's Avatar
    Join Date
    Mar 2007
    Location
    The Netherlands
    Posts
    24,246

    Default

    Am I missing something here?

    The OP is using an ArrayStore, which shouldn't even be using JsonReader.buildExtractors or JsonReader.extractValues, because ArrayReader.readRecords has it's own implementation.
    The correct fix would be to implement buildExtractors and extractValues for ArrayReader, but since the whole thing is rewritten for Ext 4 anyway, temporarily setting buildExtractors and extractValues to Ext.emptyFn seems the correct fix.

    If the OP would be using a JsonReader, then he should specify a mapping, e.g. mapping:'["*Mr. Smith"]'.
    I'm not a fan of changing the createAccessor function as suggested, because it makes the method less flexible (I wrote it this way for a reason!).

  9. #9
    Sencha Premium User evant's Avatar
    Join Date
    Apr 2007
    Location
    Sydney, Australia
    Posts
    19,250

    Default

    @Condor: You're pretty much correct. As you and others have suggested, the ArrayReader can be pared down to a very minimal set of code, so we want to have something that will be "future compatible" (woah) going forward.
    Twitter - @evantrimboli
    Former Sencha framework engineer, available for consulting.
    As of 2017-09-22 I am not employed by Sencha, all subsequent posts are my own and do not represent Sencha in any way.

  10. #10
    Sencha User Animal's Avatar
    Join Date
    Mar 2007
    Location
    Bédoin/Nottingham
    Posts
    30,892

    Default

    In fact the correct fix for the OP, is to explicitly use an integer mapping value.

    Paste this into Firebug:

    Code:
    var store = new Ext.data.ArrayStore({
        fields: [{"name":"*Mr. Smith", mapping:0}],
        data: [['I am Smith']]
    });
    alert(store.getAt(0).get("*Mr. Smith"));

Page 1 of 3 123 LastLast

Similar Threads

  1. Bug in Ext.data.JsonReader?
    By mainmanmauricio in forum Ext 3.x: Help & Discussion
    Replies: 7
    Last Post: 22 Nov 2012, 3:35 AM
  2. Replies: 1
    Last Post: 18 Mar 2010, 12:44 PM
  3. [OPEN-58][3.0+] JsonReader with array data
    By Condor in forum Ext 3.x: Bugs
    Replies: 8
    Last Post: 20 Oct 2009, 2:43 AM
  4. [2.0] Firefox bug affects data.xmlReader
    By Gribnif in forum Ext 2.x: Bugs
    Replies: 0
    Last Post: 30 Jan 2008, 7:40 AM
  5. Ext.data.connection method is case sensitive (affects paged grid)
    By corey.gilmore in forum Ext 2.x: Help & Discussion
    Replies: 3
    Last Post: 4 Apr 2007, 2:51 PM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •