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
