My guess would be that the first example is giving an error because it
thinks you are passing a code block, not a hash, and the code block has
syntax errors.
Okay I might be getting a little bit closer…
url_for :controller => ‘user’, :action => ‘login’ apparently returns ‘/’
If I change the controller to anything else, I get the expected url.
If I change the action to anything else, I get the expected url. Just
can’t use this combo, apparently.
Now I think I’ve really figured it out…in my routes.rb file I have:
map.connect ‘’, :controller => “user”, :action => “login”
So I guess url_for uses routes to generate the urls? Not sure…is
there any way I can make user/login respond to the app root, and still
be able to use url_for in other places?
instead of using start_form_tag, and I get the same thing still…I
wonder if webrick might be caching it or something?
To ease your fears, try adding ‘id=“something”’ to your form
declaration - if you see that in the source reaching the browser, you
know nothing is being cached anywhere down the chain.
Assuming caching isn’t the issue, what url do you expect to get? Have
you changed routing.rb to map / to user/login?
Assuming caching isn’t the issue, what url do you expect to get? Have
you changed routing.rb to map / to user/login?
Yeah, I did…is that what’s causing this? I’m kind of guessing so,
but I didn’t know that url_for uses routes to generate the urls. It
seems as if I map / after the default route, everything works fine:
instead of using start_form_tag, and I get the same thing still…I
wonder if webrick might be caching it or something? I’ve cleared the
cache on my browser multiple times, used a different browser, and even
tried connecting from a different computer. I haven’t turned any
caching on in rails, so unless it’s on by default somewhere, I don’t
know why anything would be cached.
Assuming caching isn’t the issue, what url do you expect to get? Have
you changed routing.rb to map / to user/login?
Yeah, I did…is that what’s causing this? I’m kind of guessing so,
but I didn’t know that url_for uses routes to generate the urls. It
seems as if I map / after the default route, everything works fine:
url_for does use routes to generate urls. this gives you loads of
flexibility when changing your url schemes, assuming you’ve used
url_for throughout your app.
So I guess url_for uses routes to generate the urls?
Most definitely, that’s the (half of) idea behind routing and using
these url helpers. They will change according to your needs. However,
url_for will use the first route that matches, so you can put this
above the route you mention: