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.
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:
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?
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
), 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.
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.
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.
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.
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.
(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.)
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.
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.
