OK, well it's good to see I'm not going mad!
We have the following file structure:
\projects
\custom
\client <--- this is where config.json is
\source <--- index.html here
\class
\custom <--- our classes in here
\build
\qooxdoo-sdk <--- the sdk
On our development machines we have http://server/custom mapped to
\projects\custom\client so http://server/custom/source and
http://server/custom/build are available.
We then have http://server/custom/source/qx mapped to the sdk directory.
Like this in apache:
Alias /custom/source/qx "C:/Projects/custom/qooxdoo-sdk/frontend/framework"
Alias /custom "C:/Projects/custom/client"
So what is the preferred method now? We cannot expose the whole of
\projects\custom\ because it contains other files. Should we move the
sdk into the client folder?
thron7 wrote:
> 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=/
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
