Can duplicate "back" browser function in Rails?

rubyonrails-talk
1

In Rails I have a DB Table index.html.erb view. It has 100's of items.

When I gen via scaffold I get index, show, edit, update, etc view.

But when I page down several pages, use the "show" link and then the "back" link I do not go back to where I was on the index view.

Instead, I go back to the TOP of the index not the place where I clicked on the "show" link.

I must then page down several times to get to where I was.

On the other hand, using the browser's back function take me right back to where I was. No paging down needed again.

Can this "back" browser function be invoked from a Rails "back" link?

TIA

Ken

2

Might not be the prettiest, but you could do this:

modify your index.html.erb so that you're giving a name attribute each item in your list.

<tr> <td><%= link_to(item.name, :name => item.id) %></td> </tr>

Then modify the 'back' link in the action in question like this: <%= link_to 'Back', items_path + "##{@item.id}" %>

better yet, roll it into a helper. :slight_smile:

3

[...]

Can this "back" browser function be invoked from a Rails "back" link?

Sure: <%= link_to 'Back', '#', {}, :onclick => 'history.go(-1)' %>

In most browsers, this will behave *exactly* like the Back button -- if the user has JavaScript turned on.

TIA

Ken

Best,

4

Marnen Laibow-Koser wrote:

Sure: <%= link_to 'Back', '#', {}, :onclick => 'history.go(-1)' %>

In most browsers, this will behave *exactly* like the Back button -- if the user has JavaScript turned on.

Hi Marnen:

Thanks for your help.

I have "<%= javascript_include_tag 'prototype' %>" in the layout head.

But the code above doesn't work. Is there a different "turn on JavaScript" line of code needed?

After much digging and searching I discovered this:

<a href="Javascript:history.go(-1)">Back</a>

I think it automatically turns on JS. I am using NB 6.5 for Ruby/Rails.

For the record: I have installed the will_paginate gem. Will test it out. It does offer some better navigation options (I think.)

The other solution to "id" each line in the index view? Will it lead to more coding, maintenance overhead?

So, far Javascript:history... and will_paginate look good.

Any votes?

TIA

Ken

5

MarnenLaibow-Koser wrote: > Sure: <%= link_to 'Back', '#', {}, :onclick => 'history.go(-1)' %>

[...]

I have "<%= javascript_include_tag 'prototype' %>" in the layout head.

But the code above doesn't work. Is there a different "turn on JavaScript" line of code needed?

No. Protoype is not even needed for this -- that is, no javascript_include_tag is necessary -- because history.go is a basic JavaScript feature, not a Prototype library function.

After much digging and searching I discovered this:

<a href="Javascript:history.go(-1)">Back</a>

I think it automatically turns on JS.

No. Nothing "automatically turns on JS". For obvious reasons, there is no JavaScript code that would turn on JavaScript interpretation in the user's browser. Check your browser options and make sure you have JavaScript turned on -- that's the only way to do it.

Also, using javascript: pseudo-URLs in the href field is generally a bad idea (and note the lowercase j!). Using onclick as in my original example is much better.

I am using NB 6.5 for Ruby/Rails.

Irrelevant unless that's what you're using as a Web browser as well as an IDE. Is that the case?

[...]

Ken

Best,

6

> Also, using javascript: pseudo-URLs in the href field is generally a > in the href field is generally a > bad idea (and note the lowercase j!). Using onclick as in my original > example is much better.

>> I am using NB 6.5 for Ruby/Rails.

> Irrelevant unless that's what you're using as a Web browser as well as > an IDE. Is that the case?

Marnen:

I have used WebBrick and Mongrel at the command prompt.

Currently I have NetBeans 6.5 set to use Mongrel within NB, it seems to work the same, just no command window.

Again, irrelevant. I was asking about your Web *browser* (you know, Safari, Firefox, Internet Exploder, whatever), since that's where JavaScript runs. WEBrick (not "WebBrick") and Mongrel are Web *servers*: although they run the Ruby side of your application, they have nothing to do with how your JavaScript is being interpreted.

I will investigate using your onclick suggestion.

Good. Even better would be to have the onClick handler set from an external JavaScript file (see Unobtrusive JavaScript - Wikipedia ), but that's slightly harder to set up, so you may not want to worry about it initially.

There's a handicap, though. I am totally new to javascript JavaScript, JScript JQuery, Rails prototype.js (I think it's a variant form of javascript), Ajax and JSON.

Pretty clueless about it.

Yes, I can see that. :slight_smile: (I don't mean that as an insult -- merely a recognition that you do have a lot to learn here, and I'll help if I can.) Let's start by untangling the terminology.

* JavaScript is the programming language itself. * javascript: is the pseudoprotocol specifier used to make JavaScript calls conform to URL syntax (as in the href="javascript:history.go (-1)" syntax I encouraged you to avoid). * JScript is basically Microsoft's JavaScript implementation. * Prototype.js is *not* a variant form of JavaScript. Rather, it is a library of useful JavaScript functions meant to make JavaScript programming easier. See http://www.prototypejs.org/ . jQuery is likewise a library, similar to Prototype. * Ajax is a term for a style of Web application programming that uses JavaScript (rather than loading new pages) to communicate with the server. * JSON is a data interchange format that is derived from, but independent of, JavaScript. See http://json.org .

I found a wonderful javascript tutorial at the www3 (world wide web online 'school') I am going to start learning there.

Do you mean the W3C or w3schools.com ? They both contain many useful resources, but they're two different entities.

Also, if you are trying to learn JavaScript, I would *highly* recommend David Flanagan's "JavaScript: The Definitive Guide", published by O'Reilly -- I have seen reviews that say that it's the *only* JS book that actually teaches proper programming practices, and my experience with other JS books would confirm that assessment.

In general it appears that HTML is one layer, the HTTP / Server communication protocol another, Rails 'ERB' yet another, the browser itself is also a layer and that javascript is an inter-layer link between the browser and the underlying HTML/generator/embedded logic generator tools.

I think you're complicating things a bit too much. Basically, the server runs your application (which, in Rails, may include Ruby code, either standing on its own or inserted into HTML files by means of ERb or Haml templates). The browser (client) communicates with the server using HTTP. JavaScript is not an "inter-layer link", but simply helps the browser present a better user interface. JavaScript exists *only* on the client side -- that is, in the browser. Ruby (including ERb) only exists on the server side. The only link between the client side and server side is the use of HTTP to exchange information.

Is that clearer?

[Note: There *are* environments that use server-side JavaScript, but Rails isn't one of them, so the description I gave above, while slightly oversimplified, is accurate for what you'll be doing.]

Obviously, there are different flavors of browser-to-embedded logic javascript tools.

What do you mean by that?

So, I plan to do javascipt, Rails prototype.js, AJAX, JSON in that order.

Yes, learn basic JavaScript and the Protoype library (or jQuery, or MooTools, or YUI, or whatever JavaScript library you'll be using). Get familar with JSON (and YAML) as part of that process. Learn Rails and build conventional Web applications with it. *Then* -- only after you've built conventional Web applications -- learn Ajax. Or at least that's my recommendation.

Many thanks,

Ken

Good luck! Let me know if you have further questions.

Best,

7

Marnen Laibow-Koser wrote:

Again, irrelevant. I was asking about your Web *browser* (you know, Safari, Firefox, Internet Exploder, whatever), since that's where JavaScript runs. WEBrick (not "WebBrick") and Mongrel are Web *servers*: although they run the Ruby side of your application, they have nothing to do with how your JavaScript is being interpreted.

I will investigate using your onclick suggestion.

Good. Even better would be to have the onClick handler set from an external JavaScript file (see Unobtrusive JavaScript - Wikipedia ), but that's slightly harder to set up, so you may not want to worry about it initially.

Many thanks,

My browser(s) are: Google Chrome for quick looks, Firefox 3 for more intent work. I also test using IE 7 and Safari.

I find learning how to use Rails, Javascript, ruby, etc a challenge as there's such a scattered lot of sites to find out how to understand and use Rails. Most amazing are the ways in which it actually works. Once learned, I get lots done very quickly. It's finding the stuff that's such a bear. But, I am persistent.

Thus far I am comfortable with MySQL (love it), ruby, the script/generator, rake tasks, migrations, css, html.

I find the Rails documentation frustrating because so much is left out. Then I spend hours testing, digging and reading. Maybe I am just thick-headed.

So, off to learn javascript, et. al.

8

Why not pass a "to" parameter that points to the page where you want to go back? For example, clicking on an item to see the show view leads you to:

http://domain.com/items/1?to=http://domain.com/items?page=2

Of course, it'll appear escaped.

From there you can harvest the parameter and let your back button be:

link_to "Back", params[:to] || items_path

Check out railscasts too. Ryan Bates made an episode all about back.

Ramon Tayag

9

[...]

My browser(s) are: Google Chrome for quick looks, Firefox 3 for more intent work. I also test using IE 7 and Safari.

OK. All of those browsers should support history.go(-1). If it's not working, then make sure that JavaScript is turned on.

Actually, I realize that a better solution would be <%= link_to 'Back', :back, :onclick = "history.go(-1); return false;" %>. This way, if you have JavaScript off, at least you still get the link_to :back functionality.

I find learning how to use Rails, Javascript, ruby, etc a challenge as there's such a scattered lot of sites to find out how to understand and use Rails. Most amazing are the ways in which it actually works. Once learned, I get lots done very quickly. It's finding the stuff that's such a bear. But, I am persistent.

Yes, it can be frustrating. http://www.railsbrain.com is your friend: the Rails API in a much more readable format than on the official Rails site. http://www.javascriptkit.com is great for JS reference. And lots of documentation is available at http://www.ruby-doc.org .

Thus far I am comfortable with MySQL (love it),

That will wear off. :slight_smile: Investigate PostgreSQL when you get a chance -- it's a much better database for most things. But mySQL is certainly quite adequate to learn on, and many companies do use it for their primary DB system.

ruby, the script/generator, rake tasks, migrations, css, html.

Great. That's a very good start. Have you started playing with Capistrano yet?

I find the Rails documentation frustrating because so much is left out.

Left out? What do you mean? Do you have a concrete example?

Then I spend hours testing, digging and reading. Maybe I am just thick-headed.

So, off to learn javascript, et. al.

Best,

10

[...]

That's completely unnecessary: link_to :back already does what you're talking about. And it won't fix the underlying problem, unless you put a #name segment in the URL.

Best,

11

Marnen Laibow-Koser wrote: ...

(From Ken:) I find the Rails documentation frustrating because so much is left out.

Left out? What do you mean? Do you have a concrete example?

Then I spend hours testing, digging and reading. Maybe I am just thick-headed.

Yes. Take form_tag. Even on RailsBrain. Go to the top of the page.

It doesn't tell you What and Why. What, exactly, is a form_tag?

I gather it is some sort of a shorthand. Why? If the regular form usage is too long then why not just get rid of it? Besides, what, exactly, is a "tag?" A helper? An abbreviation? If we need "helpers", maybe, the superclass is somewhat antiquated? Hmmm?

What about this? text_field_tag(name, value = nil, options = {}) Creates a standard text field; use these text fields to input smaller chunks of text like a username or a search query.

Ok. How much smaller? Only 4 letters? 20 letters? And why isn't the text_field adequate for this? Or why is it too cumbersome?

You see? Not very much detail. Of course, if you're experienced at all this stuff then it all makes sense. On the other hand, how do you get experienced with this stuff? I just start doing some coding and fiddle with it until it makes sense or it drives me crazy. Either way it eats up a LOT of time.

The documentation could be light-years better. IMFO. ('F' for FERVENT.)

HTH,

Ken

12

Ken Wagner wrote:

Left out? What do you mean? Do you have a concrete example?

Then I spend hours testing, digging and reading. Maybe I am just thick-headed.

Yes. Take form_tag. Even on RailsBrain. Go to the top of the page.

It doesn't tell you What and Why. What, exactly, is a form_tag?

I gather it is some sort of a shorthand. Why? If the regular form usage is too long then why not just get rid of it? Besides, what, exactly, is a "tag?" A helper? An abbreviation? If we need "helpers", maybe, the superclass is somewhat antiquated? Hmmm?

This is a matter of "prerequisite." The Rails documentation assumes you know HTML, CSS, JavaScript, etc. It does not attempt to teach HTML. If you don't know what an HTML tag is, then study documentation on HTML. The Rails API documentation is a reference not a tutorial. There are Rails guides for that sort of thing, but better yet there are books, and other related information designed to teach this stuff.

There are certainly areas of the documentation that could be improved upon, and are being improved upon. But, most of us wouldn't want to see the Rails API documentation cluttered up with a bunch of non-relevant information such as explaining what a particular HTML tag is.

13

+1

Being a Rails developer means being a *Web* developer, and you can't be a Web developer without understanding the basic building blocks: HTML, CSS, HTTP.