Matthew Gregory wrote:
> Hi All,
> Has this changed? I've just tried porting from beta1 to rc1 and it's
> broken :( I've searched the mailing list and bugzilla but couldn't find
> anything.
>
> Here is a copy of my config file:
>
> {
> "name" : "custom",
>
> "include" :
> [
> {
> "path" : "../qooxdoo-sdk/tool/data/config/application.json"
> }
> ],
>
> "let" :
> {
> "APPLICATION" : "custom",
> "QOOXDOO_PATH" : "../qooxdoo-sdk/framework",
> "QOOXDOO_URI" : "qx",
> "QXTHEME" : "qx.theme.Modern",
> "LOCALES" : [ "en" ],
> "ROOT" : "."
> }
> }
>
> As you can see the QOOXDOO_URI should be "qx", I have this set as a
> virtual directory in my web server pointing to the sdk. But after a
> "generate source" I find this in my custom.js
>
> uris : [["../../qooxdoo-sdk/framework/source/class/qx/Bootstrap.js"...
>
> Has something changed?
>
Indeed, it has... Mh, not sure what to think of it. Well, these are the
facts:
For one thing, this only affects 'source' versions of a project. The
'build' versions are self contained, all classes are compiled into .js
packages, so there is no need for uri's to find classes. Maybe that
eases the following explanations.
The only reason for the QOOXDOO_URI macro was to use it in the 'uri'
member of a library entry (for the framework, in this case). These uri
members were error-prone, easy to get wrong, but also easy to compute.
All our use cases used relative paths to the libraries in their 'uri'
fields. But since we had the path to its manifest, the 'uri' was easy to
derive programmatically. In some cases these relative 'uri' values were
even half-wrong, namely if you had an application with various
application HTML files living in different paths (We have this with
Demobrowser, Testrunner). They wanted to use the same library, but with
differnt uri's, so a single value could't suffice. But it was easy to
compute for the different parts of the application individually.
So we decided to phase out the 'uri' key of the library entries (and
there are a couple of other keys with similar issues). The 0.8-rc1 build
process already ignores the 'uri' key. What you see is the effect of
discarding the 'uri' member during config evaluation. The next step
would have been to abolish the key altogether.
But now you are using the 'uri' key for a virtual server directory...
What's your rational behind it? Do you want to have a common framework
uri across various projects? Do you try to come around the 'common
document root' issue that comes up with relative uri's? (BTW: I don't
quite get how your current solution can work. Shouldn't the value be
"/qx", rather than just "qx"?! Because now, the web server would search
a subdirectory 'qx' from the uri of your index.html, so you needed a
'qx' subdirectory in the 'source' path of your application, right?! Or
does your web server map *any* path with 'qx' in it onto the virtual
directory...?!)
In the end, the computed, relative paths should work just as well, don't
they?! They force you to have a common document root for both the
library and the application. Is this a big issue? I mean, the source
version is only meant for the development phase anyway, so this 'common
root' requirement shouldn't be too much of a burden for a development
system. Or should it?!
Thomas
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
qooxdoo-devel mailing list
qooxdoo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
