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
