View Full Version : Should I move to using Extjs MVC features?

23 Apr 2013, 3:22 PM

Currently I have an ASP.NET MVC application that is utilizing the Extjs grid component on a couple of pages and then the window component. Up until now, we have simply separated the .js files by page and just referenced the corresponding .js file in the .aspx file and the component loads onready. We have not used viewports or ext.application or anything like this. Our extjs files are just single .js files with no MVC-separation.

However, I want to create a new custom component that extends the grid so that I can reuse it in two different places. This has led me to look into the MVC options for Extjs. I like the idea of building our extjs structure this way, however, I'm concerned that it may be overkill if we are only using a few of the components and we are not using Extjs to build the full app. Our pages are all .aspx pages that have many other items on them besides the one or two extjs components.

Can anyone give any suggestions? Is the MVC architecture the recommended way to go no matter what? Are there any resources that I can use to help me break this out into an MVC structure?

24 Apr 2013, 9:07 PM
The MVC pattern with ExtJS is a recommended option for applications and may be viable for your needs with the pages being aspx pages that include ExtJS widgets. That said, you have options.

If you're looking to make a re-usable grid component you can do the Ext.define() in a dedicated js file and then just load that file to your page / pages after the framework is loaded. Then in an onReady (or within a simple Ext.application()) you can do your Ext.create() to create an instance of your grid for that page.

Then if you decide to later move to building a larger ExtJS application you can have your common classes that you've created available to that application just as you would with your aspx page setup today. I'd recommend keeping them in a dedicated Common folder and just namespace them when you define them (i.e. call your grid class "Common.grid.MyGrid" and store it in a Common folder under sub-folder 'grid' with the filename MyGrid.js) and that will help with later just-in-time importing / application building should you move on to an ExtJS with MVC build.

25 Apr 2013, 12:22 AM
But be careful. ExtJs MVC has one big problem: multi instanced views. It isn't handled from ExtJs itself. So you need to write your own stuff to do it.

For example:

You have a tabpanel. There you will open two grids in different tabs. This grids are the same view, but have to display different data. But both will display the same data. It's because the store of the grids will be instanciated only once by the controller. But each grid would need it's own instance of the store.

I hope you see what I mean xD

DeftJs for example was written to fix this problem. It's some extra classes for ExtJs. =)

25 Apr 2013, 3:26 PM
When using the MVC pattern if you use a stores array config in the controller the framework will automatically create a convenience instance of the store with the ID being the last part of the store's class name (i.e. App.store.MyStore will automatically create a store instance with storeId of MyStore).

What you can do to circumvent the shared store issue is set an alias on the definition of the store like:
alias: 'store.mystore'.

Then when you instantiate the grid on your two panels you'll config the store like:

store: {
type: 'mystore'
// any other component specific store configs if any

Now your grids will have the same store type, but not the same store instance.

25 Apr 2013, 11:51 PM
Interesting... I build a "uniqueStore" config for this. Which will instantiate a new store everytime the view is instantiated. But this seems to be a good way too. Thanks for your information =)