Large project with 100s of views?

[NathanStiles]

First I want to say how much I really want Architect to work for our project and I'm just getting acclimated with Sencha products for the first time.

I'm having trouble imagining working in Architect after we've created numerous controllers, views, models, etc.

• Would working with a large project be wildly cumbersome?
• Can I move logical groups of functionality into their own folders?
• Is it wrong to think I can get our entire application into a single project in Architect?
• If I were to use multiple projects how do I handle objects that need to be reused? Styles, avoid code duplication, etc.

Thanks in advance for any replies any thoughts are welcome.

[aconran]

I hope that some of our customers that are using this for larger projects respond here.

There are many things we are doing to improve huge projects in terms of both speed and usability.

[*]Would working with a large project be wildly cumbersome?

Architect 2.1 does not have a search within the Application inspector. This has been implemented in 2.2 and is currently in testing with our early access program. We admit navigating back and forth in between very large projects can become tiresome; the search will help alleviate this.

[*]Can I move logical groups of functionality into their own folders?

Architect supports namespaces. If you say foo.Bar it will create a namespace foo with a class of Bar. Currently this is just a flat view when viewed in the Inspector. We are having discussions about grouping this together into folders when viewed in the Inspector.

[*]Is it wrong to think I can get our entire application into a single project in Architect?

No. We've seen some pretty huge projects that customers have shared with us.

[*]If I were to use multiple projects how do I handle objects that need to be reused? Styles, avoid code duplication, etc.

This one is a bit tricky and something that we are aware we need to improve (sharing code/resources across different projects). Currently there is the ability to export/import components but they are essentially just snapshots and will remain however they were when they were brought in/out.

[tangix]

Hi,
just my thoughts; I am porting an Ext JS 3.x application to 4.1.x and I find SA invaluable for this. Currently I have 38 views, 25 additional components (localized DateFields, TimeFields, GridColumns with renderer etc), 15 controllers, 14 stores and 12 models (some are fairly large with 40+ fields). I wouldn't have made it this far without SA!

SA is a great tool to keep things organized and to enforce a same structure to the project. Navigating around this project is a bit tedious at times but once you have located a view it is easy to switch between design and code mode and focus you work there. Shift-clicking in Project Inspector to expand/collapse all below a node is something you will learn quickly...

There are some issues in SA when it comes to managing localization of radio buttons and the handling of TemplateColumns but nothing that can't be sorted out once you get a hang of it - my tip is to use overrides as soon as you hit something SA can't do or don't allow you to configure - getting a property configured as "object" to behave correctly is SA can be a great time waster - skip that and go for the override is my advise.

I am working on Windows 7 64-bit with 8 GB of RAM I haven't seen any problem so far with SA's stability or speed. SA is running constantly throughout the day and I have PhpED, FF with Firebug fully enabled, Charles web-proxy together with a MySQL workbench and some text-editors - no sweat what so ever!

I use SVN to manage the code and includes my libraries (that are in different SVN locations) using the Resources function.

HtH,
/Mattias

[EAHC-IT]

Hello,
The search of the project inspector will be very usefull.
I have also the same concern about sharing objects, do you have analysed further on this point?

[coolfish]

I'm working on a project that currently has 34 views, 12 controllers, 20 odd stores, 16 models, etc, and it will only be getting bigger. It's helpful to collapse everything that you aren't working on. Everything discussed above would absolutely help, especially the idea of logically grouping views (which can have custom components that they then link to, etc). I try and speed things up by dragging components that I'm working on to the top of their respective lists, that way they are a bit easier to find. It's not too bad, but now that I'm hearing what 2.2 might have in store I'm looking forward to it.

One thing I'd like to see - the ability to add comments for JsDoc on anything. Right now all comments have to go in the code. Would be nice if they could sit outside the object or function and you could even see them there when editing, but keep it separated. Man.. with smart templates for code commenting. That'd be peachy.

[elgs]

I'm working with two project with ~20 sub-SA projects, and the numbers are still increasing. We call them modules, and we try to keep each module small. Of our two projects, one is tab panel based and the other one is window based.

For the tab panel based project. We have a border layout viewport, we have a tree menu on the west, and tab panels on the east. But the tab panels are empty. Whenever a tab panel needs to be activated and displayed on the east tab panel area, we use an iframe inside the tab panel to load other modules, which are actually other SA projects. The code for the iframe may look something like this:

{
    xtype: 'panel',
    layout: 'fit',
    html: '<iframe src='+some_url+' width=100% height=100% border=0 />'
}

For the window based project, we use iframe, too. The mechanism essentially is similar, however, with the only thing to note that we don't use html as what we used in the tab panel based project. The reason is the events in the iframe seem not to be bubbled up to the enclosing container, so if windowA is partially on top of windowB, and the windowB will not be brought to the front if you click on the inner area of windowB. Fortunately an iframe ux in the example/ux folder solves this problem nicely. So we use it. I'm not going to talk in detail about the iframe ux. If you are interested in that, you may refer to the ext document or Google, or request me to provide some sample code in our project.

How do the enclosing and enclosed iframe windows to communicate? Let the code answer this question:
child -> parent:

window.parent.document.getDocumentById('dom_id');

parent -> child:

var ifrm = document.getElementById('my_iframe');  
ifrm = (ifrm.contentWindow) ? ifrm.contentWindow : (ifrm.contentDocument.document) ? ifrm.contentDocument.document : ifrm.contentDocument;  
var my_dom = ifrm.document.getDocumentById('dom_id');

The only drawback is you have to explicitly use id instead of itemId, which might be what you avoid doing normally.

[neilw]

For the tab panel based project. We have a border layout viewport, we have a tree menu on the west, and tab panels on the east. But the tab panels are empty. Whenever a tab panel needs to be activated and displayed on the east tab panel area, we use an iframe inside the tab panel to load other modules, which are actually other SA projects.

In this case, each iFrame must reload the ext library, right? What impact does this have on browser memory loading?

We're at the starting point of building a large tab-based app in Ext JS and are considering how to structure it. I hadn't really thought of doing it with an iFrame in each tab. What other downsides have you encountered?

[elgs]

In this case, each iFrame must reload the ext library, right? What impact does this have on browser memory loading?

We're at the starting point of building a large tab-based app in Ext JS and are considering how to structure it. I hadn't really thought of doing it with an iFrame in each tab. What other downsides have you encountered?

Yes, loading ext library multiple times probably is the drawback. However, the performance currently is still not very bad. I don't have a better way to organize a big project with a lot of modules. In this way, all modules are relatively independent to each other. I believe later some time if I find a way to solve this problem, it should not be too painful because of the loose coupling.