Thanks d,
Yes I understand qx itself best stay static and separate.
Fabian pointed out some build options (in the trunk) which allow you to
specify which classes to include.
So an optimization (probably at a later point) could be to limit the
qx.jsto what is really used, whether that can be dete
Thanks Fabian,
That helps a lot.
Cheers,
Danny
On 2/13/07, Fabian Jakobs <[EMAIL PROTECTED]> wrote:
Hi Danny,
> Do I just make a "mock" skeleton project with a dummy HTML page and
> then move custom.js (or whatever contains the finished qooxdoo JS
> library) from the "build" directory to the
Hi,
I also create dynamically JS and HTML, but have a static qx.js that includes
everything I may need. This file is big, but is cached by the browser. If
I had different customs qx.js files, then nearly all of them would need to
be downloaded if the user accesses some pages.
Danny Adair-2 wr
Hi Danny,
> Do I just make a "mock" skeleton project with a dummy HTML page and
> then move custom.js (or whatever contains the finished qooxdoo JS
> library) from the "build" directory to the static directory of the
> application server?
>
> Builds which only include what's needed: As it will b
Hello again,
We've got a very modular design in our TurboGears-based application where
dynamically created javascript "files" (which are mainly using stock classes
from qooxdoo) get pulled together at runtime.
If I have not a single static HTML page but rather dynamically create
everything on th
Hello again,
We've got a very modular design in our TurboGears-based application where
dynamically created javascript "files" (which are mainly using stock classes
from qooxdoo) get pulled together at runtime.
If I have not a single static HTML page but rather dynamically create
everything on th
