Hi Elemer,
On 11/21/2012 04:29 PM, elpix1 wrote: > Hi, > > I have developed some small self contained Qooxdoo Desktop apps > and I am wondering what would be the best strategy to develop > big applications with potentially hundreds of forms and reports, > like for example ERP, CRM or general business applications. > > These apps will have a common screen area with a header, main menu, > toolbar, eventually a split pane, a work area and a status bar. > The work area contents will change depending on the form or report the > user is working on. > > Does the browser would support a monolitic "big" application > with several (?) megabytes of compressed Javascript or is > there a way to break the application in parts which would > be loaded by demand ? > > I have been studying the sources of the "demobrowser" as it > seems to be the most similar to this case. As far as I could > understand, the work area of the "demobrowser" is an iframe > and each demo is an independent qooxdoo application. > > Regarding this approach I have the following questions: > > 1. Is this the only way to achieve an scalable application, > or are there other methods ? There are in fact other methods, see further. > > 2. Using this approach is it possible in some way for the > application running in the work area iframe to communicate > with the external app ? For example to add or disable > items in the main menu or the toolbar ? It is possible to establish communication channels between the main application and the embedded iframes. But this might get tricky. > 3. One of the problems of this approach is the load time > of each form as each one contains a copy of part of the > Qooxdoo library embedded in the script. > Any solutions to this ? Exactly. So let me sketch a bit the options and their pros and cons. Demobrowser approach: - The Demobrowser approach with a main application and another application embedded in an *iframe* is good when you - need truely separate applications (because e.g. you cannot change the embedded app, it needs to be able to run stand-alone, etc.) - there is no or little coupling between the main app and the embedded app The disadvantages are as already mentioned (communications, framework code downloaded multiple times). Parts approach: - Another option is to create a single application and create the sub-applications as qooxdoo "*parts*" which can be loaded on demand. - this way you save load overhead - the parts and the main app can be easily coupled and communicate - they share the framework classes (and in fact all classes in the app) - this is a good approach if you expect the users of your app to often switch between the sub-applications, possibly with some communication going on between the sub-apps Library approach: - A third approach is to build N separate stand-alone applications than each implement the entirety of one sub-apps (N = the number of sub-apps you want to have). - this is interesting if you expect that a user chooses a specific sub-app and sticks with it for a while - and there is no coupling/communication necessary between the sub-apps You can still achieve a lot of code reuse by factoring out common elements of those apps into qooxdoo *libraries*. With that, each of the dedicated apps only needs to provide its specific code, building on the generic components from the libraries. In this way you can implement e.g. the main application layout (header, main menu, tool bar, ...) as a single or as individual libraries, and then instantiate or subclass these elements in the dedicated apps, where you provide specific settings, customizations, override methods, provide delegates, asf. (See the Showcase demo that uses various other libraries, albeit with a much smaller impact). The third options is the best when your main concern is code reuse, not coupling between the dedicated apps. HTH, T. ------------------------------------------------------------------------------ Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
