On 07/26/2011 09:41 AM, John Spackman wrote: > Hi Thomas, > > The docs say that the key is "script" but you mentioned > "compile-options/uris/source" in an email in february
That was then an error on my side. The docs are usually authoritative for what they cover :). > so I thought I'd test for any possible typos before asking… but I had > missed that the script key only applied to build. I guess I was tired > and rushing when I read it, apologies… No worries. > > I'm aware that the Uri for libraries can be set (I use it in every > app) and that's a really useful feature because our URIs have little > relation to where on disk a particular library is stored; the same is > true for our apps, that the location on disk does not necessarily > relate to the URI in the address bar – this is because the app is > created on the fly by content management. Until Qx1.5 there was only > one file that was served from the source/script and if you don't use > the generated index.html (we don't), that can be easily overridden but > now there are other files from source/script this is a problem for us > during development. Mh, does that mean you deploy entire libraries? Do you ever generate a build version of the final app? (Just being curious...). > > I've solved my problem by providing a decode-uris-plug script but I'm > curious – why does source job not support custom uris for the > application when the build job does? Simply put, because we never anticipated that someone would fiddle around with the source version that much :). The general idea when introducing the generator was to favor "convention over configuration" (a mantra common in the RoR world). But there is still a config tweak you could try ;). Let me point you to the underrated compile-options/paths/app-root It takes a path. The given directory will be regarded as the directory holding the index.html (the default for the source version is unsurprisingly "./source"). This value is then used to calculate the *relative URIs* - and I mean, all of them. They will all be relative to this directory. This includes the paths to the involved libraries, but also the path to the 'script' directory that has the generated JS files. - I'm not sure but that might solve your issue. > An application is very similar in concept (and presumably > implementation in the generator) to a library You're right, these concepts are interchangable. "Everything is a library" in qooxdoo. > and I don't understand the logic that says that the resource and > script URIs will _always_ be relative to the web page that invoked the > app when in development but could be anywhere when deployed. That's not quite right. Also in the deployed app the URIs are relative to the web page - there is no other way to load resources through a browser (unless you resort to absolute URIs). But there is a distinct difference between source and buid version as far as URIs are concerned: The source version expects qooxdoo libraries, the build version does not. So the source versions view of the world is a directory where the "index.html" lives, and libraries somewhere on the disk. If the source version looks for class code, or an image, it calculates the relative URI to the containing library, and then following up on that evaluates the library's 'class' and 'resource' manifest properties to find the desired file. The build version only cares about a single "library", and that is not a proper library in the real sense. It is not related to any of the true libraries on disk that fed into the build version. Basically, it is what is under the 'build' directory. Everything is generated, and the interesting bits are the 'script' and the 'resource' sub-directories. And altough you could copy the build directory to any place and run the app, you can tear 'script' and 'resource' apart. And as there were projects doing this (e.g. by having the images on a different server than the script files), we provided 'uris/script' and 'uris/resource' keys for the build version. > Isn't it normally the other way around, ie that for deployment you > package everything up into as small and discrete package as possible? Mh, not sure... How about "as complete and compact as possible"?! T. ------------------------------------------------------------------------------ Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
