What I have done is to create an "application framework", which in my case uses a border layout at the topmost level, as shown here in the SoftNAS(tm) administrator's reference guide. The admin menu panel on the left side (west region) is used to navigate the available "applets". Each applet appears in a separate IFRAME on the right side (east region), in its own tab. Here is an example of how it appears when several applets have been launched:
It turns out, this approach has the added benefit that you can display any HTML page within the framework, so it supports both SA-generated applets, as well as any other web page (e.g., documentation pages, non-SA applications, PHP pages, etc.
This is very similar to how the Sencha Documentation system works.
If you've ever tried developing, debugging and maintaining a huge, monolithic ExtJS application, then you will have a great appreciation for a more modular, focused approach.
@rbraddy), thanks for sharing your approach.
Maybe other developers could share other alternatives of developing huge and complex applications / platforms through SA, w/o having an IFRAME for each app/page.
I'm afraid I'm somewhat less than sanguine about my experience. I feel it is somewhat akin to trying to edit using an old fashioned Rolodex wheel with small cards. One is constantly spinning the wheel (or mouse wheel) trying to find the right slot, with no go-backs to get to a previous point. I've also been disturbed with the broken code that keeps popping up. In the car tutorials, first rattle out of the box, the stores wouldn't load XML. They got that fixed so I proceeded and the next step didn't work.
I tried another tutorial and that didn't work. I tried turning off the appended _dc random string in a RESTful proxy, but that didn't work. The custom api for GET, POST, PUT, and DELETE didn't work. The buildURL function was completely counterintuitive and, while it worked just fine for GET it doesn't even trigger for the other verbs. The documentation is a complete mind-blank. Googling for solutions brings up deprecated functions, junk for Ext versions 1, 2, & cetera and not entirely clear. Duplicate documentation is on all sorts of other websites that are completely unaffiliated with Sencha. The IDE is like a closet stacked with a jumble of shoe boxes, which in this case are functions, views, listeners & cetera that are completely disconnected from their real-world/visual components (one might have a tree in the layout, but try connecting with all the background code--it's all over the place). Queries on support site go unanswered. The MVC model bears no resemblance to the original model by Trygve Reenskaug & Alan Kay--but I shouldn't be too harsh on that because everyone seems to make up their own MVC model without regard for the original concept.
In short, as I said, I'm somewhat less than thrilled. I'll finish the project for which I made this toolkit choice, but then, like Elvis, I'm gonna leave the building.
@rbraddy When you say IFRAME do you mean actual browser iframe or you are referring to one of the border layout regions? if browser iframe, then how does one iframe talks with another, I have always been under the impression that iframes are like separate browsers instances(tabs in the new browsers).
"If you've ever tried developing, debugging and maintaining a huge, monolithic ExtJS application, then you will have a great appreciation for a more modular, focused approach."
I agree with you completely. I wrote a library to support a configuration driven Modular MVC Design pattern using ExtJs4.2.2, although I didn't have to use any IFrames, I agree with your approach. I spoke with one of the developers of Sencha's Architect IDE and he stated that their team is inevitably going to start supporting a modular design pattern. What ExtJs is currently "enforcing" as a design pattern is creating a nightmare for development by causing a waste of money.
That being said, ExtJs is still the best choice for Large Web Application development.