View Full Version : How to Structure Application

30 Oct 2009, 8:51 PM

How do most folks structure their application? I'm a bit confused on how to do this. One big js file doesn't seem that elegant. Most of the examples show how to use a widget, loagd a datagrid, etc but don't get into how to structure the code.

Is there any MVC style I could follow or does that design pattern not really fit.

Any thoughts or helpful links would be helpful.


30 Oct 2009, 10:10 PM
I thought about it for a while too, and decided to just roll with one file... I create START SECTION and END SECTION comment blocks for each major part of my app, and then when I am not working on sections, I can shrink them from the view with Dreamweaver. Works for me:)

31 Oct 2009, 3:43 AM
hmm not sure about using one file... that's going to be a nightmare for you to manage and debug

all i can suggest is use namespaces/classes wherever possible, reduce your code smells (replicated code) and mirror this in your server-side code, you'll benefit in the long term when it comes to debugging

Mike Robinson
2 Nov 2009, 7:57 AM
I take it that you have not yet stumbled-upon this series of articles in Saki's Blog (http://blog.extjs.eu/know-how/writing-a-big-application-in-ext/). ~o)

There is definitely a "right way" to do things in ExtJS ... to figure out what was really going through the architect's minds when they put the framework together, and to structure your apps to "go and do likewise." As you will see from the blog (and elsewhere), there seem to be several key ideas that show up time and time again:

It's an object-oriented framework that is designed to promote reusability through extension and delegating. It's designed to work with layouts, rendered in a viewport.
The xtype and ptype attributes allow objects to be 'registered' once and then called-upon by mention of their names. This is used to provide "lazy instantiation" of things, e.g. a window appears in memory in all its glory only when (and if) it is needed.
The ExtJS Inc. provided material is really a foundation upon which so-called "user extensions" ("ux"es) have been built by many other clever people. The framework is architected to provide for this.
You will experience a head-explosion, repeated many times, because the documentation is very hit-and-miss. It's written by people who know the framework well... perhaps too well. But, "Google is your friend," and so is this forum. No matter what you are doing, you will find here people who have trod the same path not long ago.

2 Nov 2009, 8:27 AM
the "module" pattern is going to be what I am going to write about in my next Ext JS in Action chapter. :)

2 Nov 2009, 1:03 PM
Thanks for the replies. I will check out that link you sent over for Saki's blog. It looks promising. The module pattern sounds interesting as well. When is the book going to be finished?

8 Mar 2011, 7:25 PM
I've read Saki's work and found it very informative. However, for newbs like myself, it's hard to take much away from it other than a conceptual understanding. I've looked through all the examples that come with the download and essentially the same thing. They're all built as single page applications. When I think of structuring my application I'm wanting to know more than building a one page application. I may have 50 pages or 100. Sure I can build components and load only what I need for the page I'm on. But where does something go that needs global scope to my application? Where's the best place to put these files and when/where to include them. I've looked and I haven't found any docs on best practices for this or an example. Most responses to this question seem to revert back to Saki's article about this. So, I've settled for simply "rolling my own". Not much else you can really do until someone with enough experience with Ext sits down and actually creates a decent example of what this might look like.

The way I came to my solution is I looked at the Desktop example and a few of the others. Essentially, in my master page I always load the required ExtJs files and a single Apps.js file that gets things going. Then I create individual js files for each of my pages and load only the js file I need for that particular page. So far it seems to work but there's a lot I don't understand about how the components and javascript files could potentially work together. Right now each page is simply a complete disconnected application much like the individual examples. I'm sure all this will evolve over time as I understand more about the framework.

Hopefully, this will give you some ideas about how to do what you're asking. I'd love to hear more thorough input from somebody that actually knows what they're doing and has done this before as it could help avoid any pitfalls that the ole trial and error will get me... I'm also just starting out and switched my focus on ExtJs 4 so I'm waiting for this to be released to really proceed with my app so my advice is really more of an observation rather than based on much work. Anyway, hope it helps.

8 Mar 2011, 9:46 PM
Since 2007 i started creating a folder per business entity lets say the domain model have Customers, Products, Invoices, etc., so basically you have to create a list (gridPanel to display the records), an edit form (to edit the a record) and a master page where you will have the navigation menu to call this pages, so in my firsts projects i started creating just one javascript per business entity like customer.js, and that file contained the grid and a form displayed inside an Ext.Window...

So the structure was something like following:

The javascript files are in the same folder that php files.

|_customer.php (include customer.js)
|_product.php (include product.js)
|_invoice.php (include invoice.js)

But, then when the projects required more features i realize i needed to separate the things a little because i wanted to reuse the forms and list and add another things, without making things more complex.

The "thing" that i said above is a page called by a LookupField right now is an extended combobox because in big projects comboboxes can costs to much in development. (But that is another topic)

So, now the structure looks like this:
|_edit.php (include edit.js)
|_list.php (include list.js)
|_lookup.php (include lookup.js)
|_list.php (include list.js)
|_edit.php (include edit.js)
|_lookup.php (include lookup.js)
|_list.php (include list.js)
|_edit.php (include edit.js)
|_lookup.php (include lookup.js)

The main reason why is better to have it separated is because when you're working on teams you're not blocking a file that someone else may needed at the same time to work in something that you are not modifying... and is easy to call a page to display a list not related to the current entity, form, or lookup list from every where and plug-in in other windows, and so things will be loading when they are needing.

Now the other thing that i have to do is to group those folders in a folder per module... lets say version 3

My simple advice is: Don't mix things too much (i use files that includes helper or overrides functions that i reuse in almost all javascripts files) when you will need to reuse apart, and use a convention name for almost everything that you can, and if you do it like this, don't panic when the numbers of folders grow to much (in my case 300) because that separation will save you a lot of time, and choose a structure that you will be confortable with...

Hope it helps!

9 Mar 2011, 3:54 AM
You could take a look at the pattern that I've been publishing, called the "in action" pattern. I talked about this at Sencha Con and have been successful with it from small to large projects.

take a look at the source files for http://app.extjsinaction.com The explanation to the code and the thought process behind it are in the last two chapters of my book.

9 Mar 2011, 4:49 AM

hey thanks for your thorough response. This is the kind of information that is extremely helpful when first starting out with ExtJs. I kinda had an idea that breaking everything up was the way to go but your example takes it farther than I imagined and makes a lot more sense. Thanks for taking the time to share this info!

9 Mar 2011, 5:02 AM
I'm glad that helped you!