2009/11/2 thron7 <[email protected]>: > > > >> I don't get how to define this in the config file. Basically it's just >> another type of dependency. We also do not lost depencies of classes >> in the configuration. > > Oh, yes we do, just remember the "require" config key.
Oops, yes I overlooked this. But I wonder: is really anybody using it? Just because it's there, does not mean that it's good to be there. ;) Most stuff is more easily resolvable in the client side code. As with the automatic detection of dependencies to other classes, with support for variants and assets, it is much more powerful. > >> Just the top-level includes. > > And I consider these "external" libraries also top-level. The problem might be here in more complex apps. We use, for example, one tree of classes for different platforms and products. This external lib dependencies would be easily handleable in our client side code in the same way we do it with other classes and resources. Moving this to the config makes it impossible to use it for us, as our config is pretty generic and just differs in a set of variants. Nothing else. I just want to came up with a practical example as I can already see that this will not help us, and may also not help others. It may be enough for your internal requirements - that for sure. And it may be easier to first implement it in your suggested way. Nothing to say against this. But it does not completely solve the issue of the bug. > >> Especially >> regarding variants etc. it might be useful to have this in the code >> instead of the configuration. It's more flexible IMHO. >> > > That might be something to think about at some point. But compiler hints > are also variants-ignorant, so they are not very flexible too in this > regard. What do you mean by compiler-hints? > >> Keeping it at class-level might also help when thinking of resources >> e.g. assets which could be integrated using the already available >> #asset hints. >> >> Maybe this means a pseudo helper class for every external lib, but >> still might be better than placing it into the config. >> > > I think the config is good place to start as this is a major change in > the semantics of the build system. Better than hiding it somewhere in > class code. Mind that alternatively these libraries go into the index.html. We currently do it with wrapping the original class into a qooxdoo class file and using this file for dependency injection. Until this is support is based on code inside the classes I think we keep using this approach. Sebastian > > T. > >> > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
