Java RPC On Sep 15, 2009, at 12:14 , Petr Kobalíček wrote:
> [OT] What RPC server are you using for qooxdoo? > > 2009/9/15 Jean-Baptiste BRIAUD -- Novlog <[email protected]>: >> OK, I managed to make the default app working as I wanted : source in >> the web server all in my favorite IDE. >> The only thing that was not correct on my side was the settings of >> the >> documentRoot. >> Do not set the documentRoot inside source, but just one level above, >> so it include source. >> >> While documented in the URL provided by Thon7, this is really >> disturbing and counter intuitive since it will change all URL at >> runtime >> (http://localhost:8080/myapp/source instead of usual >> http://localhost:8080/myapp) >> Maybe this could be improved by letting, optionally, the possibility >> to set the QOOXDOO_PATH under the webserver, so this can be different >> at build-time and run-time. >> >> Anyway, its working both source and build using Tomcat on a powerful >> IDE, so, I'll start migrating our code to 0.8.3 and to python build. >> Still have to test RPC in that context, but it should be OK. >> >> Thanks ! >> >> >> On Sep 15, 2009, at 10:25 , Jean-Baptiste BRIAUD -- Novlog wrote: >> >>> >>> On Sep 15, 2009, at 09:59 , thron7 wrote: >>> >>>> >>>> >>>> Jean-Baptiste BRIAUD -- Novlog wrote: >>>>> Hi the list, >>>>> >>>>> 0.8.3 is out and I decided it could be a good time to give the >>>>> qooxdoo >>>>> python build a chance. >>>>> >>>>> Unfortunatly, I'm not able to make it work in my environement >>>>> after >>>>> hours of work. >>>>> >>>>> On the command line + vi, it works fine and I think I now >>>>> understand >>>>> the difference between generate source and generate build. >>>>> >>>>> In the config.json, the QOOXDODO_PATH had to be set. >>>>> This, as far as I understand, set both the build-time path from >>>>> generate.py to the SDK and also at the samz time the run-time path >>>>> to >>>>> the SDK under the web server. >>>>> >>>> >>>> Nope, it doesn't. The structure of a source version of a qooxdoo >>>> app >>>> is >>>> simple: the generated .js script just references all the necessary >>>> class >>>> files and resources (like images) *through relative path URIs*. >>>> It's >>>> best to run the source application in the browser from the file >>>> system >>>> (with a file://... URL). The source version is not meant to be run >>>> from >>>> a web server. >>>> >>>> If for some reason you are forced to run the source version from a >>>> web >>>> server (and you should make sure it is really necessary), >>> The reason (maybe bad, let's clarify that) is the Java backend for >>> that application. >>> Will I be able to launch RPC request on a qooxdoo application >>> launched >>> from the file system ? >>> >>>> than you have >>>> to comply to some constraints. Basically, the web server's document >>>> root >>>> has to encompass both your app and the qooxdoo SDK. See this >>>> piece of >>>> information for details: >>>> http://qooxdoo.org/documentation/0.8/snippets#running_a_source_version_from_a_web_server >>>> >>> That's excatly the problem : to produce the application, generate.py >>> look for the sdk from QOOXDOO_PATH variable. >>> Then it is wrongly assume that later, at runtime, the SDK will be >>> at a >>> place that correspond to QOOXDOO_PATH. >>> But that's wrong in our config. The path at runtime is different so >>> I'd love to find in the config.json 2 variables : >>> * one for specifying to generate.py where is the SDK to find the >>> generator.py and all the ressources >>> * one to take into account in the generated application for the >>> URI od >>> the SDK at runtime eventually behind a web server. >>> >>> >>>>> This doesn't matter for generate build because qx classes are >>>>> embeded >>>>> but this make for me the generate source to fail (or source-all, >>>>> not >>>>> sure about the differences). >>>>> >>>> >>>> Yep, run it from the file system and you'll be fine. >>> Not sure, see above for why runnig from file system may not work for >>> us. >>> >>>> The 'source-all' >>>> build variant just allows you to develop your app with less >>>> re-compilation, as it always references all know classes, >>>> independent of >>>> what you are actually using in your app. This makes the app bigger >>>> during run time, but saves you some 'generate.py source' runs. >>>> >>> OK, good point, this is now clear. It'll be useful. >>> >>>>> In fact, in my case, the SDK do not have the same path at build- >>>>> tima >>>>> and at run-time. >>>>> >>>> >>>> You shouldn't have to maintain two SDKs in your environment. Use >>>> one, >>>> and tweak the web server config so it appears the same relative to >>>> your >>>> app on both the file system and the web server's document forrest. >>>> >>> No, it's not 2 SDK : it is only one but can't be the same path from >>> file system (generator.py) and runtime. >>> It is also important to note it is not a simple web server but a >>> Java >>> web container : tomcat. >>> This make a big huge difference, as alias for example are not >>> possible ! >>> In production env, we'll have Apache AND Tomcat, but this is not >>> possible on dev machines. >>> >>>>> I also see that the generate.py is a kind of proxy to >>>>> generator.py, >>>> >>>> That's right, you can invoke generator.py directly if you like. >>> Does it change something ? Could that make QOOXDOO_PATH only useful >>> for runtime ? >>>> >>>>> is >>>>> there a way I could move the SDK by removing the need os using >>>>> config.json QOOXDOO_PATH variable look like to have to usage ? >>>>> >>>> >>>> I'm not sure I'm getting this. But there is no need to move the >>>> SDK, >>>> and >>>> it would be rather tedious. The QOOXDOO_PATH variable in the config >>>> has >>>> to point to a valid SDK but this is only necessary while you are >>>> running >>>> the generator. In the generated apps, only the source version >>>> encapsulates this knowledge in the generated URIs. >>>> >>>> >>>>> By doing that, I hope I'll be able to set the path only to the >>>>> run- >>>>> time place of the SDK ... >>>>> >>>> >>>> As I said before, just tweak your Apache or whatever you use, if >>>> you >>>> really need to run the source version from a web server. >>> I can place the SDK under the web root without problem, but not at >>> the >>> same deep level, so the generated URIs look like wrong at runtime >>> even >>> if the QOOXDOO_PATH is correct at generation time. >>> I'm not sure if my explanation is clear :-) >>> >>> Thanks ! >>> >>> ------------------------------------------------------------------------------ >>> Come build with us! The BlackBerry® Developer Conference in >>> SF, CA >>> is the only developer event you need to attend this year. Jumpstart >>> your >>> developing skills, take BlackBerry mobile applications to market and >>> stay >>> ahead of the curve. Join us from November 9-12, 2009. Register >>> now! >>> http://p.sf.net/sfu/devconf >>> _______________________________________________ >>> qooxdoo-devel mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >>> >> >> >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry® Developer Conference in SF, >> CA >> is the only developer event you need to attend this year. Jumpstart >> your >> developing skills, take BlackBerry mobile applications to market >> and stay >> ahead of the curve. Join us from November 9-12, 2009. Register >> now! >> http://p.sf.net/sfu/devconf >> _______________________________________________ >> qooxdoo-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel >> > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart > your > developing skills, take BlackBerry mobile applications to market and > stay > ahead of the curve. Join us from November 9-12, 2009. Register > now! > http://p.sf.net/sfu/devconf > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
