Forum: Ruby on Rails Can duplicate "back" browser function in Rails?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Ken W. (Guest)
on 2008-12-19 05:57
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
John Y. (Guest)
on 2008-12-19 16:23
(Received via mailing list)
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. :)

On Dec 18, 9:57 pm, Ken W. <removed_email_address@domain.invalid>
Robert W. (Guest)
on 2008-12-19 18:08
> better yet, roll it into a helper. :)
>
> 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.
Marnen L. (Guest)
on 2008-12-20 08:03
(Received via mailing list)
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
Ken W. (Guest)
on 2008-12-20 12:25
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
Marnen L. (Guest)
on 2008-12-20 18:58
(Received via mailing list)
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:
>
> <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,
--
Marnen Laibow-Koser
removed_email_address@domain.invalid
http://www.marnen.org
Ken W. (Guest)
on 2008-12-20 23:27
> 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
Marnen L. (Guest)
on 2008-12-21 23:32
(Received via mailing list)
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. :)  (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
Ken W. (Guest)
on 2008-12-22 04:00
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.
Ramon T. (Guest)
on 2008-12-22 04:34
(Received via mailing list)
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.
Marnen L. (Guest)
on 2008-12-22 04:43
(Received via mailing list)
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. :)  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
Marnen L. (Guest)
on 2008-12-22 05:08
(Received via mailing list)
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
Ken W. (Guest)
on 2008-12-22 15:31
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
Robert W. (Guest)
on 2008-12-22 16:22
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.
Hassan S. (Guest)
on 2008-12-22 17:59
(Received via mailing list)
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
This topic is locked and can not be replied to.