Is MVC really required?

My rule of thumb for putting code as overrides in a view is whether or not the code requires knowledge of the component's DOM elements so that controllers can stay focused on application logic and designers can tweak DOM manipulations, for example if the view used a custom template. I try to limit the view functions to overrides of template methods and the automagic config accessors (usually update*). If you need your controller to listen to events from any custom elements in your view, override the initEvents template method (be sure to callParent) to hook up mini listeners that translate page events to application events, e.g.:

Code:

---

config: {
        users: null
}
,tpl: '<tpl for="users"><a href="#{username}" class="user">{fullname}</a></tpl>'

,initEvents: function() {
        var me = this;
        me.callParent();
       
        // use delegate event on persistent common element instead of attaching to individual identical or transient elements
        me.el.on('click', function(ev, t) {
                ev.stopEvent();
                me.fireEvent('userClick', me, t.hash.substr(1), ev, t); // first param should always be the thing firing the event, then any meaningful information you can extract from ev or t, and finally all the original DOM event parameters
        }, me, {delegate: 'a.user'});
}

// override the autocreated empty updateUsers method, it gets called when your controller calls setUsers or passes in a users config when creating the component
,updateUsers: function(users) {
        this.update({users: users});
}

---

Quote:

---

Originally Posted by skirtle

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?

---

The key is that there is not a 1:1 relationship between views and controllers. What I do is have one controller per area of functionality. For example if I have functionality that lets you manage customer records - say, search for customers, edit an existing customer, add a new customer, etc., that might be handled by 5 or 10 different views. But all of those views work together to do the same thing -- give you a way to manage customer records. So I'd have a "customer controller", and in there I'd put the code related to handling these views. The views are just UI definition so if you read the view classes all you would see is a list of UI components - the only exception to this really is when I use templates, I usually put those in the views. And for the buttons in the views, I tag them with an "action" attribute so I can find them easily without relying on the text labels on the buttons directly since those can change. Each view that I create gets its own xtype too.

To your question about the save button and knowing where to look - in my example the developer would know what area of the system we are talking about - say, editing an existing customer record and saving it. So they'd look in the customer controller. In the event hooks at the top, there would be events that use the view xtype and the button action to define the path. like 'editcustview button[action=save]' : { click: onEditCustomerSave }. In reading that it would be pretty obvious where to go from there because your event path isnt just 'button' : { click: ... } - the path includes the view's xtype, the button, and the button's action.

Also, I personally stay away from using the 'refs' stuff in views because I often find that I need to support more than one instance of the same view. One controller can manage multiple instances of the same type of view. And the events generally pass a reference to the view as the first parameter. So if you have that, you can get whatever else you need from there using up(), down() etc.

Quick Points:

Extjs MVC gives,

1. Reusable components - No more thousand lines of files.
2. Logic at your controllers - Can understand application flow and any one can debug easily.
3. Everything is organized - Folder structure that makes our life easy. (even we can have sub-folder under view, controller, store..)
4. Easy Maintenance -When we need to add any new UI items to our existing view just modify corresponding view alone so that the controller part is still same and untouched. The same applies for Stores and Models changes.

We should be careful that there is no dependency for view based on controller logics. I mean the controller logic should direct us to the view with proper input rather than generating items for the view. The view in turn make use of the input from controller and creates, loads store to construct all items on its own.

It depends on how well we organize our app based on need. Extjs is a Gem to develop web app currently !

There are 3 things I don't leave my home without.

1. My license to drive.
2. My license to carry.
3. An MVC framework for whatever technology I am using.

Of course you don't "have" to use an MVC, but if I can't see myself doing anything larger than a toy application without it. Once your business logic, view logic and services hit a certain point, your code becomes a terribly large ball of mess without some type of order. Then soon changes that should only take an hour or two to implement take an entire day because you are unsure of the side effects of your code.

If you feel that MVC is unnecessary you may want to read up why its necessary.

I like ExtJS MVC.

I tend to stay away from itemId and id and opt instead for aliasing my views. For instance, a view classed as MyApp.view.admin.EditUser would be aliased as widget.adminEditUser. After this, I fire custom events and parameters from a given view component and bubble them up to and out of the top level component of the view. That way, I can either use the Ext.app.Controller.control() method through referencing the xtypes of the views or add listeners to the views as I instantiate them within the controller logic.

Since the view 'knows itself', the controller won't care about anything but the xtype of the view, the event name, and the parameters it expects (typically a model or some form data to save or manipulate.) The controller won't need to have any component queries that could break by changing the view's component layout or nesting or the text of a button.

In some part, though, I wonder if it wouldn't be easier to handle control logic within each view. I haven't yet been programming for a year, so I have a lot to figure out. ~o)

At least in the Flex world I would sometimes handle control logic in the view depending on how much work had to be done. This was usually accomplished through 'states'. So I would have an admin state and a user state ( not skin states ), the controller would then do something like "view.setAdminState(true/false)' and the view would take care of all the component hiding, showing, enabling and so forth. I did that mostly because it gets annoying to have your controller littered with addUserButton.enable=true, deleteUserButton.enable=true and so on.

Hi,
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.

Thanks all for the responses.

BTW we are going the MVC way!

In my experience MVC is a very good one while developing......but I just want to know what are the security issues regarding this...............

I think the Ext MVC pattern works okay, but it's not great.
Forcing controllers to use component query to wire up events means you can only do that for observable components, and have to wire up listeners by hand for other things.

Then there are some obvious holes; things that just don't fit, such as actions. We've taken the approach of putting actions into a sub-namespace under controllers, so something like Blah.controller.area.actions.Save, say.

If everyone knows what's going on though I believe everything is doable, and it should normally be obvious where the code for something is. If it's not you have to ask yourself if you're doing it right...