On 05/10/2010 03:56 PM, Qoo Goo 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.
Ok, Al, I guess I get your requirement. Let me say a few things: - It would have been difficult to achieve this with the 0.7 tool chain, since 0.7 allowed you to compile a set of classes *together with their dependencies*, which then you need to exclude explicitly. - Essentially, this hasn't changed. You have the 'include' and 'exclude' config keys, to tailor a set of classes you want in the build. But there are several things to be aware of: - Your partners would need an exact list of classes already loaded with the main app, so they can exclude them in their build, so there won't be any class duplicates. You could cater for that by providing a custom config.json, or complete skeleton, to your partners that fixes that. Take a look at the 'bom' skeleton from the qooxdoo SDK (run 'create-application.py -t bom -n sample'). - This config would also need to provide a part definition. Only the boot part is necessary, but then you can add the packages/loader-with-boot:false setting, so the class code is split from the loader code (as you don't want general loader code to go with the plug-ins). This would create a valid qooxdoo package. Beware that this means it starts with a qx.$$packageData section which needs to be registered with the qooxdoo run time, if the plug-ins carry individual information about resources (images) and translation/cldr data. (You might then best use qooxdoo's PartLoader infrastructure, e.g. qx.io.part.Package.loadClosure() and .execute). - That would allow your partners to develop classes and wrap them into custom builds, and you to load them into a running application. I presume you have some sort of plug-in API defined, by which the main application finds and integrates the foreign code. - Your partners will *never* be able to test their plug-in until it is integrated with the main application (which would be kind of a weird way to develop software). Does that answer your questions? T. > > > > Regards, > > > > Al > > > > 2010/5/10 thron7 <[email protected] > <mailto:[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] > <mailto:[email protected]> > > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > > ------------------------------------------------------------------------------ > > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > <mailto:[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
