Hi,
Am Dienstag 15 Juni 2010 schrieb thron7:
> Grabbing just the qooxdoo .js file this way would not work. You would
> have to copy all the images along. And not only for this one
> application, but also for the next, and the next, and the next. This is
> a waste of disk space you'd say, so you would want to put the qooxdoo
> stuff into a central directory too, together with the images. But then
> all the URIs to images from within qooxdoo would stop to work, so you
> would need to adjust them, for each individual application, as each
> potentially has a different relative path to the images. And so on and
> so forth...
just for perspective I would like to describe how we use a big qooxdoo library
in our systems - an eCommerce product.
There is no whole application but instead it provides a frame and abstract
functions where application plugins attach itself to [Content-Management,
Newsletter, ProductManagement, ...].
For this to work each individual application becomes a package [there are
also library packages] and we modified the Debian package management system
to manage this for us [installation, updates, ...]. Therefore there is no
build time as it isn't clear what will be included in the application instance
for each customer which results in the need for qooxdoo to be a team-player
and a monolithic qooxdoo library.
We build the library with the following config (this is a part of it)
"build" :
{
"extend" : ["common"],
"library" :
[
{
"manifest" : "qxaddons/Manifest.json",
"uri" : "qxaddons"
}
],
"include" :
[
"qx.*",
"nx4.base.Assets"
],
"exclude" :
[
"=qx.test.*"
],
nx4.base.Assets does nothing more then to require all assets.
The install-step in our build rules does then among other steps
#qxdata.js zusammenstellen
head -128 build/qx-dbgoff.js | tail -n +3
>BUILDINFO/qooxdoo/share/qooxdoo/qxdata.js
head -131 build/qx-dbgoff.js | tail -n +3 | tail -1
>>BUILDINFO/qooxdoo/share/qooxdoo/qxdata.js
pkghash=`tail -n -1 BUILDINFO/qooxdoo/share/qooxdoo/qxdata.js | cut
-d "=" -f 1 | cut -d "'" -f 2`
echo "qx.\$\$resources=qx.\$\$packageData['$pkghash'].resources;"
>>BUILDINFO/qooxdoo/share/qooxdoo/qxdata.js
installjs "qx-dbgoff.js" "qooxdoo" "qx.js"
to separate the init-data from the library with installjs doing a
cat build/$1 | sed '1,131d' | head -n -2 >>$target
to strip off the just separated data. These steps need a bit of modification for
each major qooxdoo version, as the generator output differs most of the time.
But this is once every 6 months or so :-)
This results in a qooxdoo-1.0.1-2_all.kap package that is easy to install in
individual application instances using a simple
kapt-get install qooxdoo
and behaves exactly the same in each. The application then simply depends on
"qooxdoo (>= 1.0.1)"
The rest of the javascript classes are resolved and included using our own
dependency resolver based on
#kesrequire(share/.../....js)
statements in the source files.
I hope I didn't write to much nonsense :-) but I like our solution and
perhaps it's helpful to someone [of course only with a dedicated server].
Heiko
--
Nexst4 GmbH
Arndtstrasse 12
01099 Dresden
Tel.: +49 (351) 655 76 70
Fax: +49 (351) 655 76 66
Mail: [email protected]
Geschäftsführer: Alf Thiele, Matthias Schmidt
Sitz der Gesellschaft: Dresden
Handelsregister: Amtsgericht Dresden HRB 27274
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
