Re: [qooxdoo-devel] qooxdoo development setup
Hi Bharat, 2011/2/14 nrg-b : > > Hi Ivo, > > Slightly OT, but I am intrigued to ask why are you looking at Qooxdoo given > that you seem to have a working system based on JQuery? In other words, what > is it about JQuery that is making you consider Qooxdoo (or something else)? > I'm working on a (Python) toolkit that allows you to build generic user interfaces in stead of working on a specific application / UI. This means I need a large set of controls / widgets, and JQuery doesn't really offer a consistent, good looking set of these like Qooxdoo does. To give you an impression, http://rctkdemo.m3r.nl/ (see http://rctk.org for more info on the project which will basically point you to http://rctk.googlecode.com at this moment) Trying to integrate all existing 3rd party (JQuery) UI components and partially implementing/wrapping them myself, and especially laying them out properly is taking too much of my time. I'd rather not depend too much on a specific toolkit like Qooxdoo, but if I can get it to work (and it seems I can), it will save me a lot of time and I'll actually be able to start developing applications using my framework :) Theoretically, the UI component should be pluggable so you can choose if you want the Qooxdoo or JQuery frontend (or Flex, HTML5, or perhaps just gtk+, tkinter, etc). Who knows, perhaps I'll get that far one day. 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 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
Re: [qooxdoo-devel] qooxdoo development setup
Ivo van der Wijk wrote: > > Part of my experiments if to see if it can replace what > JQuery/JQueryUI currently offers, and integration with the backend is > really important > Hi Ivo, Slightly OT, but I am intrigued to ask why are you looking at Qooxdoo given that you seem to have a working system based on JQuery? In other words, what is it about JQuery that is making you consider Qooxdoo (or something else)? FYI - I am using QX to prototype a RIA frontend to our existing Java/Swing trading application so that it can be used over the internet. JQuery (& sencha / ext.js) is something which I initially considered but seemed just a bit too low-level for me as I am mainly a java server-side guy. I didn't have the time or the volition to mess with html and css etc. Interested in your thoughts and from others. Regards, Bharat -- View this message in context: http://qooxdoo.678.n2.nabble.com/qooxdoo-development-setup-tp6020508p6023317.html Sent from the qooxdoo mailing list archive at Nabble.com. -- 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
Re: [qooxdoo-devel] qooxdoo development setup
On Sun, Feb 13, 2011 at 08:31, Ivo van der Wijk wrote: > > 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 You can make the build version debuggable, and that's what I tend to do when I am forced to develop using a server-based version. (I try to separate my gui and server-side development by testing the gui code on its own; then writing the server side and testing it with RpcConsole (I use JSON-RPC, and RpcConsole allows one-shot or scripted testing of remote procedure calls); then when both of those are working independently, I switch over to issuing the requests from the gui code to the server code. At that point, there are many fewer possible sources of error, so debugging is reasonably easy. The way you create a debuggable build version is to turn off optimization. There are four types of optimization, and it's possible you don't need to disable all types (you can read up on it) but to disable all of it, add this line to the top-level "let" section of your config.json: "OPTIMIZE" : [ ] then do another "generate.py build". You'll find that it then generates a single file with everything, but the file is readable and debuggable. Hope that helps. Derrell -- 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
Re: [qooxdoo-devel] qooxdoo development setup
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 -> 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 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
Re: [qooxdoo-devel] qooxdoo development setup
> 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 -> 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
