Gelmiş geçmiş en büyük porno sitemiz olan 2pe de her zaman en kaliteli pornoları sunmayı hedefledik. Diğer video sitemiz olan vuam da ise hd porno ağırlıklı çalışmalara başladık.

Hybrid View

  1. #1
    Ext JS Premium Member
    Join Date
    May 2009
    Posts
    41
    Vote Rating
    0
    maksimenko is on a distinguished road

      0  

    Default overriding / callParent behavior change (bug?)

    overriding / callParent behavior change (bug?)


    Hello there,

    When overriding a constructor in ExtJS 4.1, the overridden constructor gets called when this.callParent() (instead of on this.callOverriden()) is used on the new function.

    Code:
    Ext.override(Ext.data.Store, {
         constructor: function () {
               ...... 
               this.callParent(); // this calls the overridden Ext.data.Store constructor instead of the Ext.data.AbstractStore constructor
               ....
         }
    });
    Is this an intentional behavior change or an unnoticed bug?

    The problem with this behavior is that if I try to override a constructor to provide custom functionality or fix a bug, the overridden constructor with the undesired code is getting called too, thus giving unexpected results...

    Let me know if you need more info

  2. #2
    Sencha - Senior Forum Manager mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    36,519
    Vote Rating
    813
    mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute

      0  

    Default


    Have you tried callOverridden()?
    Mitchell Simoens @SenchaMitch
    Sencha Inc, Senior Forum Manager
    ________________
    Check out my GitHub, lots of nice things for Ext JS 4 and Sencha Touch 2
    https://github.com/mitchellsimoens

    Think my support is good? Get more personalized support via a support subscription. https://www.sencha.com/store/

    Need more help with your app? Hire Sencha Services services@sencha.com

    Want to learn Sencha Touch 2? Check out Sencha Touch in Action that is in print!

    When posting code, please use BBCode's CODE tags.

  3. #3
    Ext JS Premium Member
    Join Date
    May 2009
    Posts
    41
    Vote Rating
    0
    maksimenko is on a distinguished road

      0  

    Default


    Hello Mitchell,

    Maybe I didn't explain myself correctly.

    I don't want to call the overriden Ext.data.Store constructor, in fact, I expect it to not be called.

    The problem is that, now in the 4.1 branch, with the changes made to the callParent function code, the this.callParent() is calling the overriden constructor and I expect it not to do so, instead I expect it to call the Ext.data.AbstractStore constructor...

    Hope I explained myself better this time,

  4. #4
    Sencha - Ext JS Dev Team dongryphon's Avatar
    Join Date
    Jul 2009
    Posts
    1,293
    Vote Rating
    121
    dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all

      0  

    Default


    Yes, this was changed as part of the Ext.define/override functionality. I will add it to the API changes page. If you haven't seen this yet, you might find it useful:

    PHP Code:
        Ext.define('My.patch.Store', {
            
    override'Ext.data.Store',

            
    constructor: function () {
            }
        }); 
    The override can then be "required" and dynamically loaded or brought into an optimized build. If an override is required (say 'My.patch.*'), it won't actually be used unless the target class is also used.

    From a design perspective, overrides in 4.1 are almost like partial classes and will allow a single class to be implemented in multiple, independent pieces (rather than the problematic approach of "AbstractFoo" and "Foo" classes).

    Is this need very common in your overrides?

    To bypass the original method, in 4.1, you have to go old-school:

    PHP Code:
        constructor: function () {
            ... 
            
    Ext.data.AbstractStore.prototype.constructor.call(this);
            ...
        } 
    Don Griffin
    Ext JS Development Team Lead

    Check the docs. Learn how to (properly) report a framework issue and a Sencha Cmd issue

    "Use the source, Luke!"

  5. #5
    Sencha Premium Member skirtle's Avatar
    Join Date
    Oct 2010
    Location
    UK
    Posts
    3,472
    Vote Rating
    280
    skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future

      0  

    Default


    I only use overrides to patch bugs. It's pretty common to need to skip the buggy overridden method in such circumstances. Personally I always used the 'old-school' prototype approach when I was doing this anyway, relying on the callParent() magic always struck me as a bit risky when I'm subverting a class's original methods.

  6. #6
    Touch Premium Member
    Join Date
    Nov 2010
    Location
    Chicago
    Posts
    1,287
    Vote Rating
    109
    LesJ is a glorious beacon of light LesJ is a glorious beacon of light LesJ is a glorious beacon of light LesJ is a glorious beacon of light LesJ is a glorious beacon of light LesJ is a glorious beacon of light

      0  

    Default


    Quote Originally Posted by dongryphon View Post
    From a design perspective, overrides in 4.1 are almost like partial classes and will allow a single class to be implemented in multiple, independent pieces (rather than the problematic approach of "AbstractFoo" and "Foo" classes).

    Is this need very common in your overrides?
    Don, hi!

    I use the "AbstractFoo" and "Foo" approach. Can you explain (in more detail) why this approach is problematic and how I could use overrides in 4.1?

    Also, does it mean that classes such as AbstractComponent or AbstractContainer will be eliminated?

    I still don't understand why for example there is the AbstractComponent class... why not fold its content into the Component class?

  7. #7
    Sencha Premium Member skirtle's Avatar
    Join Date
    Oct 2010
    Location
    UK
    Posts
    3,472
    Vote Rating
    280
    skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future

      0  

    Default


    I believe AbstractComponent and AbstractContainer exist so that the code can be shared with Sencha Touch.

    If I've understood what Don said correctly, I believe these classes will disappear because the new style of overrides allow this code to be reused without the need for the abstract classes. They are still there in 4.1-pr1 though.

  8. #8
    Sencha - Ext JS Dev Team dongryphon's Avatar
    Join Date
    Jul 2009
    Posts
    1,293
    Vote Rating
    121
    dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all dongryphon is a name known to all

      0  

    Default


    @LesJ,

    The AbstractFoo/Foo approach can still be valid in many cases, don't get me wrong. Inheritance is still a Good Thing.

    AbstractElement/Element and AbstractComponent/Component, however, were really "artifacts of implementation" where we were trying to share code between Touch and Ext JS. An app should never create an AbstractElement or AbstractComponent and really nothing other than Element or Component should even derive from them. This is not really what inheritance is all about, but it was the only tool at hand at the time. The problem is that this rippled through everything, including the docs, forcing these details to be in front of everyone.

    It is possible that we will fold such things together in the future and maintain aliases for the old names. If we did this, the AbstractElement class would be renamed to Element and the current Element class would become an override.
    Don Griffin
    Ext JS Development Team Lead

    Check the docs. Learn how to (properly) report a framework issue and a Sencha Cmd issue

    "Use the source, Luke!"

  9. #9
    Ext JS Premium Member
    Join Date
    May 2009
    Posts
    41
    Vote Rating
    0
    maksimenko is on a distinguished road

      0  

    Default


    Hello Don,

    Thanks for your response.

    As skirtle do, I mostly use overrides to patch bugs, so, in those cases I'd like the overridden method not to be called.

    I've a few overrides in 4.0 and now I had to do a few for 4.1 so I could test the app ( and I've seen great perf. improvements in every browser... but still couldn't test on IE6 with a surface error )

    Anyway, now I understand the reasoning behind the change. And the workaround of using the old school way of calling the superclass method works fine, so it's OK.

    Thanks again for your response

  10. #10
    Ext JS Premium Member
    Join Date
    May 2009
    Posts
    41
    Vote Rating
    0
    maksimenko is on a distinguished road

      0  

    Default


    Hi all,

    Well, after testing some cases, I'm really not liking this new behavior in Ext.override('...', {...});, maybe I'm still missing something,

    For example, in 4.1, I have a few overrides like this one:

    Code:
    Ext.override('Ext.layout.container.Fit', {
        calculate: function (ownerContext) {
            var me = this,
                childItems = ownerContext.childItems,
                /* begin workaround */
                //length = childItems.length, 
                length = childItems !== undefined ? childItems.length : 0, 
                /* end workaround */
                targetSize = me.getContainerSize(ownerContext),
                contentSize = { width: 0, height: 0 },
                i;
    
    
            for (i = 0; i < length; ++i) {
                me.fitItem(ownerContext, childItems[i], targetSize, contentSize);
            }
    
    
            if (!ownerContext.setContentSize(contentSize.width, contentSize.height)) {
                me.done = false;
            }
        }
    });
    but when Ext.layout.Context.runLayout runs, it calls layout.calculate(ownerContext), and, for a fit layout, the original calculate function is called instead of the override and thus it's giving me:
    "Uncaught TypeError: Cannot read property 'length' of undefined"... (This error happens when there is a panel without child items, just using the html: property, I can report it in another post if it helps)

    I understand and see the value of being able to have partial definitions of classes (coming from a .net world where partial classes are used somewhat widely), but maybe using another name instead of override, and let override do what the name suggest...

    Thanks again