It's probably not that obvious, so don't blame yourself ;). Defining parts is still a bit tricky, I think the issue here is with overlapping dependencies.
It's probably not a good idea to define a part "chart" as you did. Let me explain a bit: In general, don't think in terms of libraries when you think about parts. You get best results when you think in terms of your main application and its logical/visual parts. In most cases this means you will list a class from your main application "heading" the part (e.g. representing the entire part you want to define), which goes into the part's "include" key, and let the dependency system figure out which prerequisite classes need to be included then. (Of course library classes themselves can head a part, it just doesn't feel very natural, though). Now, designing your parts takes a bit of consideration. The base line is: You must avoid overlapping classes with your parts' "include" keys, as the dependency calculation of the parts try not to include classes that are covered by other parts (see item "c." in [1]). But this is what I suspect happened in your app: You class ApPlanungsChartView has a dependency to AoISeriesCallback. If left on its own, it would just draw in this class. But as it is *explicitly* listed in the "include" of the "chart" part (after expanding the file glob of common.gui.chart.*), it is not added to the class set of the "grunddaten" part. So the part that actually needs the class yields to the supposedly stronger demand of the explict "include". The resulting "grunddaten" part is inconsistent as a consequence. (At this point, you might bemoan this working of the generator, and might righteously create an enhancement bug for it :)). If the "grunddaten" part would be loaded before the "chart" part in the application (which I presume), the AoISeriesCallback class wouldn't be available, although it would be available with the "chart" part. (BTW: ap.gui.globaleFunktionen.* covers sub-name spaces, so ap.gui.globaleFunktionen.alertdefinition.* and ap.gui.globaleFunktionen.verlaufskurven.* are both already covered; but it's no issue). The solution to me would be completely re-designing your parts. E.g don't create a separate part for the "common" classes, just because you know you're going to need them somewhere. Let the generator figure out when to include prerequisite classes. Also, don't create parts along some classification of classes, like "grunddate" or "globaleFunktionen". It's not about classifications, it's about when your application needs what during run time. Some "grunddaten" classes might need some "globaleFunktionen" classes to do their work, which in turn might require some "chart" classes to be available. Think more in terms of there are some classes you want to show at startup, and some only when the user follows a certain path through the application, like opening a detail view or an options dialog. Try to think about your application along this lines and you will get better results. As a first step, just throw out the "chart" part altogether, and see what happens (I could imagine you get the same problem then with classes from the "globaleFunktionen" part :)). T. [1] http://manual.qooxdoo.org/current/pages/tool/generator_config_articles.html#packages-key On 12/13/2010 03:27 PM, Robert Nimax wrote: > Hi Thron, > it says: "Unfullfilled dependency of class > 'ap.gui.grunddaten.planung.ApPlanungsChartView'[2]: > 'common.gui.chart.AoISeriesCallback'" > AOISeriesCallback should be included in the file glob > "common.gui.chart.*". Well....it´s an interface, not a class, but I > don´t think, it´s the problem, is it ? :) > Now "ap.gui.grunddaten.planung.ApPlanungsChartView" belongs to another > package by the name of "grunddaten". Maybe the order of the packages is > wrong. So I removed the package "grunddaten" to exclude this problem. > But then it says: "Defining class not included in part: > 'common.gui.chart.AoIChartDataMapper'". > I KNOW, there is a simploe solution, but I just do not see it. :-) > Thanks a lot ! > Rob. > >>>> thron7 <[email protected]> 12/13/2010 1:59 >>> >> As you can see (namespace "common" ), the "chart" package is the problem. >> So what is my mistake ? :) > > Rob, which dependency exactly is reported as unfullfilled? I.e. which > class needs to be included to make the thing work? Is this class covered > by the "common.gui.chart.*" file glob? > > T. > > ------------------------------------------------------------------------------ > Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, > new data types, scalar functions, improved concurrency, built-in packages, > OCI, SQL*Plus, data movement tools, best practices and more. > http://p.sf.net/sfu/oracle-sfdev2dev > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > > > ------------------------------------------------------------------------------ > Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, > new data types, scalar functions, improved concurrency, built-in packages, > OCI, SQL*Plus, data movement tools, best practices and more. > http://p.sf.net/sfu/oracle-sfdev2dev > > > > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel ------------------------------------------------------------------------------ Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
