Mk 27 wrote:
Marnen Laibow-Koser wrote:
It still seems to me that it is. Where there is html, there can be
javascript.
Yes. There can also be CSS. There *should* be neither.
WHY!???!? You want to make web programming *more* limited that it
already is??
No, I want to separate behavior and presentation. That's just good
architecture.
Nothing I am recommending makes Web programming any more limited. If
anything, it has the opposite effect, since it organizes the code
better.
I agree "when convienient" but
Rather what I'm talking about is simply having <div class="menu"></div>
in your HTML, then do something like
window.onload = function () {
1) what if this menu is part of a view being loaded into an existing
div, and not part of a fresh page
I *think* the principle still works.
2) create_menu_div would imply (or at least, I would hope) to me
something a little bit more significant than just assigning some style.
I do use a function like this, and it takes an array of choices (for the
menu options) and a callback containing a switch(); the number of the
choice corresponds to this, so rather than having to write a slew of
onclick statements, etc,
choices = ["do this", "do that", "do both"];
create_menu_div(style, choices, parnt, callback);
Not sure I understand from that description. I'll reread when I'm less
pressed for time.
Also, using an event handler still
entails putting some javascript in an html page somewhere.
Not necessarily. You can use the onload technique (as above) to assign
behavior without a single JS call in the HTML. All you need is the
external <script> tag in the <head>.
The <head> I would say is part of an html page.
Yes. That's not what I meant. Rather, I meant that the <script> tag
points to an external file, so there is *not a single line of JS* in the
HTML file.
I'm sure you already handle CSS this way, with <style> tags pointing to
external file. Why is it so hard to grasp the concept of doing the same
for JS?
It's not a paradox at all. It's perfectly feasible, and I know because
I have done it.
Yeah, because you use ruby shortcuts. The JS still ends up in the page.
Wrong. The complex Ajax work I have done was in an application that did
not involve Rails, or indeed any other framework with JS helpers. I
know precisely how much literal JS wound up in the HTML generated by
that application: none. I made sure of that, and would do it exactly
the same way again in a similar case, Rails or no Rails.
All you have to do is look at the source generated for a rails app page
(any and all of them) to find more inline javascript than you can shake
a stick at.
Yes, if you use Rails' JS helpers without the UJS or Lowpro plugins.
This is why I don't like to do that. At the very least, use one of
those plugins to separate your JS and HTML.
Again: it is possible. It is feasible. It's not even particularly
difficult.
Sure, and again I agree: as convenient. By "not possible" I meant that
I sincerely hope that people with your opinion do not come up with a
means of *forcing* everyone else to comply, and I do believe that "will
not be possible", in fact. Thankfully.
Yeah, I don't know that I'd want that either. Choice is a good thing,
but with choice comes responsibility -- just because you *can* write JS
inline doesn't mean you should.
OTOH, I really wouldn't be at all unhappy if inline JS just dropped off
the face of the earth. It's not an appropriate way to write
maintainable code, and it causes problems on the client side as well.
-MK
ps. with your penchant for waving credentials and experience, the
biggest question in my mind would be why the simple answer Rob gave was
evidently out of your range...
Why? Simple: because I haven't done a lot with Rails' JS helpers --
just enough to know that they generate more inline JS than I'm
comfortable with.
Best,
...I think I've
made my point and I'll leave it at that.