CODEWITHSUNDEEP
model-view-controllerextjs4
Levi Hackwith
Levi Hackwith

Reputation: 9332

Sharing Models, Views, and Controllers Between ExtJS 4 Applications

Right now, I’m working on a legacy web application that is made up of multiple screens, each one performing a separate function. I’m in the process of converting several of the screens to EXTJS 4 using the MVC approach. In order to isolate the impact of my changes and because we don’t have time to convert the entire app at once, I’ve converted two of the screens into two separate EXTJS 4 apps. Each screen now has its own folder in which I’ve set up an app using the appropriate file structure and app.js file.

My question is this: as I continue developing, I may want to use models from one app (screen) in another app. How do you share models, views and controllers between applications? What’s the best approach?

FYI, I’m using autoloading to pull everything in.

Thanks

Upvotes: 1

Views: 2011

Answers (2)

Levi Hackwith
Levi Hackwith

Reputation: 9332

Here's what Saki said to me on the Sencha Forums:

The multiple applications on one page, or sub-applications of Ext MVC are not supported yet, however, developers are working on this functionality, AFAIK. Such implementation would most likely solve also the problem of re-using models, views and controllers among (sub) applications, I hope.

More specifically regarding linking multiple applications:

I would just soft-link files of MVC components is this case. There's no logical or functional connection among them now, only I wanna reuse already written file, right?

Upvotes: 1

Netzpirat
Netzpirat

Reputation: 5501

I would not use autoload in production, because it generates to many HTTP requests to get all files, which slows down the page load speed. This is well documented at Google's Page Speed and Yahoo's Best Practices for Speeding Up Your Web Site.

The best practice is to preprocess the resources upon deployment of the application and generate a single javascript file with everything in it that is sent in a single (GZIP) compressed response. There are several tools for this job, but it depends heavily on your toolchain. You can for example have a look a the SO question Best JavaScript compressor to get recommendations for various compressors (I use Jammit).

When you have a flexible configurable JavaScript compressor in your toolchain, you can set up a shared folder where you have your common files, like model, stores and some libs. These are now included in the builds for the different projects.

In case you have a good reason to serve single javascript files, you can either use a good version controll system like git and make use of submodules. Which this approach you'll have a separate repository for common files. This gives you the downside of slower page speed and a little overhead with updating the submodules.

As last solution, you can use a symbolic link on the file system to link the common folder to the different other projects.

Upvotes: 2

Related Questions