>> >>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...).
The build job is used for all apps in production, but it is managed on the fly so the libraries are deployed on a live site but only available to the build process; on dev the libraries are served direct from wherever they are. The CMS supports multiple websites and each website would typically have it's own library, including one or more classes derived from qx.application.*, plus have access to the core CMS library and other libraries (e.g. Contribs); an admin user can configure a page in the CMS to use a given Qx client class (derived from qx.application.*) and a Java server class. The CMS creates a temporary directory for the generator (i.e. the equivalent of create-application.py) and compiles it, build job or source job, on the fly. The temporary directory for the app exists to give the generator the minimum that it needs to do its work and it's class/Application.js exists only to pass compile time parameters to the client app (and if I can use qx.core.Environment for this, even the class/Application.js will be removed). Because everything has to be managed by the CMS and on the fly, managing that temporary app has to be as simple as possible and anyway there isn't usually one single app for the entire website - this is for security as well as usability, i.e. the site control panel and it's associated java object have more sensitive code than user apps, but the user app doesn't have it turned off - it simply does not have any of the code (client or server). (incidentally, there is a similar thing on the server - Qx classes are compiled on the fly into objects that run in Rhino, each site having its own library etc; there is no RPC yet for connecting server Qx to client Qx but only because I haven't had time, hence the use of Java classes on the server still) >>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 :). :) fair enough. >But there is still a config tweak you could try ;). Let me point you to >the underrated > >compile-options/paths/app-root I'll try that, thanks >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. OK I think I see now and it seems suddenly obvious - the build version gives the _illusion_ of supporting multiple libraries because it provides resources from those libraries. But in fact it's not because it _copies_ the resources it simply has them to hand in the app. Thanks for your help John ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
