1. #1
    Sencha User
    Join Date
    Jan 2012
    Posts
    71
    Vote Rating
    2
    mehran is on a distinguished road

      0  

    Default "override" vs "extend" in build 311

    "override" vs "extend" in build 311


    Hi,

    I wonder why in build 311 the user classes override the designer classes instead of extending them? Would someone please tell me what changes this will impose on the developers?

    Thanks

  2. #2
    Sencha - Architect Dev Team aconran's Avatar
    Join Date
    Mar 2007
    Posts
    9,080
    Vote Rating
    113
    aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold

      0  

    Default


    In detail discussion of the changes:

    http://www.sencha.com/forum/showthre...g-Build-gt-298
    Aaron Conran
    @aconran
    Sencha Architect Development Team

  3. #3
    Sencha User
    Join Date
    Jan 2012
    Posts
    71
    Vote Rating
    2
    mehran is on a distinguished road

      0  

    Default


    Even though I've already read that thread, I read it again. But yet I don't see a comparison between two paradigms. I don't see why did you switched from "extend" to "override" and I don't see how this transition affects me!
    All I know is that before this transition, any attempt to use a component results in instantiating a user class. This way any customized functionality provided by the user class was available to all since no instantiation of designer class would ever exists. The new paradigm does not enforce this and thus I don't know how the overridden user classes are going to be used!
    For example, I promoted a child component to a class. Then I added some new functionality by overriding it. Finally I deployed it and opened it in a browser. The result was unexpected. The promoted child component was instantiated from the designer class (instead of the overridden class) and thus had none of the new functionality.
    Am I missing something here or there's a problem with your design?

  4. #4
    Sencha Premium Member
    Join Date
    May 2010
    Location
    Guatemala, Central America
    Posts
    1,261
    Vote Rating
    79
    ssamayoa is a jewel in the rough ssamayoa is a jewel in the rough ssamayoa is a jewel in the rough ssamayoa is a jewel in the rough

      0  

    Default


    Quote Originally Posted by mehran View Post
    For example, I promoted a child component to a class. Then I added some new functionality by overriding it. Finally I deployed it and opened it in a browser. The result was unexpected. The promoted child component was instantiated from the designer class (instead of the overridden class) and thus had none of the new functionality.
    It seems that you bumped with a bug I heard about some time: Overrides are processed after apllication's launch.

    Overriden classes works for me so if aren't for you may be is because you use them in the main view and I'm not.

    Is the case? I mean, do you use overriden classes in the main view?

    Regards.
    UI: Sencha Architect 3.x / ExtJS 4 & 5
    Server side: JEE / EJB 3.x / CDI / JPA 2.x/ JAX-RS / JasperReports
    Application Server: Glassfish / WildFly
    Databases: Oracle / DB2 / MySQL / Firebird

    If you like my answer please vote!

  5. #5
    Sencha User
    Join Date
    Jan 2012
    Posts
    71
    Vote Rating
    2
    mehran is on a distinguished road

      0  

    Default


    I'm not sure what do you mean by "main view". As far as I know, overridden classes are never used by the designer itself. Which means either they are loaded by developer explicitly or they are never used. In other words, regretfully they seem useless to me. I believe the previous inheritance design was much more solid. As I said before maybe I'm missing something here! I hope someone proves me wrong and shows me the correct way to use the new design so I can get back to work.

  6. #6
    Sencha Premium Member
    Join Date
    Mar 2008
    Posts
    92
    Vote Rating
    1
    kveeiv is on a distinguished road

      0  

    Default


    The way the overrides seem to flow for me is:
    - There is a class definition for the override class which has a requires[] statement for the base class.
    - The override class Ext.define (http://docs.sencha.com/touch/2-0/#!/...-method-define) implements the createdFn, which would happen after the Ext.define of the main class due to that requires[], and which does an Ext.override on the base class, guaranteeing the existence of the base class before executing.
    - This means that as long as that override class gets included, all objects ever created will be the base class, and the override class is essentially just created to inject itself in to the process.
    - In your auto-generated designer.js file, you should see the override class in the requires[] config for the call to Ext.application(), this should make it one of the first things included, well before any launching() happens.

    If this is not what you see during the execution cycle, I think the Sencha folks will need more details or to see your project. There are still a lot of things you can't do directly from within the UI that can still/only be completed by overrides, which allows the vast majority of my large application to be built from within the designer. If there is an execution flow that is breaking from the one listed above, I'd love for them to know about it before it has an impact on me

  7. #7
    Sencha User
    Join Date
    Feb 2012
    Posts
    117
    Vote Rating
    11
    Sottilde will become famous soon enough

      0  

    Default


    I had a custom requires[] statement in my Application that I used in Build 298. In Build 311, there is an autogenerated requires[] statement that (unfortunately) cannot be added to. My custom statement was causing overrides to failure until it was removed. If you have one, remove it and overrides should function correctly.

  8. #8
    Sencha - Architect Dev Team aconran's Avatar
    Join Date
    Mar 2007
    Posts
    9,080
    Vote Rating
    113
    aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold aconran is a splendid one to behold

      0  

    Default


    Quote Originally Posted by Sottilde View Post
    there is an autogenerated requires[] statement that (unfortunately) cannot be added to.
    This is currently true, but we aware of that limitation and will be looking to address it.
    Aaron Conran
    @aconran
    Sencha Architect Development Team

  9. #9
    Sencha User
    Join Date
    Jan 2012
    Posts
    71
    Vote Rating
    2
    mehran is on a distinguished road

      0  

    Default


    Finally I managed to get a hang of the new design, thanks to everyone. Now I believe the new design is an improvement over the previous one in all of the ways except one. And that would be an explicit mandatory "require" of the overridden class. And I believe that could be easily left to the developer.
    I had a hard time understanding the new design because I was trying to understand it by matching it to a classic design. But since we are coding in Javascript, we can manipulate a class (object) long after it is defined, and that's what exactly the "override" pattern does. The overridden class tries to manipulate the designer class in place! That's why we never make an object of the overridden class.
    I hope my words would come handy for someone who's as confused as I was.

    Thanks again,
    Mehran