Hi Thomas
I am indeed running an unusual setup, that I will try to explain more
clearly here.
The simplest would be that you browse the arborescence directly in SVN
(it's an open source appli & ignore the ssl error) :
https://www.argeo.org/svn/slc/trunk/org.argeo.slc.webapp/
See also my previous mail about the bug I think I found.
What you will see :
+ config.json : the config file for the whole application
+ src/main/webapp => the source directory, containing various libraries
+ argeo-ria-src/ => the main "application-type"
library (NS : org.argeo.ria), containing the started Application
(extending Standalone class)
+ argeo-ria-lib/ => "customer" libraries in which
one must declare at least one IPerspective implementation so that the
main Application can start.
+ Currently defined library are sample
(NS : org.argeo.ria.sample), slc (NS : org.argeo.slc) and slc-web (NS :
org.argeo.slc.web)
As you can see, it's a kind of Eclipse architecture (no I swear I'm not
developing RAP again!! :-) ), where the argeo-ria-lib will contain as
many "plugins" as needed. Those plugins can declare their own namespace
in a java-style naming convention, and thus you can find various ones
beginning with "org.argeo" for example.
To keep with the TestList example, the TestList class is indeed found in
the slc-web library, not in the "application" library.
I hope it's more clear now, and in my opinion it's not that unusual (ok
ok it's not standard), but it's just leveraging your powerful library
system that I was so happy to use!
Thanks again for this great work, tell me your thoughts
Charles
thron7 a écrit :
> 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
>
>
>
------------------------------------------------------------------------------
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
