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!
Thanks
Mayura

3 Oct 2012, 2:44 AM

evant

No, MVC is not required. It's a nice pattern to follow, but you don't ~have~ to use it.

3 Oct 2012, 5:59 AM

skirtle

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

themightychris

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.

4 Oct 2012, 9:21 AM

Kyle2123

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

skirtle

@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.

4 Oct 2012, 11:41 AM

themightychris

Another big benefit to us of keeping logic out of views is it enables designers and developers to work in parallel. Designers will often need to tweak layout configurations or change container nesting, by using controllers and properly-specified componentqueries they can play around on their own without breaking any functionality.

@skirtle - if the developer in question was experienced with MVC, he would immediately look to the control section of the controller responsible for that section of the application. From there you can easily find the rest. We create 1 controller per major section of the application, usually corresponding closely to the application's primary models.

4 Oct 2012, 12:26 PM

Tim Toady

@Skirtle
While MVC isn't perfect, I have found it makes code much cleaner because of the structure it imposes. My controllers are usually 1 to 1 with views unless there are multiple views within the same section in which I would have them in the same subdirectory.

For example, here is the basic structure of a medium sized application I built that could easily scale:

I have an app that consists of a viewport, a left navigation, and a content area in the center that is a card layout. The content area changes based on the left navigation. Each card is its own view. If that card needs multiple components defined, I will put them all in the same subdirectory. My controllers look like this:

Viewport

Navigation

Content

Page1

Page2

Page3

Page4

...

My Views then look like this

Viewport

Navigation

Content

Page1

page2 - directory

Page2

UploadForm

Page3

Page4

...

Obviously this is somewhat specific to the way this application has its navigation set up, but it can easily be scaled to any number of pages and it would be clear where any handlers were found if the developer understands Ext. In this application, there are about 7 different cards (currently) and maybe half of them are further broken down into other views.

In your scenario with the save button, it would be easy to know where a button's logic would be in this application. The cards are all named as they appear in the navigation. Say one of my cards is named User Manager in the navigation. A developer would just find the UserManager controller and look at the this.control statement.

The only confusion with controllers that I find is with things like renderers or overriding methods for views. They can be done in the controller, but it's not very pretty. I have come to the conclusion that I should just put these types of things in the view. Fortunately, the majority of the time the only thing happening is event handling.

4 Oct 2012, 12:55 PM

fordprefect

I've written server-side MVC code for years (rails, asp.net mvc) and I jumped into MVC in extjs right away. I never want to go back to a non-mvc front-end. What I like about MVC is:

1. Clear distinction between presentation (views) and logic (controllers)
2. Everything is organized nicely
3. I don't have to go looking through views to find code, I just go to the correct controller and look up the action.

The MVC pattern is definitely not required but IMO it's the best way to write web apps. Of course YMMV.

4 Oct 2012, 1:07 PM

Tim Toady

I was a little hesitant to jump into MVC myself. I have another project I did around when Ext4 came out that is more complex that my previous example and I kept with the Ext3 style. There probably would be around 100 stores and 40 views/controllers. I think the way I architected it makes sense, but it would have really shined if I used MVC. Perhaps I will convert it to MVC in the future.