Charles,
you have a rather unusual setup. Let me see if I can decode it a little:
In your other mail you write about the class "org.argeo.slc.web.TestList".
According to qooxdoo conventions the source of this class has to be in
path ending with
.../org/argeo/slc/web/TestList.js
So much so good. On the other hand, your config says that the path to the
Manifest of the containing library is (macros resolved):
src/main/webapp/argeo-ria-lib/slc-web/Manifest.json
Now, provided that you haven't changed the standard set up of the
Manifest.json file, the bridge to this library's class files is
'source/class'. So, putting this all together it adds up to
src/main/webapp/argeo-ria-lib/slc-web/source/class/org/argeo/slc/web/TestList.js
for the file path to the sample class file you've given. Since you say
the 'generate.py source' run goes through fine and the various libraries
are scanned correctly, I will assume the above file path is correct.
Now for the URIs:
Given the value of your compile-source/root key, the path to your
index.html must be:
src/main/webapp/argeo-ria-src/index.html
Then, in order to locate the above named TestList.js file relative to the
index.html, the URI for it has to be:
../argeo-ria-lib/slc-web/source/class/org/argeo/slc/web/TestList.js
(and not "argeo-ria-lib/class/org/argeo/slc/web/TestList.js" as you wrote
in your other mail), and the correct URI for the lib would be:
"../argeo-ria-lib/slc-web"
which is what you have in your config.json (macros resolved). Why the
actual generated URI to the TestList file would be
"./class/org/argeo/slc/web/TestList.js", as you write, I cannot say. Also,
I'm surprised to hear that it doesn't matter whether you supply the 'uri'
parameter in you config or not. Even if both versions would be wrong they
should at least be different. - Have you run generate.py source in
between? Can you simply post the console ouput of such a run ('uri'
parameter set)?!
Again, it is very uncommon to put the project's config.json in some
remote path that happens to be the common root for all local libraries,
and it's hard to say which side effects you run into. But it's also a nice
challenge to the build system :).
Thomas
Charlie wrote: Hi again
First of all, I've finally partly solved my problem with the migration to
0.8.1. It may be evident, but *i had not cleared the "cache"* between 0.8
and 0.8.1 and that was making python errors in the dependancyloader. If
anyone encounters the problem.. :-)
Now the build version is working good but.... the source is not!! Again,
I've checked and rechecked but it seems to me that in source mode, my
libraries URI are not computed correctly. I've tried skipping the "uri"
key (like it's now authorized in 0.8.1) or putting it back, there's no
way, the generated source does not locate correctly the classes that are
in the library, thus the application won't load. My libraries are defined
by me (not contrib ones) and located in a different folder that the one
containing the source.
Has anyone tested that?
Thanks
Charles
PS : Interesting parts of my config.json below :
"let" :
{
"APPLICATION" : "org.argeo.ria",
"QOOXDOO_PATH" : "src/main/webapp/qooxdoo-0.8.1-sdk",
"QXTHEME" : "qx.theme.Modern",
"QXICONTHEME" : ["Tango"],
"API_EXCLUDE" : ["qx.legacy.*"],
"LOCALES" : [ "en" ],
"ROOT" : "src/main/webapp/argeo-ria-src",
"BUILD_PATH" : "src/main/webapp/argeo-ria",
"RIA_LIB_PATH" : "src/main/webapp/argeo-ria-lib",
"RIA_LIB_URI" : "../argeo-ria-lib",
"CACHE" : "cache-0.8.1" ,
"CUSTOM_PACKAGE" : "org.argeo.slc.web"
},
"jobs" :
{
"common" :
{
"library" :
[
{
"manifest" : "${QOOXDOO_PATH}/framework/Manifest.json"
},
{
"manifest" : "${RIA_LIB_PATH}/slc-web/Manifest.json", "uri"
: "${RIA_LIB_URI}/slc-web"
},
{
"manifest" : "${RIA_LIB_PATH}/slc/Manifest.json",
"uri" : "${RIA_LIB_URI}/slc"
},
{
"manifest" : "${ROOT}/Manifest.json"
}
],
"include" :
[
"${APPLICATION}.Application",
"${CUSTOM_PACKAGE}.*",
"${QXTHEME}"
],
"cache" :
{
"compile" : "${CACHE}"
},
"settings" :
{
"qx.version" : "${QXVERSION}",
"qx.theme" : "${QXTHEME}",
"qx.application" : "${APPLICATION}.Application",
"ria.StartupPerspective":"org.argeo.slc.web.LauncherPerspective"
}
},
// -- source jobs --------------------------------------------------
"source-script" :
{
"extend" : ["common"],
"compile-source" :
{
"file" : "${ROOT}/script/${APPLICATION}.js",
"locales" : "${LOCALES}",
"root" : "${ROOT}",
"gzip" : false
}
},
Derrell Lipman (via Nabble) a écrit :
On Sun, Jan 18, 2009 at 10:36 AM, Charlie_fr > wrote:
But to
stick to the initial topic of this message, I've tried the close()
method
and terminate() method of my Application class, and it seem to me
that the
terminate() is still never called. Is the bug really verified for
0.8.1 ?
The close() method is working good.
It seems that at least in Firefox, the "beforeunload" event which causes
the close() method to be called gets fired, but the "shutdown" event which
is supposed to cause the terminate() method to be called does not. This
was tested by putting an alert() call in each of the low-level handlers in
qx.core.Init. Maybe there's some event other than "shutdown" that must be
listened for in Firefox, for an after-unload event.
Maybe you can make due with the close() method which is fired immediately
before the page is unloaded? What do you need to do that must occur after
the page is entirely unloaded?
Derrell
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-de...@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
------------------------------------------------------------------------
This email is a reply to your post @
http://n2.nabble.com/Window-unload-action-tp2161752p2177373.html
You can reply by email or by visting the link above.
------------------------------------------------------------------------------
This SF.net email is sponsored by: SourcForge Community SourceForge wants
to tell your story. http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________ qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
-- Thomas Herchenröder Core Development - Web Technologies 1&1
Internet AG phone: +49 (0)721 91374-4482 Ernst-Frey-Str.9 web
: www.1und1.de 76135 Karlsruhe qooxdoo.org Amtsgericht
Montabaur HRB 6484 Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias
Ehrlich, Thomas Gottschlich, Robert Hoffmann, Markus Huhn, Hans-Henning
Kettler, Dr. Oliver Mauss, Jan Oetjen Aufsichtsratsvorsitzender: Michael
Scheeren
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
