3

I am trying to use Clojure + Compojure + Ring in combination with the qooxdoo JS library. This is actually going well, but qooxdoo runs in two modes "build" (that works for me) and "source" (not so good). In the latter case, the JS generated by qooxdoo actually hardcodes references (well, using relative addresses ../../..) back to the qooxdoo installation and at run time it asks for sth like:

http://localhost:3000/opt/qooxdoo-5.0.1-sdk/framework/source/class/qx/bom/client/OperatingSystem.js

...since I have the library installed under /opt/qooxdoo-5.0.1-sdk.

Serious sanity check: if I directly open the index.html in the browser, it works fine. So it seems I just have to figure out how to serve the static files under the /opt library install.

I have tried wrap-file from the ring.middleware.file because that sounds like what I want but no matter what path I give it I get hundreds of 404s as it tries to pick up each framework file individually from the installed library.

I can work OK under "build" (qooxdoo cobbles together a single minified .js I serve with wrap-resource) but on occasion I need to run in source mode to find JS bugs.

Am I missing something simple?

kennytilton
  • 994
  • 1
  • 6
  • 16

4 Answers4

2

The correct way to handle this is to configure Qooxdoo to tell it what URIs you would like to use - by default the source build does just use relative paths, but you can easily override this by editing the config.json.

In your config.json you will have a "jobs" section containing a "libraries" section, containing a "library" array - your application is a library, as is Qooxdoo, as is any contribs so it will look something like this:

"jobs" : {
   "libraries" : {
        "=library" : [ {
            "manifest" : "${QOOXDOO_PATH}/framework/Manifest.json"
        }, {
            "manifest" : "Manifest.json"
        }
   },

Each "library" object can have a "uri" property, so for your example you probably want something like this:

"jobs" : {
    "libraries" : {
        "=library" : [ {
            "manifest" : "${QOOXDOO_PATH}/framework/Manifest.json",
            "uri" : "/opt/qooxdoo-5.0.1-sdk"
        }, {
            "manifest" : "Manifest.json"
        }
    },
johnspackman
  • 980
  • 4
  • 10
0

Simple indeed: (wrap-file "/")

In development/source mode qooxdoo works off the installation directory instead of code pulled into my local tree, and does so by hardcoding relative paths that resolve to an absolute /opt/qooxdoo-etc path.

This looks to the server like a relative "opt/qooxdoo..." file request, so I had to offer root ("/") as a search directory.

kennytilton
  • 994
  • 1
  • 6
  • 16
  • Sorry if this seems obvious, and I am pretty sure I tried it at some point in my thrashing, but apparently not or in combination with a different flaw. – kennytilton May 11 '16 at 04:45
0

(wrap-file "/") is a serious security issue since you're offering the root directory for all.

What you can potentially do is to make a dedicate directory to server your static file, and serve your content from there.

su
mkdir -p /var/clojure/static/opt
cd /var/clojure/static/opt
ln -s /opt/qooxdoo-5.0.1-sdk qooxdoo-5.0.1-sdk
chown -r YOUR-USER-ID /var/clojure/static/opt 

And use the middleware: (wrap-file "/var/clojure/static") to serve your file.

Thach Mai
  • 915
  • 1
  • 6
  • 16
0

There is a section in the manual that deals with the issue of serving a source version through a web server.

I guess you found the basic insight yourself, that the web server must export a root where the relative paths used in the generated loader match URL paths under that web server. (The rational behind this is that the source version uses all the JS files from all involved libraries directly from disk.)

In the worst case that might mean you need to export the file system root ("/") from your web server. As you are doing this on a local development machine this shouldn't be much of a problem. If security is a concern you might want to collect your qooxdoo environment under some innocent path like /home/kenny/devel/qooxdoo, containing the qooxdoo SDK, your app, and all libs/contribs you might be using.

If you follow the above link you will also find some help from the qooxdoo tool chain. E.g. if you run generate.py source-httpd-config[*] it will tell you which path on your local disk is the closest parent directory that will encompass all necessary libraries, i.e. needs to be exported in your web server for the source version to work.

Alternatively, as John wrote you can export each qooxdoo lib through an individual path under your web server, and then tell your main application where to find it. You might actually need to give a proper URL like http://localhost/libs/qooxdoo-5.0.1-sdk/framework, not just a file system path as John suggests. Also remember that you have to go as far as the directory where the Manifest file resides (hence the above path ending in .../framework). See this manual section for a deep dive.

ThomasH
  • 22,276
  • 13
  • 61
  • 62