PS. I solved this problem by symlinking everything. [but it's very very
dirty]
But at least I get all the freedom I need, without exposing server side
code, generator scripts, etc.
This is my structure:
my-rails-app/
app/
config/
db/
doc/
lib/
log/
tmp/
public/
qooxdoo -> ../qx/qooxdoo
source -> ../qx/source
api -> ../qx/api
index.html -> ../qx/build/index.html
resources -> ../qx/build/resources
script -> ../qx/build/script
qx/
qooxdoo -> /opt/qooxdoo82
config.json -> ../config/qx.json
cache -> ../tmp/qx/cache
source/
class -> ../../app/qx
translation -> ../../config/locales
Then I added some rake tasks, since the ./generate.py script only works
properly in its own directory
Perhaps I'll put this into a rails plugin someday..
Mvg,
Ralf
On Tue, Apr 21, 2009 at 12:55 PM, Ralf Nieuwenhuijsen <[email protected]> wrote:
> >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,
>
>
------------------------------------------------------------------------------
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
