I’ve deployed a WAR to Tomcat and the initial page comes up fine (with
all assets, etc) In my javascript(jquery), I reference a controller and
action like this:
$("#create_button).click(function() { document.location.href =
“/requests/new”; etc…
so basically, it’s doing a URL redirect to /requests/new.
Since this application is running under a subfolder in Tomcat’s webapp
directory, it attempts to hit
localhost/requests/new
instead of
localhost/image_server_requests/requests/new.
How do I tell rails, or Tomcat… or whomever to use
/image_server_requests as the base URL? I’ve tried just modifying my
javascript to prepend the base directory, but actions from other
controllers still don’t work.
Use Rails url helpers where you can inside templates – they will
include the extra prefix. If you need to hard-code URLs inside static
javascripts, then I’d suggest making a helper function to detect the
extra prefix and prepending it to all your URLs.
/Nick
Nick S. wrote in post #967735:
Use Rails url helpers where you can inside templates – they will
include the extra prefix. If you need to hard-code URLs inside static
javascripts, then I’d suggest making a helper function to detect the
extra prefix and prepending it to all your URLs.
/Nick
I ended up just setting up a virtual host in Tomcat. (isr.locahost) That
alleviates the headache but it would be nice if I could specify
something in routes.rb that would allow a different context.
Sadly I am used to PHP where I can just specify a path and it works.
It’s great for staging apps before deployment… but it stinks for
doing much else. (been drinking Ruby Koolaid)
Thanks for the input!
-Jim
I think Rails had a configuration option called host_base or
base_host
or something like that that did the trick and it used it as prefix for
the
urls.
Nick S. wrote in post #967735:
Use Rails url helpers where you can inside templates – they will
include the extra prefix. If you need to hard-code URLs inside static
javascripts, then I’d suggest making a helper function to detect the
extra prefix and prepending it to all your URLs.
/Nick
What is the best practice here?
In PHP development, I often use jQuery to send Ajax requests like this:
$.post(‘delete_record.php’, {some_param:paramvar}, callback()…etc
Since “delete_record.php” is relative, it’ll work.
I’m in a whole new world of calling controllers and actions with URLs.
What do the Ruby experts do in this type of situation (remembering that
in production, my app is deployed to a subdirectory).
If using a helper function that guesses if it’s on the production server
vs. my local dev environment, then that’s I’ll just have to get used to
that.
Something like this, I guess:
var currentUrl = window.location.href;
if(currentUrl.indexOf(‘3000’) > 0) {
var url = ‘/access/destroy/’+ir_id;
} else {
var url =
‘/image_server_requests/access/destroy/’+ir_id;
};
I know this is more of a broad “best practices” question and may not fit
in this forum. If so, then please accept my apologies.
On Mon, Jan 3, 2011 at 2:01 PM, Jim W. [email protected]
wrote:
In PHP development, I often use jQuery to send Ajax requests like this:
$.post(‘delete_record.php’, {some_param:paramvar}, callback()…etc
Since “delete_record.php” is relative, it’ll work.
I’m in a whole new world of calling controllers and actions with URLs.
What do the Ruby experts do in this type of situation (remembering that
in production, my app is deployed to a subdirectory).
I don’t know of a current “best practice” as this issue tends to only
come up with Java appserver-based deployments where there’s a leading
prefix.
My suggestion is to have a controller/action that renders a dynamic
bit of javascript that can be cached. Have a script tag in your
layouts that load the javascript from the Rails controller.
layout:
controller:
class JavascriptController < ApplicationController
def index
render :text => “var prefix =
‘#{ENV[‘RAILS_RELATIVE_URL_ROOT’]}’;”, :content_type =>
“text/javascript”
end
end
Then use “prefix” when calculating ajax URLs.
Bonus points for making a helper js function that builds all your URLs
according to the prefix, and for making the javascript#index action
cached (it should only have to be generated once per deployment).
/Nick
On Mon, Jan 3, 2011 at 5:21 PM, Nick S. [email protected]
wrote:
I don’t know of a current “best practice” as this issue tends to only
come up with Java appserver-based deployments where there’s a leading
prefix.
Neither do I, but I have used jrails plugin for using “jQuery to send
Ajax request” when I made my presentation slide on top of JRuby of
Rails. It worked well and the programing was easy.
#136 jQuery - RailsCasts will help you to understand
how to do that.
-Yoko
Neither do I, but I have used jrails plugin for using “jQuery to send
Ajax request” when I made my presentation slide on top of JRuby of
Rails. It worked well and the programing was easy.
#136 jQuery - RailsCasts will help you to understand
how to do that.
-Yoko
Yes, Ryan does some great Railscasts! His philosophy on ajax requests
and return types is something I’ll have to integrate into my mindset.
The way I’ve been doing things for the past few years is by returning
JSON or even HTML snippets (usually used for tables or repeat region
style form elements). Ryan seems a fan of returning escaped Javascript.
I’m so new to Rails that I’m finding a LOT of philosophies to which I
must adapt. Things like “respond_to” blocks, linking to controller
actions via HREF, etc.
Is your presentation available on Vimeo?
Thanks for your input,
-Jim
Nick S. wrote in post #972122:
layout:
The link_to rails helper will attempt to add a hyperlink. ‘url_for’ will
work perfectly though. Otherwise, this solution works great!
Thanks!
-Jim
On Jan 4, 2011, at 16:14 , Jim W. wrote:
Nick S. wrote in post #972122:
layout:
The link_to rails helper will attempt to add a hyperlink. ‘url_for’ will
work perfectly though. Otherwise, this solution works great!
Whoops, #url_for is what I wanted there. Good catch!
/Nick
Nick S. wrote in post #972122:
I don’t know of a current “best practice” as this issue tends to only
come up with Java appserver-based deployments where there’s a leading
prefix.
I think we’ll be seeing more and more of this as jruby gains in
popularity. It’s just causing me to rethink how to solve problems
though, and I like that.
My suggestion is to have a controller/action that renders a dynamic
bit of javascript that can be cached. Have a script tag in your
layouts that load the javascript from the Rails controller.
layout:
controller:
class JavascriptController < ApplicationController
def index
render :text => “var prefix =
‘#{ENV[‘RAILS_RELATIVE_URL_ROOT’]}’;”, :content_type =>
“text/javascript”
end
end
Then use “prefix” when calculating ajax URLs.
/Nick
I’ll give this a shot. Thanks again Nick!
I’m not sure if it is legal to post the following Call for papers, but
as
a community member, developer and conference chair, I felt I should do
it:
Dear speakers and friends of RailsWayCon!
It’s a pleasure for us to announce RailsWayCon 2011! After a great
RailsWayCon 2009 and an even greater RailsWayCon 2010 in Berlin it’s
time
for a continued success and a great conference about the leading web
framework in Europe.
Everyone who attended the event was greatly impressed by the content and
of course the speakers. Be (maybe again) part of a huge event in an
amazing city and network with the most renowned experts of the world.
Basic facts RailsWayCon 2011
-
Location: Berlin, Germany
-
Date: May, 30 June, 1, 2011
-
Enter Submissions via http://railswaycon.com/input
-
Deadline: January, 28th, 2011
-
Duration of Sessions: 60 minutes
-
Duration of Short Talks: 20 minutes
-
Duration of Tutorials: 4 x 75 minutes
The following topics are a hint for what we would like to see:
- Rails 3 Success stories
- NoSQL with Ruby
- Alternative Ruby implementations (MacRuby, JRuby, )
- Real Live Scaling
- Effective Testing
- Extending Rails 3
- Testing JavaScript
- Best Practices
- Ruby Kung Fu
Members of the advisory board:
- Steven Bristol
- Gregg P.
- Jonathan W.
Please feel free to send this email to friends & colleagues, who may be
interested in submitting.
We are looking forward to your submissions and wish you a happy new
year!
Best regards
Michael J. & Sebastian Meyen