View Poll Results: Are you using MVC part of ExtJS4 in your application?
- 60. You may not vote on this poll
3 Oct 2012 2:38 AM #1
Is MVC really required?
We have a pretty complex application to be built. Planning to use EXTJS4. I have a team who is well
versed with coding EXTJS3 style. We are researching on MVC feature of EXTJS4 and whether to go that way or not. Want to add that we will have really complex layouts and pages. Going through first MVC article I feel that MVC will needlessly make everything more complex.
Really need inputs from ppl who have built huge applications using MVC feature of EXTJS4.
Please help guys!
3 Oct 2012 2:44 AM #2
- Join Date
- Apr 2007
- Sydney, Australia
- Vote Rating
No, MVC is not required. It's a nice pattern to follow, but you don't ~have~ to use it.Evan Trimboli
Twitter - @evantrimboli
Don't be afraid of the source code!
3 Oct 2012 5:59 AM #3
A major problem I have with the MVC is that the controllers are too 'magic'. It's fine for the developer who wrote the code originally but for all the other people who have to maintain it thereafter it can be incredibly painful trying to figure out where code lives. Having the 'controller' code inside the views may be considered less good practice but it's an awful lot easier to understand.
Perhaps having good conventions for organising code into controllers could overcome the 'dude, where's my code?' syndrome but I'm yet to see a large app where this has been done effectively.
Several parts of the ExtJS MVC also seem geared towards pushing things into singletons (a nice way of saying global variables). That seems like a step in the wrong direction to me.
I think the directory structure that the MVC encourages is well worth using though. Proper separation of M & V also works well in my opinion, I use models to represent all sorts of things that I never would have attempted using ExtJS 3's records. It's just the C I'm unconvinced about. I'm yet to see a large app where it works well or a decent explanation of how to use controllers in a real application. All the examples I've seen are just too simple and don't scale to large applications.
My current approach is to use controllers only where they save me a lot of effort compared to the alternatives. They can be useful but I've moved away from making them the core of my applications.
4 Oct 2012 8:45 AM #4
Skirtle is right that MVC can make it less obvious where code is, but this is only a problem for people with no ExtJS experience. Between developers that are familiar with ExtJS4's MVC it has the exact opposite effect.
I've used the ExtJS4 MVC since its release on many complex applications and it has been a huge booster to my team's development efficiency. My team has many developers and the MVC structure makes it easy to move between projects with minimal friction.
Further, by not creating our own ad-hoc structure for complex applications, we can leverage the Sencha docs and tutorials a lot better when training new developers. We've also both joined development on external projects built on the MVC and had external developers join our projects and the common language and structure provided by the MVC prevented a lot of wasted time learning new codebases.
While there are certainly a few things that could be improved about ExtJS's implementation, it gets the job done well and the fact that it's standardized and documented easily pays for the time to learn it.Chief Architect @ Jarv.us Innovations
Co-captain @ Code for Philly
Jarvus builds and optimizes top-quality Sencha Touch and ExtJS apps for open-source projects and clients of all sizes.
Don't waste time with bugs that have already been found and fixed by the community, compile our tried and tested hotfixes packages into all your projects: https://github.com/JarvusInnovations/sencha-hotfixes
4 Oct 2012 9:21 AM #5
We started developing on Ext with 4.0 and my experience is pretty much exactly the opposite. I feel like Ext's MVC architecture lets me know exactly where code belongs. If you have a bunch of logic in your views, you're doing it wrong. The view should essentially just be the layout of the components on your page. All of the logic that controls how the page works goes in your controller. If all of your logic is in the controller, it's easy to know where the code is. It would only be confusing if you are putting some of the logic in the controller, and some of the logic in the views, because then no one knows where the code is, and which file it really belongs in.
4 Oct 2012 10:22 AM #6
@themightychris & @Kyle2123. I've heard many people make claims similar to yours but I'm still yet to witness it first hand.
I don't expect you're able to share your applications publicly but perhaps you could help me by elaborating on the conventions you've adopted to keep things clear. I'll give a concrete example...
A bug report comes in saying that the 'Save' button is broken. A new developer is assigned the task of fixing it. More than likely, the first thing that developer will do is a quick search to find the text 'Save'. From that he finds half a dozen views and quickly establishes which one corresponds to the correct button.
In the non-MVC scenario the code to handle that button is very easy to find, it'll be referenced in the handler config.
In the MVC scenario there's no direct clue to where the click logic lives... so I assume he's relying on some sort of convention?
My question to you is what conventions do you have in place to make this work? How many controllers do you typically have, compared to the number of views? If some logic touches upon several different views then how would you decide which controller to put it in?
Keen to hear some real world experiences on turning the theory into practice. My own experiences have been largely bad, so I guess I've missed an important trick somewhere.
7 Oct 2012 9:00 PM #7
I need a help ....
when i run my app in pc the tab panel title names are not completed loaded,but wen i run it in ipad the title names are completly shown.Any idea why this is happening.
8 Oct 2012 1:24 AM #8
Thanks all for the responses.
BTW we are going the MVC way!