Hi Thomas, Thanks for your answer.
You are right, but in 0.7 you had the option to compile only a set of files by executing: tool-0.7.4/generator.py --class-path source/class --generate-compiled-script --compiled-script-file build/your_file.js --optimize-variables --optimize-base-call --optimize-private This does not get dependencies, but it creates a single package with all code which is useful I think. You must, then, ensure you have all necessary base classes in you core. This still works for us, but some problems arise (including assets, for example). So, I think that with a bit of work we could have a 0.7 toolchain working fine for our goal by just letting old tools create the package for the plug-in, but this solution leaves us in a not much stable situation. The last approach we have taken is as follows: - For internal plug-ins (those developed by us) we use the PartsLoader mechanism. We have achieved this with a few changes to our plug-ins mechanism and this allows us to develop as we were just extending the core. Everything keeps integrated. - For external plug-ins (those developed by our partners / clients), we will try to apply the approach you tell us. As you say, it is not the best way for working (and not the way I personally would be happy with if I was a client or partner), but honestly I do not figure out a better way to let them develop extensions without having access to the main trunk of source code, and this is unfortunately a requirement. I will let you know if we find a more elegant way. Thanks, Al 2010/5/10 Petr Kobalíček <[email protected]> > > 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
