Hi Thomas,
> > As you are just evaluating qooxdoo, maybe it would be a better approach to > create a simple prototype application that does not try to integrate with > your current project. This way you could stick within the default > development model and focus on the more important aspects of the framework > (class system, widget set, data binding, IO layer, ...). Once you're > satisfied with these, it might be more justified (and better motivated) to > look at the integration of qooxdoo with the current project and adapt its > development model. > Part of my experiments if to see if it can replace what JQuery/JQueryUI currently offers, and integration with the backend is really important >> >> For example, because I need everything to be served by my application >> server to avoid cross domain request issues, I had to mess with >> config.json which I found rather unclear. Eventually it turned out >> that I just need to reconfigure the URI for jobs -> libraries -> >> library -> <qooxdoo>Manifest.json, I still have no clear idea what the >> purpose of compile-options -> uris is. > > In short: The library/uri parameter is relevant for the source version of > an app, compile-optioins/uris for the build version. As the libraries are > addressed individually in the source version, each library can be reached > through an individual uri. In the build version, all resources are > collected together under the "build" directory, which is separate from any > involved library, so the compile-options settings are used to taylor > generated uris for the build version. > I've somewhat learned that by now. The build version is "lean" and fast and actually usable, but not very useful for development. I don't mind an optimized compressed qooxdoo library, but it would be nice if my own code remains readable/debuggable. It's somewhat all or nothing right now, but I don't really care about the core qooxdoo components (at this moment) >> >> But that part's been solved for now - I can serve qooxdoo directly >> from my application server, or directly through apache. However, now >> it turns out that, in my development/source setup, qooxdoo is loading >> over 500 (different) files. An due to the caching parameter, >> duplicates are loaded as well. This means it takes over a minute to >> "load" my trivial application, which is too long for development. > > 500 classes and one minute to load in a modern browser looks like more > than a "trivial" application, at least compared to the GUI skeleton (which > has around 200 classes and loads in a few seconds). > My application is a trivial window, Ajax request and an alert popup. I have the impression a lot of modules are loaded more than once. Firebug may also be a slowdown. > To disable the nocache parameter, set > compile-options/uris/add-nocache-param : false in the "source" job of your > config.json. > I'll play with that and see if things improve. Thanks for your help so far! Regards Ivo -- Drs. I.R. van der Wijk / m3r Consultancy B.V. Linux/Python/Zope/Plone and Open Source solutions PO-box 51091, 1007 EB Amsterdam, The Netherlands Email: ivo <at> m3r.nl Web: http://m3r.eu/ ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
