Am 08.09.2008 um 23:19 schrieb Jean-Baptiste BRIAUD - Novlog: > > On 8 Sep 2008, at 23:03, Sebastian Werner wrote: > >> >> Am 08.09.2008 um 22:59 schrieb Jean-Baptiste BRIAUD - Novlog: >> > [CUT] > >>>> >>>> As already mentioned: Maybe it would OK for you to create a set of >>>> JavaScript files once. For example to compile the 400 classes into >>>> 10 >>>> logical packages (where one is kind of core which is needed by all >>>> of >>>> them). Then you can dynamically include the packages you like. >>>> Would >>>> that be an option? >>>> >>> >>> No, that would be a solution ! >>> >>> How hard it is to do that ? >> >> Not to hard. You can basically build all this into a single >> config.json (configuration for the generator). >> >> It is basically a set of include/exclude statements which filter the >> whole class set into smaller groups. We can work on this together >> when >> you like. >> >> Sebastian >> > > That's really great, my problem look like solved ! Let me explain the > solution I understood with my word : > > Say a new version of qooXdoo is availlable. > Step 1 : install it including the toolchain on developer machine > Step 2 : launch a special build using several config.json
It's only one config.json :) > > Step 3 : extract the qooXdoo built and package it as a special- > qooXdoo- > for-our-generator.bz2 What do you mean by extract? Mainly just copy over the build directory to the server. It also contains some resource graphics for the theme you select. > > Step 4 : install that package on the server. The server do not need > Python. By the package you still mean that it may contain multiple script files? > > > As a consequence, the special-qooXdoo-for-our-generator.bz2 file size > will be bigger than optimized qooXdoo build since all classes will be > include and modularity won't change that. Load time will also be more > important than the result of the optimized built process but can be > maintain resonable via modularity > Say we build with CORE + A + B modules. The worst case would be when > one application only need a small class from B, so all B will have to > be loaded. And CORE would also be loaded as it contains the whole OO stuff & toolkit core features etc. The idea with the packages is also great for cachability. It is much better than depend on single files (bad latency) and also better than one single file (much overhead). It's the best compromise when trying to get a more generic solution. > > > I can deal with that. Ok, fine. Welcome to qooxdoo :) Again. Sebastian > > >> > [CUT] > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
