14 Feb 2012 6:56 AM #1
MVC app listing all views, stores and models is unmanageable
When reading source code for pre PR4 controller extensions, it was easy to determine what views, models, and stores a particular controller is to manage. That pattern worked well in the direction of the "Self documenting code" practice.
Moving views, models and stores to the application really goes against self documenting code as controllers often are specific to a certain view and/or model. I initially liked the idea of centralized configuration, but am now against it. Application definitions will become bloated and hard to manage/maintain for larger apps.
While thinking about MVC for ST2, please keep in mind that this code will most likely be used for Ext JS5, where tens of views, stores and models can pollute the application definition.
Just look @ the app.js for the kitchen sink demo. Imagine if there were an equal amount of models and stores listed there.
views: [ 'NestedList', 'List', 'SourceOverlay', 'Buttons', 'Forms', 'Icons', 'BottomTabs', 'Themes', 'Map', 'Overlays', 'Tabs', 'Toolbars', 'JSONP', 'YQL', 'Ajax', 'Video', 'Audio', 'NestedLoading', 'Carousel', 'TouchEvents', 'SlideLeft', 'SlideRight', 'SlideUp', 'SlideDown', 'CoverLeft', 'CoverRight', 'CoverUp', 'CoverDown', 'RevealLeft', 'RevealRight', 'RevealUp', 'RevealDown', 'Pop', 'Fade', 'Flip', 'Cube' ],
In this new model, I have to remember: What controller requires what models, stores and views? Did i get ALL of them in the app.js? This leads to potential pollution in production apps.
I'm sure the team has a really good reason for making this change. I just can't see it.
I would love to hear what the community thinks.
14 Feb 2012 7:02 AM #2
- Join Date
- Mar 2007
- Gainesville, FL
- Vote Rating
Since Ext.app.Application extends Ext.app.Controller, I would think it would be trivial to move these kinds of configs to the Controller and still have the Application use it. I'm not sure why the behavior was moved off of Controller, possibly a performance decision but I will open a ticket for this.
I'm not sure about the SenchaCon app but TouchForums has quite a few views and if I were to define them in the Application that array would be quite long also. However, most of the time I don't put views in the application, I use the requires property in the different views that require that view.Mitchell Simoens @LikelyMitch
Sencha Inc, Senior Software Engineer
Check out my GitHub, lots of nice things for Ext JS 4 and Sencha Touch 2
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 firstname.lastname@example.org
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.
14 Feb 2012 7:08 AM #3
Jay - totally agree with you and didn't like having to move all my views, models, and stores into the application. What if you have a controller that is used in 3 different applications? Now when you add a view to that controller, instead of adding it in one place (the controller) you have to add it to three applications. What if developer A is working on application A and didn't realize he just broke applications B and C?
The thing I like to do is keep my application dumb. I prefer to define controllers and a launch() function in the application and that's about it. I define a launch() method in a controller that I want to initially control the app.
14 Feb 2012 7:19 AM #4
I was surprised that in beta1 they moved it to a central place, but on the other side, the new routes config moved to the controller (as opposed to a central place as in ST1).
I don't have an opinion on both yet, though. I'll see with time how it feels/maintains.
Usually you have your views structured into namespaces, therefore a "views" array of a normal application would look a bit more organized than the kitchensink code example.
What I don't like in >= beta1 though is that if you use namespaces in views, you have to specify the complete namespace, e.g. "SomeApp.view.nested.View" instead of just "nested.View".
Also, I'm often on the fence if I specify a view in the app config or in the "requires" config option of the main views as Mitchell points out.
14 Feb 2012 7:20 AM #5
14 Feb 2012 7:22 AM #6
could you give me an example of where you'd use the same controller in 3 different applications?
14 Feb 2012 7:39 AM #7
14 Feb 2012 7:56 AM #8
+1 for this.
To me, having controllers define views, stores, & models bodes well for reusable modules. Also, as stated earlier, it makes our controllers more humanly readable.
14 Feb 2012 8:44 AM #9
Device Order App (workflow used by end user and CSR)
Device Activation App (workflow used by end user and CSR)
Account Maintenance App (used by end user and can also do Device Order and Device Activation workflows)
The workflows have controllers, views, stores, and models that are shared by all 3 applications. Each workflow has a "master" controller (DeviceOrderController and DeviceActivationController) and they communicate with the workflow controllers via events.
In addition to the 3 applications in the above product we also have other products which use these workflow controllers, views, etc. So this "workflow library" is used by several products and each product can have multiple applications within it.
14 Feb 2012 9:59 AM #10
I've moved this into Discussion as it's obviously not a bug. The imminent B3 release has a new guide on dependency philosophy that I'd like you to take a look at as it lays out the reasoning behind this change. Happy to hear other viewpoints of course.
Thread Participants: 17
- TommyMaintz (4 Posts)
- Jamie Avins (2 Posts)
- svenna (1 Post)
- soros (1 Post)
- mitchellsimoens (3 Posts)
- Steffen Hiller (9 Posts)
- stormin_walker (1 Post)
- themightychris (2 Posts)
- rdougan (1 Post)
- edspencer (6 Posts)
- ykey (1 Post)
- estesbubba (3 Posts)
- perfusorius (1 Post)
- aoathout (2 Posts)
- Zyphrax (1 Post)
- ryancanulla (1 Post)
- brian.moeskau (1 Post)