>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?!
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)
2 - it would expose generate.py etc.
3 - i still don't get what's wrong with being able to overwrite the URI of
the qooxdoo libraries?
4 - it makes using virtual hosts entirely impossible (some people prefer
things like source.myapp.com for testing) ..
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.
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.
Mvg,
Ralf ( @ gong.nl // 06-49147635 )
------------------------------------------------------------------------------
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
