Christian, > I have a class that I develop in the normal qooxdoo filesystem/class > structure, but which is not included into the source/build versions. > Instead, it is loaded separately on demand as a plugin. This means, it is > outside of the generator system. The reason is that I want to be able to > develop classes as plugins to distribute them separately from the > application. The classes are then loaded after the qooxdoo system has > finished loading.
interestingly, some colleagues are working on a target goal in-house. The interesting question is how to do the "late binding" at run time. > A file typically looks like this: > > [code] > <snip> > [/code] > > When I do ./generate.py translation, the string "Import from library > catalogue" will be picked up by the generator and included into the de.po > file where I can translate it. However, when the plugin is loaded, the > string is not translated. 'generate.py translation' takes a simple approach of scanning right through the classes that are in the current library, ie. the classes found in the current 'source/class' path. That means that all translatable strings found make it into the .po files. The 'source' and 'build' jobs on the other hand pick and choose from the current classes only those that will be necessary for the build at hand. Therefore, only *their* transl. strings will be considered. In general, it is a good idea to think of a class not only being defined by its code, but also by the resources it uses (images etc.) and transl. strings it depends on. All these things together constitute the "properties" of a class. So if for example your plugin would use a specific image for its button, that image would *not* be available in the main app automatically. Same issue. > Of course, the whole idea of a plugin is that it can be shipped > separately, > so including the translation in the main app is somewhat arkward, but for > the moment, that would be ok if only the app would actually translate the > plugin's messages. > > Do you see any reason why it isn't - and maybe have an idea how to better > solve the task of translating plugins? So the issue is to somehow make the "non-class" dependencies of the plugin available at run time. I see two ways of doing this. One, as you pointed out yourself, is to force the main application to carry everything necessary with it, so it is present when the plugin arrives. In the case of transl. strings you can achieve this by adding the same keys that the plugin uses to the main app, e.g. using 'marktr()' calls. In the case of images you can achieve this by additional #asset hints. The other way would be to make the plugin carry everything it needs with it. But then a simple class file won't do. The answer would be a qooxdoo "package" [1][2] which is a .js file that has both a data and a code section. So far, packages have not been exposed directly to the application developers, only as a building block for parts. But at least the creation of such a package should be easy in your case: Just define a dedicated "application" for your plugin, best by providing its own config.json, e.g. as "plugin.config.json" alongside the normal config.json of the main app. Use the "include" and "exclude" config keys to limit the scope of this application to just your plugin class. Also, add a "packages" key to this config, in it add a "boot" part and specify "loader-with-boot" = false. Then, when you do a generate.py build it will create a loader .js and a separate plugin-0.js file. Ignore the loader file, and you have a package that contains your plugin code plus all additional information like resource info and transl. strings! The next issue is how to load this package at run time. Just using XHR won't be enough, as the data that comes with the package has to be included into the qooxdoo run time system. E.g. transl. strings are integrated with the translation manager. But naturally there is support for all this in qooxdoo, as packages are also processed when a part is loaded. We just don't have a public API to load packages directly. I haven't tried this myself, but the qx.io.part.Package class has the necessary infrastructure to load a package (e.g. Package.loadClosure which is usually what you need for a qooxdoo package). You might want to look into that if you go that way. Ok, so much for this. I hope you can make some sense out of it. If you have further questions, get back. T. [1] http://qooxdoo.org/documentation/1.1/parts_overview [2] http://bugzilla.qooxdoo.org/show_bug.cgi?id=2350 ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
