On 06/20/2011 05:25 AM, Derrell Lipman wrote: > I thought there was a news article or something on using packages and > parts, but I can't locate what I'm looking for.
There were probably a few blog postings during the last 2-3 years that included parts and packages in some way. But usually the best place for standard topics like this is the manual: http://manual.qooxdoo.org/1.4.x/pages/development.html#parts > > I am building a type "basic" application for use with Rhino. I would > like for the generator to create multiple parts: a single part that > contains all of the qx.* classes that the application requires, a > single part for a all of the classes within a contrib that I'm using, > and then separate files (parts) for each class in my application's > namespace. Can someone point me to the documentation that shows how to > do that, or explain to me the config.json incantation to accomplish it? That's generally not possible. Parts are not good for partitioning classes "physically", meaning: according to name space. You should always give one or two classes has "head" classes of a part, and then let the generator figure out which classes in total have to be present in this part. This class set will usually be a mix of your own classes, framework classes, and potentially other library/contrib classes if you use them. This is necessary to ensure all dependencies are fullfilled within a part. The next then is for the generator to calculate packages from the parts. Packages are loading units, meaning if a package is loaded all of it is loaded, and contain 1-N physical .js files. Packages are organised such that the actual loading of code into the client allows only the needed classes to be loaded, but no less, so that all dependencies are fullfilled. The last step of the generator is then to merge packages so that the number of actual load requests is reduced, but still all constraints are observed. What you outlining might be possible, but only if you take care of load order and dependencies yourself (which might not be such a big issue). But it would also defeat the idea of parts, to load only necessary classes when you require a certain part. In your approach, e.g. all framework classes would have be loaded upfront, whether you need them later or not. There is a bug in our bugzilla that targets something like you describe (called "raw packages" in the bug): bug#2797. You probably want to particularly look at: http://manual.qooxdoo.org/1.4.x/pages/development/parts_using.html#in-depth-configuring-the-include-key-of-your-parts What do you want to achieve anyway? T. ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
