Ralf,

this thread stems from last year's August. Things have changed a bit...

> Well, the problems are:
> 1 - this makes it nearly impossible to use with a skeleton rails app 
> (since that needs to be the root for the mod_passenger to work)

I don't know anything about skeleton rails apps or mod_passenger (nice 
name, BTW), but here is the status quo of qooxdoo config:

- The library 'uri' subkey is in full effect again.
- If specified, it will be used to compute all uris in this library. 
This affects the source version.
- There is an interference with compile-source/compile-dist keys. See a 
lengthy (also, slightly outdated) information about uri computation 
here: 
http://qooxdoo.org/documentation/0.8/generator_config_articles#uri_handling

> 2 - it would expose generate.py etc.

Not directly. The uri key of a library points to the folder where its 
Manifest.json is. This is usually also the folder where generate.py 
lives. But from this folder, individual paths are calculated to the 
class, resource, translation folders (as specified in Manifest.json). If 
these are direct subdirectories of the library's root, then yes, 
generate.py would be uri-addressable. If they navigate upwards, this 
should be normalized away.

> 3 - i still don't get what's wrong with being able to overwrite the 
> URI of the qooxdoo libraries?

It's possible again.

> 4 - it makes using virtual hosts entirely impossible (some people 
> prefer things like source.myapp.com <http://source.myapp.com> for 
> testing) ..

Let us know if this is still an issue.

>
> The main problem here is that the server-side code and the client-side 
> code need to co-exist in the same structure from the point of the view 
> of the browser because we can't xmlhttprequest to another domain. 
> Otherwise we could just setup two different virtual hosts.
>

This issue is gone. Let us know if there are still loose ends pending.

> It's just that the basic premise that the base URL and the base PATH 
> have anything to do with each other is just completely utterly wrong.
> For me, this choice is creating more problems than it solves.

Again, it's a matter of the development model. Not many people are 
exposing their source version through a web server. But it should work 
now nevertheless.


Thomas


------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and 
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today. 
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel

Reply via email to