Hi, personally, I would avoid Iframes if possible. In my experience, they tend to create more problems than they solve. Generally speaking, the Demo Browser probably isn't the best example for a large qooxdoo application. It was written long before concepts such as data binding were introduced to the framework and never got the makeover it deserves ;) The Playground is a much better example for a clean architecture that separates the logic from the view.
qooxdoo has a part loading mechanism that could be just what you're looking for: http://manual.qooxdoo.org/current/pages/development/parts_using.html Check out the Feedreader's sources for a live example. Some more general hints: * Create UI widgets only when they're actually needed to save initial startup time. * Avoid destroying and re-creating widgets (such as form elements) by pooling and reusing them. The ObjectPool class can help you with this: http://demo.qooxdoo.org/current/apiviewer/#qx.util.ObjectPool * MVC is a tried-and-true design pattern well supported by qooxdoo thanks to its data binding layer. Regards, Daniel 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 ? > > 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 ? > > 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 ? > > > > Best regards, > Elemer. > > > > > > > > ------------------------------------------------------------------------------ > 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 > > ------------------------------------------------------------------------------ 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
