> Still, QxBuild is not part of the official qooxdoo release, and the bom > application is just an example that it's doable. Not every developer wants > or can afford to develop a custom builder (I for one would love to, but am > too time-constrained).
What more does it take than including a few name spaces in config.json, and excluding a few others?! > Besides, there's the problem of standardization. A standardized way of > packaging and deploying plugins/libraries of Javascript/qooxdoo classes on > top of a basic qooxdoo-based bootstrapper would allow plugins/libraries of > independent programmers to interact - a qooxdoo ecosystem could develop > much faster than contribs which must be compiled into your source code > would ever allow. But what would be the standard, then?! What would be in the bootstrapper? Just for an example, would it contain qx.ui.embed.HtmlArea? Sure this is a widget you only include if you are sure you are going to use it, but would you know this for all potential plugins?! Would it contain qx.io.remote? Most people would want to use this as a communication layer, but only recently someone on the mailing list was absolutely adamant about excluding it. And while Petr is truly tolerant towards a few KB more or less in download size, others go nuts to squeeze out the last KB from their app. Where would be the standard?! > IMO, it's very much like the relation between old monolythic, C++-based > programs and programs for the JVM. Introspection, reflection and dynamic > class loading make Java apps running on the JVM a much nicer network > language. You don't have such features in monolything apps. Therefore I > assume you don't want qooxdoo apps to be closed, monolything apps. I agree with this analogy about static and dynamic binding. Yes, qooxdoo builds are in a sense created like static bound binaries. But we are working on new ways to address that, one of them was introducing a standardized package format, which might evolve further in the future, so packages could be useful and re-usable outside a confined application. Another thing we're exploring right now is how we could support packages that are created dynamically on the server. But it would still be a long way for something like this to make it into the standard distribution... T. > > Nevertheless, I can understand time and resource constraints. > > br, > > flj > > > ------------------------------------------------------------------------------ > > _______________________________________________ > 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
