Can duplicate "back" browser function in Rails?


#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.

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

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:

On Dec 18, 9:57 pm, Ken W. removed_email_address@domain.invalid


#3

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

On Dec 18, 9:57�pm, Ken W. removed_email_address@domain.invalid

Or you could do what most people do and use will_paginate to create a
web UI that’s actually usable.


#4

On Dec 18, 10:57 pm, Ken W. removed_email_address@domain.invalid
wrote:
[…]

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,

Marnen Laibow-Koser
removed_email_address@domain.invalid
http://www.marnen.org


#5

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:

Back

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


#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.

I will investigate using your onclick suggestion.

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. I found a wonderful javascript tutorial at the
www3 (world wide web online ‘school’) I am going to start learning
there.

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.

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

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

Many thanks,

Ken


#7

On Dec 20, 5:25 am, Ken W. removed_email_address@domain.invalid
wrote:

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:

Back

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,

Marnen Laibow-Koser
removed_email_address@domain.invalid
http://www.marnen.org


#8

On Dec 20, 4:27 pm, Ken W. removed_email_address@domain.invalid
wrote:

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
http://en.wikipedia.org/wiki/Unobtrusive_JavaScript
), 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,

Marnen Laibow-Koser
removed_email_address@domain.invalid
http://www.marnen.org


#9

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 B. made an episode all about back.

Ramon T.

On Fri, Dec 19, 2008 at 11:57 AM, Ken W.


#10

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
http://en.wikipedia.org/wiki/Unobtrusive_JavaScript
), 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.


#11

On Dec 21, 9:33 pm, “Ramon T.” removed_email_address@domain.invalid wrote:

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.
[…]

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,

Marnen Laibow-Koser
removed_email_address@domain.invalid
http://www.marnen.org


#12

On Dec 21, 9:00 pm, Ken W. removed_email_address@domain.invalid
wrote:
[…]

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,

Marnen Laibow-Koser
removed_email_address@domain.invalid
http://www.marnen.org


#13

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


#14

Ken W. 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.


#15

On Mon, Dec 22, 2008 at 6:22 AM, Robert W.
removed_email_address@domain.invalid wrote:

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.

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.

+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.


Hassan S. ------------------------ removed_email_address@domain.invalid