> Thon,
>
> Thanks for the quick reply. Before I provide any answers I would like to
> thank you for qooxdoo. I have been converting a Pro*C rf warehouse
> application for almost a year and I could not have done it without
> qooxdoo.
> Very nice work by everyone involved.
Thanks.
>
> I did read the manual and looked through the feedreaded app, but that
> doesn't necessarily mean that I understood everything.
>
> Instead of posting the configuration (besides it being ugly, it is still a
> work in progress) I would like to describe what I am trying to do. The
> application has almost 100 different "screens" in it which rf operators
What is an "rf operator"?
> can
> use to run a warehouse. The final qooxdoo build script was a little over
> 1.8Mb so I thought I would try using parts since there are some very
> esoteric screens which are seldom used.
Sounds reasonable.
>
> In my first attempt I included ${QXTHEME}, the Application and all
> "commonly" used classes (error message handling, dialog boxes, function
> key
> handling, widget subclasses, ...) along with the previously mentioned
> static
> class into the "boot" part.
It's better to only list the minimal set of classes, usually the theme and
the application class. Don't overspecify what is otherwise found through
dependencies anyway.
> I then defined 27 other parts -- this was
> just
> a first attempt and needs refinement. I realized very quickly that I was
> not getting anywhere with the large associative array in the static class
> so
> I changed it to be initialized by a member of the class and invoked this
> function in Application right after logging is enabled.
So you shouldn't need to list the static class in the 'boot' part.
>
> At this point I was able to generate source with no errors and all 28
> parts
> defined,
This is where the wobbly part begins. The generator output says a lot when
generating parts. Where all parts listed in the output? Or was there e.g.
messages saying "ignoring part" or something?
> so I decided to give it a try just to see if the boot loaded. I
> have not yet added any code to call the partloader since I had assumed
> (possibly incorrectly) that at least the boot should load and then I would
> know that I was on the right track.
You're right, the boot part should load anyway.
> This is where the error occurs,
> during
> boot loading. The very first error I get is "qx.data.SingleValueBinding
> is
> undefined"; then qx.core.Init shows being loaded; and finally that the
> static module is undefined so it cannot call the array initialization
> function.
This is very strange given the fact that you explicitly included the
static class in the boot part. I'm also rather suspicious concerning the
qx.data.SingleValueBinding class, as the generator is pretty meticulous in
checking that dependencies within the parts are fullfilled.
As I wrote previously, it all hinges on the definition of the parts. If
e.g. a class in some part other than boot uses the static class at load
time, this might violate part consistency.
> Can you provide any method I can use to debug the situation?
Check the generator output when creating the app. Make sure you follow the
instructions in the manual concerning part definition. Apart from that you
will need to run the generator with the -v comm.line switch, but this will
be then for me to analyze.
T.
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
