Hi,
wow...that´s what I call a sophisticated answer.
I will heed your advice, Sir. :-) As soon as possible I will redesign
the parts. Well, "redesign" is too excessive as there are actually just
2 parts, so it´s not too much work.
But by now I have to read your answer once again and try to understand
*everything*. ;-.)
Thank *very* for taking so much time,
Rob.
>>> thron7 <[email protected]> 12/13/2010 5:49 >>>
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
------------------------------------------------------------------------------
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
