You found a bug! We've classified it as a bug in our system. We encourage you to continue the discussion and to find an acceptable workaround while we work on a permanent fix.
  1. #271
    Ext JS Premium Member SebTardif's Avatar
    Join Date
    Feb 2011
    Location
    Cambridge, MA
    Posts
    309
    Vote Rating
    9
    SebTardif will become famous soon enough

      0  

    Default Any update needed to the migration pack when using the 4.1 release of Ext JS ?

    Any update needed to the migration pack when using the 4.1 release of Ext JS ?


    It looks like the migration pack was not updated for a while, and so is the same after 4.1 was released.

    Does anyone had problems using the old migration pack with Ext JS 4.1?

  2. #272
    Sencha Premium Member danguba's Avatar
    Join Date
    Feb 2009
    Location
    Kragujevac, Serbia
    Posts
    365
    Vote Rating
    5
    danguba is on a distinguished road

      0  

    Default


    If you are referring to compatibility pack I tried it with 4.1 a day or two ago. I haven't migrated the whole app but it looks like everything works fine for now. Had a minor problem with stores and grids but nothing that could not be solved. I do remember I had to override couple of methods just to get things started but I think that compatibility pack is decent enough to start migrating.
    All Best
    ---
    Željko Mitrović
    http://skitanja.blogspot.com/

    "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." Martin Golding

  3. #273
    Ext JS Premium Member SebTardif's Avatar
    Join Date
    Feb 2011
    Location
    Cambridge, MA
    Posts
    309
    Vote Rating
    9
    SebTardif will become famous soon enough

      0  

    Default


    1- toolbar.insertButton is not aliased, see http://docs.sencha.com/ext-js/3-4/#!...d-insertButton but calling "insert" instead does work with the same old parameter.

    2- Ext.lib.Ajax.defaultHeaders is not aliased, but Ext.Ajax.defaultHeaders does work.

    3- I get false warning about Ext.KeyMap. The code to detect looks very awful and so, of course, doesn't work. The last expression is very pessimist and in my case return a Menu and so it doesn't match string "Ext.util.KeyMap" and then generate a false positive. See like 144 of ext3-compat.js:

    if(arguments.callee.caller.caller.caller.toString().indexOf("Ext.KeyMap")
    != -1 ||
    arguments.callee.caller.caller.caller.caller.caller.arguments[0] !=
    "Ext.util.KeyMap") {

    4- Compatibility pack has false positive error with Store constructor. This one is the most annoying. The code of Store and AbstractStore constructor use configuration like (model,fields)that is set to "this" or to the "config", whatever is it. My code, set it to "this" and doesn't bother to pass a config to constructor of Store or AbstractStore, then the conversion code intercept call to AbstractStore and somehow understand that model could be in "this" or "config" but just assume fields will be in "config:, see code:

    else if (!this.model && !config.model){
    ...
    if (config.fields) {
    // shorthand store classes like ArrayStore and XmlStore support fields directly on the store config
    fields = config.fields;
    delete config.fields;
    // this is required to be done, but skip the warning. In some cases TreeStore internally adds this. The bigger picture
    // issue of configuring the store correctly will already be covered by other warnings.
    // deprecate({pkg:'Ext.data.Store', msg:'Passing a "fields" config directly on the store\'s config is no longer supported. '+
    // 'Instead you should configure a model and pass it as the store\'s "model" config. ' +
    // 'Please see the header docs for Ext.data.Store for details on properly setting up your data components.'});
    } else {...}

    End-up with error: [BREAKING][4.0][Ext.data.Store]: A store was specified with no model, url, or fields configured. Please see the header docs for Ext.data.Store for details on properly setting up your data components. This is a breaking change that cannot be resolved in the compatibility layer!

    5- xtype: 'tbbutton' is not handled. After a text search I found a file in the Ext JS 4.1 Release src folder src\toolbar\Toolbar-legacy.js that seems to handle that outside the migration code. I don't believe this file is ever mentioned in the migration guide and anyway should be handled by the migration code.

    6 - In Ext JS 4.1 compared to 3.4, Field convert method is called even if the field is not included in the JSON. The default passed in will be empty String is no default was explicitly specified. Our code stopped to work because of this, our convert functions were only expecting data, not empty string.

    7 - Support for Editing grid using old syntax is very limited, it doesn't support that your grid has initComponent function. The logic rewrite the class hierarchy bypassing anything not in config, see:
    Code:
    Ext.grid.EditorGridPanel = function(config) {
    deprecate({pkg:'Ext.grid.EditorGridPanel', msg:'EditorGridPanel no longer exists as a separate class. Instead just '+ 'create a standard GridPanel and include the CellEditing plugin, e.g. "plugins: Ext.create("Ext.grid.plugin.CellEditing", {...})'});
    return Ext.createWidget('grid', Ext.apply(config || {}, {
    plugins: Ext.create('Ext.grid.plugin.CellEditing', {clicksToEdit: 1
    })
    }));
    }
    8 - Ext.util.TextMetrics.createInstance(...) is not aliased to new Ext.util.TextMetrics(...)

    9 - Inside BasicForm "this.items" doesn't work anymore, but "this.getFields()" does

    10 - Doesn't handle setting columns of grid in initComponent, like: this.colModel = new Ext.grid.ColumnModel.... That will break on some migration library code assuming this.column exist.

    11 - Store.root is not working if it's nested so with dot(s), like [root: 'message.body'] will not work, due to the too basic conversion done in the migration code provided by Sencha:
    Code:
    loadData:function (records) {
    if (Ext.isObject(records)) {
    deprecate({pkg:"Ext.data.AbstractStore", member:"loadData", msg:"Passing loadData an object is no longer supported. Now just pass the array"});
    records = records[this.proxy.root||this.root||"rows"];
    }
    oldLoadData.apply(this, arguments);
    }
    12 - http://docs.sencha.com/ext-js/3-4/#!...e-method-getUI is not aliased and doesn't exist anymore. Same thing with toggleCheck, instead you can use node.set('checked', false);

    13- Combobox setValue method in Ext JS 4.1 also accept a Model/Record, it doesn't expect that in Ext JS 3.4, so we had issue with this.

    14- Selection model class names changed and it's not aliased.

    15- form field without a 'name' will use the 'id' instead of 'hiddenName' like it was in Ext JS 3.4, the converter do not detect that.

    16 - In Ext JS 3.4 FieldSet extends Panel but not anymore in 4.1, so any code assuming tbar will be handled break silently. Converter framework ignore the issue.

    17 - Store constructor in Ext JS 3.4 will call the reader so that field "mapping" is used. But in Ext JS 4.1 the constructor has an hardcoded if statement that will only call the proxy if it's a memory proxy, the end result is that "mapping" is not respected anymore. I think Sencha code was smelling bad before I even find the issue, because polymorphism is broken by specifying a concrete class like proxy.Memory. In any case, the code should be about reader not about proxy. Of course, when you receive data in a constructor the proxy is not needed anymore, it's all about reader, so the constructor should use the reader assigned to any kind of proxy, or allow to pass in the constructor the reader to use.

    Extract from Store.js:
    Code:
     if (data) {
                if (proxy instanceof Ext.data.proxy.Memory) {
                    proxy.data = data;
                    me.read();
                } else {
                    me.add.apply(me, [data]);
                }
    18- Ext.util.Observable.purgeListeners() doesn't exist anymore, but clearListeners() works. The aliasing was not done for this.

    19- Column renderer event has a different scope in Ext JS 4.1, it's the grid instead of the column. Since the renderer has now for last parameter the view, it seems that changing the scope is a mistake because it's lot harder to find back the column than using the view parameter to get the grid.

    20- Column render do not support anymore listener syntax like the following. So the end result is that it's harder to pass scope, also existing code has no warning, or error, the renderer is ignored. You are losing functionality when upgrading from Ext JS 3.4 to 4.1, I don't see why Sencha didn't reuse listener logic to support same syntax than before:
    Code:
    renderer: {
                                fn: function(value){
                                    var fullName = Ext.ux.renderer.UserRenderer(value.id);
                                    return Ext.ux.renderer.QtipRenderer(fullName);
                                },
                                scope: this
                            }
    21- The aliasing of Ext.util.JSON is wrongly coded, the decode will replace the encode. Since most application do not often encode, it seems to work.
    Code:
    if (Ext.JSON) {
            Ext.util.JSON = {};
            for(var key in Ext.JSON)    {
                var value = Ext.JSON[key];
                
                if(typeof(value) == "function") {
                    Ext.util.JSON[key] = function() {
                        deprecate({pkg:"Ext.util.JSON", member:key,
                            msg:"Use Ext.JSON." + key + " instead. Automatically fixing."});
                            
                        return value.apply(Ext.JSON, arguments);
                    };
                }
            }
        }
    22 - proxy.conn.url is not aliased automatically to proxy.url, also store.setBaseParam doesn't exist anymore but setExtraParam does work.

    23 - store.query api doesn't exist anymore even if all the code that was used in the body of the method in Ext JS 3.x still exist in some private method. So you now have to write more code using store.queryBy. The conversion layer do not do any warning, aliasing or whatever.

    24 - AbstractContainer.findById doesn't exist anymore, and the migration code is buggy so that when nothing is found instead of returning null like before, it returns an empty array. So our code checking for null is silently broken.
    Code:
    findById: function(id) {
                    deprecate({pkg:'Ext.Container', member:'findById', alt:'query', msg:'Use the query method with the # id syntax, e.g. comp.query("#"+id).'});
                    return this.query('#'+id);
                }
    25 - ext-all-dev.js doesn't work with the conversion framework provided by Sencha. The community already made the case that having *-dev.js files is a mistake, that instead the extra functionality should be in the debug version. This is another justifications.

    26 - Ext.MessageBox.getDialog() doesn't exist anymore and it's not aliased

    27 - findParentByType with class find nothing because the "real" class have changed of name. The conversion framework could do some aliasing.

    28 - treepanel.dataUrl doesn't exist anymore. The conversion layer try to handle and show a warning but it's not quite right. It's now using get instead of post so that's failing on the server.
    Last edited by SebTardif; 1 Jun 2012 at 6:17 AM. Reason: more bugs

  4. #274
    Sencha - Community Support Team mschwartz's Avatar
    Join Date
    Nov 2008
    Location
    San Diego, Peoples' Republic of California
    Posts
    2,053
    Vote Rating
    17
    mschwartz will become famous soon enough mschwartz will become famous soon enough

      0  

    Default


    Quote Originally Posted by brookd View Post
    Can we get an answer to this question and mine? How long will 3.4 or "pre 4.0" code base be supported?? I wish I could upgrade, but as you know 4.0, its not exactly backwards compatible. Something thats already cost me tens of thousands of dollars. Thanks for that!
    I am watching our 3.4 project deteriorate before my eyes. First it was double click on a grid row -> open tab in tab panel leaves everything in the whole browser selected, now the grids are failing.

    After we've spent tens of thousands of dollars developing and supporting this application, a port to 4.1 is an enormous task. And even if we did port to 4.1, 5.x will come out and leave our 4.1 version obsolete.

    After seeing how we've been left in the dust by Sencha, how can I recommend we use it for any core applications? We'll continue to use Sencha products where appropriate, but we won't expect a lifetime beyond a couple or three years anymore.

  5. #275
    Sencha - Community Support Team mschwartz's Avatar
    Join Date
    Nov 2008
    Location
    San Diego, Peoples' Republic of California
    Posts
    2,053
    Vote Rating
    17
    mschwartz will become famous soon enough mschwartz will become famous soon enough

      0  

    Default


    Quote Originally Posted by rich02818 View Post
    I assume that you mean that in 4.1 these problems occur, or are they beginning to occur in 3.4?
    What I mean is the browser developers release new browsers with slightly different behaviors. Ext 3.4 hasn't been touched by Sencha engineers in over a year, so any new browser release may introduce buggy behavior in existing 3.4 applications. The 3.4 code has browser detection and special case logic to handle the oddities of the various browsers, but that detection and oddities handling only works with browser versions over a year old.

    So google comes out with new versions of Chrome and dblclick selects all the elements in the browser now. If Sencha were supporting 3.4, there'd be a fix applied and a 3.4.x or 3.5.x version released.

    I notice today that grids now render with a horizontal scrollbar and the columns on the right edge don't render proper. There's ellipses (...) rendering past the right column into the reserved area for the vertical scrollbars (should they appear).

    As far as I'm concerned, I created an ExtJS application. Sencha has turned it into a deprecated legacy application.

  6. #276
    Ext JS Premium Member
    Join Date
    Apr 2008
    Posts
    352
    Vote Rating
    14
    rich02818 is on a distinguished road

      0  

    Default


    Quote Originally Posted by mschwartz View Post
    What I mean is the browser developers release new browsers with slightly different behaviors. Ext 3.4 hasn't been touched by Sencha engineers in over a year, so any new browser release may introduce buggy behavior in existing 3.4 applications. The 3.4 code has browser detection and special case logic to handle the oddities of the various browsers, but that detection and oddities handling only works with browser versions over a year old.

    So google comes out with new versions of Chrome and dblclick selects all the elements in the browser now. If Sencha were supporting 3.4, there'd be a fix applied and a 3.4.x or 3.5.x version released.

    I notice today that grids now render with a horizontal scrollbar and the columns on the right edge don't render proper. There's ellipses (...) rendering past the right column into the reserved area for the vertical scrollbars (should they appear).

    As far as I'm concerned, I created an ExtJS application. Sencha has turned it into a deprecated legacy application.
    So those are new 3.4 bugs and need to be reported as such. We must try to hold Sencha's feet to the fire to fix these as they've promised!

  7. #277
    Ext JS Premium Member SebTardif's Avatar
    Join Date
    Feb 2011
    Location
    Cambridge, MA
    Posts
    309
    Vote Rating
    9
    SebTardif will become famous soon enough

      0  

    Default


    Quote Originally Posted by mschwartz View Post
    What I mean is the browser developers release new browsers with slightly different behaviors. Ext 3.4 hasn't been touched by Sencha engineers in over a year, so any new browser release may introduce buggy behavior in existing 3.4 applications.
    At least IE provide backward compatibility settings via X-UA-Compatible. Any professional web site should lock the version of their application to the latest IE they support.

    I don't think anyone expect 3.x will have new feature, it was upgraded to support IE 9. And Sencha announced the following at http://www.sencha.com/blog/ext-js-4-1-final-released/:

    We want to take this moment to reiterate our commitment to our customers on various versions of Ext JS. We blogged about extending support of Ext JS 3 for 12 months beyond the next major release after Ext JS 4, and support subscribers will continue to receive patch updates for Ext JS 3.4.x, including support for IE 10.
    Sencha product is cheap, if you didn't open a ticket to get your bug resolved you are shooting your feet.

  8. #278
    Sencha User
    Join Date
    Jun 2008
    Posts
    138
    Vote Rating
    7
    jchau is an unknown quantity at this point

      0  

    Default


    Sencha should really do a case study of someone migrating a large, enterprise 3.x app to 4.x . I have spent almost 2 weeks upgrading our app and I feel like I am rewriting the whole thing. If we have to do this again for every release, it's going to be tough to convince our management to keep spending resources on this framework.

  9. #279
    Sencha Premium Member
    Join Date
    May 2009
    Posts
    157
    Vote Rating
    9
    ZachG will become famous soon enough

      0  

    Default


    We have around 5 enterprise applications we actively develop. We only converted one completely to ExtJS 4. For the others, any new code that can be is written in 4 and displayed in an iframe. It's allowed us to take advantage of the SVG charts and new features without having to rewrite everything.

  10. #280
    Sencha User
    Join Date
    Dec 2012
    Posts
    1
    Vote Rating
    0
    usha.basavaraju is on a distinguished road

      0  

    Default migration from ext2 to ext4js

    migration from ext2 to ext4js


    Trying to migrate from ext2 to ext4.
    Used compatability file also.But still getting this error
    Error: [Ext.extend] Attempting to extend from a class which has not been loaded on the page.
    javascript//ext-4.1.1a/ext-all-debug.js
    Line 4391

    Please help..

Similar Threads

  1. Migration to 3.0
    By tillda in forum Community Discussion
    Replies: 5
    Last Post: 17 Aug 2009, 7:19 AM
  2. Migration to 2.0
    By scaswell1 in forum Ext GWT: Help & Discussion (1.x)
    Replies: 1
    Last Post: 7 Jul 2009, 9:56 PM
  3. migration 1.0 to 3.0
    By alien3d in forum Ext 3.x: Help & Discussion
    Replies: 2
    Last Post: 1 Jun 2009, 5:38 AM
  4. Migration GXT 1.2.4 to 2.0
    By G.edwin in forum Ext GWT: Help & Discussion (1.x)
    Replies: 2
    Last Post: 15 May 2009, 6:26 AM

Thread Participants: 110

  1. aconran (1 Post)
  2. mystix (1 Post)
  3. ap (2 Posts)
  4. evant (1 Post)
  5. ethraza (1 Post)
  6. steffenk (5 Posts)
  7. brookd (4 Posts)
  8. dherbolt (2 Posts)
  9. tore.kjorsvik (1 Post)
  10. wm003 (2 Posts)
  11. stevil (4 Posts)
  12. vlads (3 Posts)
  13. paubach (1 Post)
  14. BuckBazooka (1 Post)
  15. dbraiden (1 Post)
  16. mjhaston (1 Post)
  17. demon222 (1 Post)
  18. SToto98 (1 Post)
  19. rebe (1 Post)
  20. zombeerose (6 Posts)
  21. rich02818 (3 Posts)
  22. sg707 (3 Posts)
  23. vpopa (1 Post)
  24. hschaefer123 (3 Posts)
  25. jchau (1 Post)
  26. chrisvensko (1 Post)
  27. DannyMeister (3 Posts)
  28. dajester2008 (1 Post)
  29. mschwartz (4 Posts)
  30. wgpubs (4 Posts)
  31. LisburnLad (2 Posts)
  32. edspencer (3 Posts)
  33. firefoxSafari (9 Posts)
  34. Luckyman (3 Posts)
  35. oniram88 (1 Post)
  36. danguba (7 Posts)
  37. cnesbit (2 Posts)
  38. Jangla (1 Post)
  39. MuadDib-DK (1 Post)
  40. abctenorio@gmail.com (1 Post)
  41. uzver (3 Posts)
  42. zhangt (2 Posts)
  43. peet (3 Posts)
  44. ZachG (3 Posts)
  45. yyogev (7 Posts)
  46. pcr (4 Posts)
  47. 大漠穷秋 (1 Post)
  48. jacurry (4 Posts)
  49. excyberlabber (6 Posts)
  50. dongryphon (3 Posts)
  51. Henrik Rutzou (1 Post)
  52. hazimdikenli (1 Post)
  53. paparent85 (1 Post)
  54. Ekambos (3 Posts)
  55. burnie (1 Post)
  56. aaronbartell (1 Post)
  57. mattgoldspink (1 Post)
  58. dbrin (1 Post)
  59. CraigMyers (1 Post)
  60. Francois Lecroart (5 Posts)
  61. BulletzBill (1 Post)
  62. tumbochka (1 Post)
  63. a.l (2 Posts)
  64. c.darmon (8 Posts)
  65. Dipish (1 Post)
  66. blex2010 (2 Posts)
  67. kpalser (1 Post)
  68. ldonofrio (2 Posts)
  69. DHainzl (6 Posts)
  70. MrSparks (2 Posts)
  71. rebeccapeltz (1 Post)
  72. Jeremy Solarz (1 Post)
  73. RLBruggers (2 Posts)
  74. Ourysso (1 Post)
  75. jjohnston (1 Post)
  76. ShaneMc (9 Posts)
  77. msmolyak (1 Post)
  78. watermark (1 Post)
  79. lukefowell89 (3 Posts)
  80. winkelmann (1 Post)
  81. willjohnathan (1 Post)
  82. cayenne_08 (1 Post)
  83. SebTardif (3 Posts)
  84. mberrie (3 Posts)
  85. rijkvanwel (1 Post)
  86. george4voc (1 Post)
  87. Jehu (2 Posts)
  88. freeranger (4 Posts)
  89. Inoc (1 Post)
  90. eCoast (1 Post)
  91. dstarr@allofe.com (3 Posts)
  92. bee (2 Posts)
  93. /mbr (3 Posts)
  94. ptraczynski (1 Post)
  95. qqjianyue (1 Post)
  96. jmf10024 (1 Post)
  97. Reggae (2 Posts)
  98. wimh (1 Post)
  99. jas88 (1 Post)
  100. Roho (1 Post)
  101. lokisapocalypse (1 Post)
  102. ovillemain (1 Post)
  103. Flashmattic (2 Posts)
  104. testnina123 (1 Post)
  105. jlimaye (2 Posts)
  106. rivanov (1 Post)
  107. usha.basavaraju (1 Post)
  108. rageshp_moxie (2 Posts)
  109. er_abhisinha (1 Post)
  110. darkwata (2 Posts)