Hi, compiling custom code can ve very efficiently achieved by yuicompressor.
The QxBuild is only tool how to use qooxdoo as a one big package. I understand the qooxdoo build process and I understand the advantages of it, but it has also disadvantages. The simplest application with some widgets is about 0.8 to 1MB (js size). The complete qooxdoo is about 1.4MB. I think that 400kB is nothing (it's 50-100kB gzipped). And for my application? I really don't need the qooxdoo tool-chain, because I want to use all my code (so there is no code that can be eliminated by tool-chain) and I really know why qooxdoo widgets I need (and these widgets with all dependencies are set in my custom QxBuild config file). I'm really wondering why there is not official package like QxBuild. I think that for evaluation it's great and I'm using it also for development/deployment. Playground is okay, but I think that web apps are not only about creating widgets, it's about displaying data, and for data you need a server. Also the contribs, why I need to compile the contribs into my application? I think that the simple solution like 'download & play' will be great. Look at jQuery for example, and focus at their download counter (zillion of downloads). I think that this is what qooxdoo needs in the future, more users and fast way how to setup development environment and play with it. > I think the main problem here with QxBuild is that it doesn't provide > any help to compile and package up the custom code of the plug-ins. But > it is a valid example of putting up a custom build nevertheless. Qooxdoo toolchain doesn't provide this too;) I think that 'parts' are not plugins. -- Best regards - Petr Kobalicek <http://kobalicek.com> On Mon, May 10, 2010 at 6:41 PM, thron7 <[email protected]> wrote: > > > On 05/10/2010 05:59 PM, Petr Kobalíček wrote: >> Hi, >> >> I solved exactly this problem using QxBuild, building qooxdoo as one >> big file without the application. I think that it's tricky, but still >> possible (Note that I'm not using generator for our .js files) >> >> http://code.google.com/p/qxbuild/ >> >> QxBuild is only set of config files, I think that it can be >> inspiration for you:) > > I think the main problem here with QxBuild is that it doesn't provide > any help to compile and package up the custom code of the plug-ins. But > it is a valid example of putting up a custom build nevertheless. > > T. > > >> >> Hope that helps >> >> - Petr >> >> On Mon, May 10, 2010 at 3:56 PM, Qoo Goo <[email protected]> wrote: >>> Thanks Thomas, >>> >>> >>> >>> I already had visited those links, but none of them solve my problem (in >>> fact I've been digging into the documentation for a while last days, but no >>> clue...). >>> >>> >>> >>> We have already explored the possibility of using parts (and we use them), >>> but not for plugins, but as a good mechanism to let browser alone by not >>> loading unused application modules. >>> >>> >>> >>> Let me try to explain more deeply the scenario: >>> >>> >>> >>> - We have developed an application and it is been distributed to our >>> clients. It is a standalone complex application (around 2MB in the build >>> version). We have experienced using Parts not to load some modules of the >>> application if they are not used and it is fine. It works really well. >>> >>> >>> >>> - What we want is to give our partners the ability to develop extensions for >>> our application, so they can create new code for their customers or for >>> their selves and plug into the application. We (our boss in fact) do not >>> want to give them the whole source code of our application, as we want to >>> keep only one core version of it and avoid forks that may break some >>> compatibility. So, they must develop "offline", I mean, without access to >>> original config.json and building process. >>> >>> >>> >>> They will have the API documentation and therefore, they know what classes >>> are in our applications and what classes not. So, they can include Qooxdoo >>> classes not present in our base if they need them in their code. >>> >>> >>> >>> With 0.7 generator you could build some pieces of code into a one "compiled" >>> file. Then we could install this file and their resources together with main >>> code by just copying them to the web server and download items at execution >>> time with the mechanism I said in my first email. >>> >>> >>> >>> So, the question I tried to ask is: >>> >>> >>> >>> Is there a way to compile a piece of code without putting it together with >>> the whole application source code (and not having access to this source >>> code)? >>> >>> >>> >>> I am not sure if it is clear, but the main point is to let third party >>> developers create extensions for our software, keeping the main trunk not >>> accessible directly. >>> >>> >>> >>> Regards, >>> >>> >>> >>> Al >>> >>> 2010/5/10 thron7 <[email protected]> >>>> >>>> Hi, >>>> >>>> as you might have gathered from the wiki page, the idea of packages has >>>> been carried further. The lingo has shifted a bit, the basic construct >>>> is now called a 'part', but the fundamental idea has been retained, as >>>> it is expressed on the 0.7 manual page: To split out parts of the >>>> application into own packages that can be loaded on demand. >>>> >>>> As you have migrated your application to 1.x, you already have a >>>> config.json in your application directory. This is the main tool to >>>> configure your application's build process. The main key for you to >>>> integrate is the 'packages' config key [1]. [2] has an overview of the >>>> part documentation, and [3] is probably what you are looking for. It is >>>> also necessary that you modify your class code to load parts in the >>>> appropriate situation during run time (explained in [3]). >>>> >>>> Have a look at the standard Feedreader application [4], which uses parts >>>> in a straight-forward way, and has corresponding configuration features. >>>> >>>> HTH, >>>> T. >>>> >>>> [1] >>>> http://qooxdoo.org/documentation/1.1/tool/generator_config_ref#packages >>>> [2] http://qooxdoo.org/documentation/1.1#specific_topics >>>> [3] http://qooxdoo.org/documentation/1.1/parts_using >>>> [4] >>>> >>>> http://qooxdoo.svn.sourceforge.net/viewvc/qooxdoo/tags/release_1_1/qooxdoo/application/feedreader/ >>>> >>>> On 05/10/2010 01:31 PM, Qoo Goo wrote: >>>>> Hello, >>>>> >>>>> After a migration from a complex application based on Qooxdoo 0.7 to >>>>> 1.x, we are now trying to figure out how to reimplement our plug-ins >>>>> mechanism. >>>>> >>>>> We were using our own mechanism server-side and in client-side we based >>>>> our plugins architecture in the contents of the article in >>>>> http://qooxdoo.org/documentation/0.7/split_up_application. Fortunately >>>>> this mechanism to inject code at runtime still works, but the problem we >>>>> are facing now is the building process for those extensions. >>>>> >>>>> The building instructions on that page do not work any more, and we've >>>>> been trying to build this extensions with now success until now. >>>>> >>>>> Are there some guide to build something that is not a whole standalone >>>>> application, but just an extension for an existing application? >>>>> How would you build a sort of classes without including those code >>>>> already used in main application and including resources as needed? >>>>> >>>>> Thanks in advance. >>>>> >>>>> Al >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> qooxdoo-devel mailing list >>>>> [email protected] >>>>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> qooxdoo-devel mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> qooxdoo-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >>> >>> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> qooxdoo-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >> >> > > ------------------------------------------------------------------------------ > > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > ------------------------------------------------------------------------------ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
