See the discussion in the text. On 6 Mar 2009, at 14:20, thron7 wrote: > > Jean-Baptiste BRIAUD -- Novlog wrote: >> Don't scare me too much : we had lots of discussion about how to use >> qoxdoo without the py build and at that time it didn't look too bad >> to >> do that. >> As some messages show it here, we are several apprently using qooxdoo >> without py build. >> I understand lots of good work had been done for optimisation on that >> py build but even good optimisations are always done for a particlar >> context. So if one want to use qooxdoo in a slightly different >> context, it should be possible. >> I had choosen qooxdoo, and I never regret it, just because it was >> possible to use it without the py build machinery. >> I'd like to clarify if that way of using it is already or have to be >> tag as forbidden or if, like I understood it, we are warn we won't >> benefit of all the god optimisations made in the py build. >> > > I, for one, are not forbidding anything :-). But everything comes at a > price. I understand that :-) > And what everybody seemed to ignore at the time we had that > discussion was that you can achieve all of this (as far as I can see) > with standard qooxdoo tools - with that one constraint that you have > to > use the tool chain *once*. Well ... no ... that's the problem, if not, it would not be a problem to just use it once :-) I can reexplain why shortly : I'm generating entire IT system, so everytime a new project (it implies a new IT system with different spec, different end user, different customer, different database, different GUI, ...) is started, I'll have to run that tool and that happen at *runtime* for me. The classical buildtime is runtime for me as a compiler or a generator. Also, I don't know very much about that build but I understood it has to be run each time a new javascript file is added and not just once at the begenning. Because it it is only once at the begenning, I'll prepare a zip file of the result and then I won't have to use the build anymore.
> In the context of a custom project, I don't > see any difficulty to grab a Python and a qooxdoo SDK and run it > *once* To keep qooxdoo as a general purpose framework, I would suggest to let open the fact that for some people, having Python might be a blocker. I would not like to go too far that way as it is not the problem I'm really facing technically, but even that said, I'm not really keen to use Python for my developpment, I already have enought different technology and I always try to minimize extra dependency. Also it could be an issue for some IDE. Finally, what's absolutly wrong with the idea os using qooxdoo as "just include qooxdoo javascript file and use it" ? > > and then re-use its output multiple times, on multiple machines and > with > multiple developers, just as if you had downloaded it from Petr's web > site. This would have given you all the ease of using a pre-build > library and *additionally* all the support e.g. for a new version. You > could follow standard procedures, re-run the generator, and have a new > library to work with. That's I don't understand clearly : when will I have to re-run that generator ? I'm really OK to run it once when a new version of qooxdoo is out. As for the Python dependency, if I could remove the "dependency" with Petr build, I'll do it to be more standard (I'll prefer that, really), but can I ? Basically, can I have a default project build once with the build and then reuse that folder tree in time and space : in space : with different various extremly different project ? I guess yes, just copy that folder tree (produce by the build once and saved in a zip file for example) to bootstrap the new project. in time : considering one project's life, can it live without py build if I add javascript qooxdoo new files ? I guess no but I'm not sure. During that live, my qooxdoo application will add file to this qooxdoo project. Yes, I'm a compiler that produce qooxdoo files (and others) and the GUI of that compiler is in qooxdoo : lots of qooxdoo, that's why I like it :-) > > > But in fending off this limited initial effort, you went for a quick > grab of the pre-build library and are now spending probably non- > trivial > efforts afterwards. I wished that most of the effort that went into > Petr's custom build .js file would have gone into a custom config.json > and index.html file. *This* would have been really re-usable, people > could share this stuff easily on the mailing list or through a > contrib, Yes, but then, the py build has to be run during project's live, at build time, but that is done by a program in my case and so it is runtime for me. I know there are some optimisation in that build, but my own "thing" can already been seen as a complexe build system with a lot of optimisation, so please, leave the door open to use qooxdoo without apparent optimisation. > > so that others would be able to just drop them into a vanilla skeleton > and then let the generator do its stuff. Rather than a pre-build > library > you would be sharing the information how to create it anywhere, > anytime, > under your own control, and with very little effort. > > > Cheers, > Thomas > > >> On 6 Mar 2009, at 12:54, thron7 wrote: >> >> >>> Hi Petr, >>> >>> Petr Kobalíček wrote: >>> >>>> Hi Alex, >>>> >>>> thanks for response. >>>> >>>> So is there any way to use the loader or to force it to load my >>>> script >>>> files or it's deprecated and it will be completely removed in the >>>> future? I mean what 'parts' are now working within qooxdoo? I think >>>> that loader will remain;) >>>> >>>> What can you recommend me to do to get the old loading behavior? I >>>> like my dynamic way and our application needs it (with qxbuild we >>>> have >>>> only one qooxdoo support package and all applications (variously >>>> configured) are using the same qooxdoo files). >>>> >>>> >>> I mean, you *are* aware that you are playing with highly internal >>> stuff, >>> which we do not recommend at all, and about which we make no >>> promises >>> altogether, how it will evolve or how we are going to use it or >>> whatnot, >>> aren't you?! And you cannot expect us to spend much time in >>> supporting >>> you on this way. You wouldn't heed when we warned about embarking >>> this >>> "dark way". When you are hacking a system (like you do with >>> qooxdoo), >>> this is the price you pay, right ;-). >>> >>> Thomas >>> >>> >>> >>>> Cheers >>>> - Petr >>>> >>>> 2009/3/6 Jean-Baptiste BRIAUD -- Novlog <[email protected]>: >>>> >>>> >>>>> Hi Petr, >>>>> >>>>> Please to hear that : the qxbuild for 0.8.2 not the issue :-) >>>>> I jump the 0.8.1 as I really need qxbuild to use qooxdoo. >>>>> >>>>> On 6 Mar 2009, at 01:13, Petr Kobalíček wrote: >>>>> >>>>> >>>>> >>>>>> Hi devs, >>>>>> >>>>>> after some time not developing in qooxdoo I'm back. I want to >>>>>> update >>>>>> qxbuild to be able to sucessfully build 0.8.2 and SVN. I tried it >>>>>> now >>>>>> and I have some problems. >>>>>> >>>>>> First I see is that there is now only 1 javascript file generated >>>>>> per >>>>>> one build type (build or debug), I tried to look at generated >>>>>> files >>>>>> and there is something like this: >>>>>> >>>>>> qx.$$loader = { >>>>>> parts : {"boot":[0]}, >>>>>> uris : [["script/qx-debug-0.js"]], >>>>>> boot : "boot" >>>>>> }; >>>>>> >>>>>> Isn't this incorrect ? >>>>>> >>>>>> Also I have question if I can add some things into boot loader >>>>>> (this >>>>>> way is used for older qxbuild) ? I mean add possibility to >>>>>> control it >>>>>> from html wrapper file. >>>>>> >>>>>> My way using qxbuild was this (html file): >>>>>> >>>>>> <script type="text/javascript"> >>>>>> // [Settings] >>>>>> qxsettings = >>>>>> { >>>>>> "qx.application" : "bfly.main.Application", >>>>>> "qx.theme" : "bfly.theme.Light", >>>>>> "qx.resourcesUri" : "/res/bfly/support/qooxdoo/resource" >>>>>> }; >>>>>> >>>>>> // [Scripts] >>>>>> qxscripts = >>>>>> [ >>>>>> "/res/bfly/support/qooxdoo/script/qx-build-0.js" >>>>>> >>>>>> ,"/res/bfly/admin/bfly.theme.js" >>>>>> ,"/res/bfly/admin/bfly.main.js" >>>>>> ,"/res/bfly/admin/bfly.lib.js" >>>>>> ,"/res/bfly/admin/bfly.lib.filebrowser.js" >>>>>> ,"/res/bfly/admin/bfly.lib.richtext.js" >>>>>> ,"/res/bfly/admin/bfly.lib.db.js" >>>>>> ,"/res/bfly/admin/bfly.io.js" >>>>>> ,"/res/bfly/admin/bfly.ui.js" >>>>>> ,"/res/bfly/admin/bfly.forms.js" >>>>>> ,"/res/bfly/admin/bfly.base.js" >>>>>> ,"/res/bfly/admin/bfly.web.js" >>>>>> ,"/res/bfly/admin/bfly.web.news.js" >>>>>> ,"/res/bfly/admin/bfly.shop.js" >>>>>> ,"/res/bfly/admin/bfly.devel.js" >>>>>> ]; >>>>>> </script> >>>>>> >>>>>> <script type="text/javascript" >>>>>> src="/res/bfly/support/qooxdoo/script/qx-build.js"></script> >>>>>> >>>>>> Now it seems that I can delete >>>>>> /res/bfly/support/qooxdoo/script/qx-build-0.js from file list >>>>>> needed >>>>>> to load, but can I without hacks (some python scripts that >>>>>> postprocess >>>>>> built files) add this to bootloader by this way? >>>>>> >>>>>> Thanks for assistence:) >>>>>> - Petr >>>>>> >>>>>> ------------------------------------------------------------------------------ >>>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San >>>>>> Francisco, CA >>>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the >>>>>> Enterprise >>>>>> -Strategies to boost innovation and cut costs with open source >>>>>> participation >>>>>> -Receive a $600 discount off the registration fee with the source >>>>>> code: SFAD >>>>>> http://p.sf.net/sfu/XcvMzF8H >>>>>> _______________________________________________ >>>>>> qooxdoo-devel mailing list >>>>>> [email protected] >>>>>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >>>>>> >>>>>> >>>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Open Source Business Conference (OSBC), March 24-25, 2009, San >>>>> Francisco, CA >>>>> -OSBC tackles the biggest issue in open source: Open Sourcing the >>>>> Enterprise >>>>> -Strategies to boost innovation and cut costs with open source >>>>> participation >>>>> -Receive a $600 discount off the registration fee with the source >>>>> code: SFAD >>>>> http://p.sf.net/sfu/XcvMzF8H >>>>> _______________________________________________ >>>>> qooxdoo-devel mailing list >>>>> [email protected] >>>>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >>>>> >>>>> >>>>> >>>> ------------------------------------------------------------------------------ >>>> Open Source Business Conference (OSBC), March 24-25, 2009, San >>>> Francisco, CA >>>> -OSBC tackles the biggest issue in open source: Open Sourcing the >>>> Enterprise >>>> -Strategies to boost innovation and cut costs with open source >>>> participation >>>> -Receive a $600 discount off the registration fee with the source >>>> code: SFAD >>>> http://p.sf.net/sfu/XcvMzF8H >>>> _______________________________________________ >>>> qooxdoo-devel mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >>>> >>>> >>>> >>>> >>> ------------------------------------------------------------------------------ >>> Open Source Business Conference (OSBC), March 24-25, 2009, San >>> Francisco, CA >>> -OSBC tackles the biggest issue in open source: Open Sourcing the >>> Enterprise >>> -Strategies to boost innovation and cut costs with open source >>> participation >>> -Receive a $600 discount off the registration fee with the source >>> code: SFAD >>> http://p.sf.net/sfu/XcvMzF8H >>> _______________________________________________ >>> qooxdoo-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >>> >>> >> >> >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San >> Francisco, CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the >> Enterprise >> -Strategies to boost innovation and cut costs with open source >> participation >> -Receive a $600 discount off the registration fee with the source >> code: SFAD >> http://p.sf.net/sfu/XcvMzF8H >> _______________________________________________ >> qooxdoo-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >> > > ------------------------------------------------------------------------------ > Open Source Business Conference (OSBC), March 24-25, 2009, San > Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the > Enterprise > -Strategies to boost innovation and cut costs with open source > participation > -Receive a $600 discount off the registration fee with the source > code: SFAD > http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
