15 Mar 2012 12:19 AM #1
"override" vs "extend" in build 311
"override" vs "extend" in build 311
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?
15 Mar 2012 6:54 AM #2Aaron Conran
Sencha Architect Development Team
17 Mar 2012 10:45 PM #3
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?
18 Mar 2012 10:58 AM #4
- Join Date
- May 2010
- Guatemala, Central America
- Vote Rating
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 2.x / ExtJS 4 MVC
Server side: EJB 3.1 / CDI / JPA 2 / JAX-RS / JasperReports
Application Server: Glassfish 3.1.x
Databases: Oracle 10g & 11g / DB2 9 & 10 / Firebird 2.5
If you like my answer please vote!
18 Mar 2012 10:23 PM #5
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.
19 Mar 2012 5:01 AM #6
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
19 Mar 2012 8:38 PM #7
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.
20 Mar 2012 8:32 AM #8
21 Mar 2012 10:03 PM #9
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 hope my words would come handy for someone who's as confused as I was.