> Hi, > > I'm just getting started with qooxdoo development. I'm exploring if it > can be used for a project I'm working on. > However, I find the whole tooling/scripting/configuration chain around > qooxdoo rather confusing and unstructured. It probably makes sense > once you get the hang of it, but I just want to build UI's, not write > configurations and run scripts generating tons of stuff I have no > clear insight into.
If you work outside qooxdoo's default programming model (which you do running the source version through an application server), you will not be able to get around without concerning yourself with the config system. 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. > > 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. > > 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). To disable the nocache parameter, set compile-options/uris/add-nocache-param : false in the "source" job of your config.json. > > So, what am I missing here? What does a decent (non-fs based) qooxdoo > development setup look like? Which docs did I forget to read / fail to > find? There is a snippet section about running a source version from a web server [1], but since you already deployed library/uri parameters, you are probably beyond the point where you can benefit from it. T. [1] http://qooxdoo.org/documentation/general/snippets#running_a_source_version_from_a_web_server ------------------------------------------------------------------------------ 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
