The only problem with linking qx.js from the demo is that the relative 
paths to the class files does not match. These must be valid from the 
location of the document which includes the file, not from qx.js itself.

I think the best is to integrate all existing code bases to the 
skeletons. I think this is easier and faster than manually trying (and 
failing) many times. Normally it's quite easy. The structure used from 
the skeletons is much better than some old style, where you have 
included some demo.js and hacked around with this.

Features of the skeletons are:
* Custom or Full build (custom builds are optimized to your application)
* Own API viewer (combining qooxdoo & your application classes)
* Complex commands wrapped inside a useful and easy to use Makefile

Cheers,
Sebastian



Hugh Gibson schrieb:
>> if You do a "make source" qx.js is only a loader for the original 
>> qooxdoo files. If You want to deploy Your application You must do a 
>> full build ("just type make without parameters") The qx.js of a full 
>> build is about 900K in size and contains the full sourcecode of 
>> qooxdoo. The best way to develop a qooxdoo application is using the 
>> skeletons (http://qooxdoo.org/documentation/user_manual/skeleton).
> 
> Yes, thanks, but that's not what I'm wanting to know. I've done a full build 
> from SVN source, but it's useless for debugging. In the old days of 0.5 I 
> wrote up how to do a build with the newlines in the code so that you could 
> trace into qooxdoo code to see what was going on. As you know, the 
> documentation still leaves a lot to be desired to a lot of the time you have 
> to "use the code" to see how something really works.
> 
> Anyway, I thought I had found the solution with the source build. And with 
> the demos it looks great - as I said, you can see all the qx files loaded 
> into the debugger. So I thought that just using the qx.js from the frontend 
> location would be sufficient, but it isn't, as qx isn't defined etc.
> 
> It looks to me that the demo source build has been sorted out, but not the 
> source build for your own applications (though, as we started this work 
> before the skeletons were written, it may be that we could use the qx.js from 
> the demo - I might have to look into it further).
> 
> Hugh
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Reply via email to