Additionally, I may have taken a slightly different approach to my application architecture than most. Instead of creating one big, monolithic ExtJS application, I chose to break my application into smaller, standalone "applets" (that's what I call them). Each applet is a standalone SA project and distinct ExtJS application. It can run standalone or be integrated into my overall application navigation framework.
I believe that this modular approach is perfect for Sencha Architect, as each application and project is smaller and focused as a result. Admittedly, I'm not thrilled with how I had to integrate the various applets into the application framework (using iframes), but it works and for the most part works extremely well.
If I understand well, all the views etc which you used in your application, they are each an application on their own,right? Is there any other way of integrating all of them without using iframes? I don't seem to truly understand this...
If I understand well, all the views etc which you used in your application, they are each an application on their own,right? Is there any other way of integrating all of them without using iframes? I don't seem to truly understand this...
Sencha Architect produces an ExtJS application, which has multiple views, controllers, stores, etc. When building a very large application (e.g., dozens to hundreds of views), by default SA assumes you will place everything in one corresponding large application (or a separate web page per application).
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.
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.
Each applet appears in a separate IFRAME on the right side (east region), in its own tab. (...)
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.
Rick (@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.
@rbraddyWhen 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).
@rbraddyWhen 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).
Thanks
The company I work for also uses browser iframes for older html/javascript pages that was developed before Ext JS was introduced into my company. You can do communication between iframe and the main window pretty easy. Just google some examples about communication between iframes and window in javascript. I have even created a bunch of workers using iframes for IE and using html5 webworkers for Chrome/FireFox/Safari in handling large datasets of 1,000-200,000 rows in a Ext JS 3.4 grid almost similiar to how Ext JS 4.1+ is doing the infinite grid.