Real world project structure with Sencha Architect

I am new to Sencha ExtJS and Architect MVC, but I know MVC and some other JQuery libraries in general.

I want to ask when building a real-world system, what is the proper approach to layout an Sencha app structure in Architect 2?

For example, we have the following departments in our app, they have distinct functionalities:

Accounting, Controlling, Quality Assurance, Customer Services, Human Resources, Logistics, Purchasing, Sales, Records Management ...

Approach 1: Write them in different Sencha Architect projects. Stitch up with master layout page + main area + header/footer + side bar pages. (using MVC.NET in our case)

--- Pros:

Multiple programmers can work on different sub-projects in an agile environment.
Each project is smaller and easier to be upgraded or replaced.

--- Cons:

We have different Sencha Architect projects for, e.g. main areas, side bar, header, footer. How do they collaborate with each other? We now only use JQuery to pass information between them, but it feels kind of hacky.

Approach 2: Write them all in one big Sencha Architect project. So, it sarts up in a single app.html page with everything in it.

--- Pros:

Now every component in the project can collaborate with each other.
A true Single-Page-App All-in-One app.html looks nice.

--- Cons:

Having hard time if multiple programmers are working on one Sencha Architect project.
It is one big complicated piece of app. Although it is seperated into simple App, Store, M, V, C categories, but we can have name crash on components in a larger project.
Loading speed may be an issue? I am just guessing here because we don't know if Sencha Architect MVC design loads relevant windows and compoents part by part or everything together.

Question is, if we take 1st approach how do we make communications between different projects? If we take 2nd approach, is Sencha Architech 2 designed to build real-world projects that way? stacking everything in one big project?

First I'll say that your thinking about this problem in all the right ways. Your pros and cons are spot on.

Second for full disclosure I'm an engineer on the Sencha Architect team.

My suggestion is to have separate projects that are more loosely coupled and perhaps connected by a portal/dashboard application. The glue app can be written in anything including Ext JS in Architect.

The reason I say this is simply that I don't like putting all my eggs in one basket and if you've built single page apps you'll know that when they're working they really hum. But when an uncaught javascript exception occurs it can force that user to have to do a full refresh to get back to a happy state. Of course if you're perfect this will never happen :p Who's perfect?

I build Architect which is in fact a very large single page application. As a team we all do our best to keep each system able to work with as little dependency on any other system(s) as possible. We use things like eventing, pub/sub, adapter and plugin patterns, etc...

These systems are very much broken into separate namespaces and directories which like all software helps developers compartmentalize. Architect doesn't fully support this idea today. However with convention you can get close. e.g. HRController, HRNewEmployeeForm, HREmployeeGrid

Having HR as a separate app however, affords you HR.EmployeeController, HR.NewEmployeeForm assuming your app name is HR. Each app being a separate project also allows for the dev team to be more agile in how it deploys!! Major win.

Other users have taken this approach and one such user graphs all his projects together using a managed iframe approach http://www.sencha.com/forum/showthread.php?243179

Asp.Net MVC is another good approach and might afford you some features like user auth etc...

Hopefully this helps!

Recommended topics

Hot tags