shortcut to call js function

Mk 27 wrote:

Is there a shortcut for this kind of thing:

<%if X=42%>
     <script type="text/javascript>
          some_funct()
     </script>
<%end%>

I'm not sure, but if there isn't, a helper method would be trivial to
write. However, you probably shouldn't be writing that sort of code in
the first place:

* "if X=42" should be "if x == 42".
* JavaScript belongs in external files, not in the view. (Just like CSS
-- although you *can* include it inline, it's a very bad idea.)
* Depending on what you're doing, this may be too much logic for the
view.

Best,

It already exists:

<%= javascript_tag("some_func()") if x == 42 -%>

-Rob

Rob Biedenharn http://agileconsultingllc.com
Rob@AgileConsultingLLC.com

Rob Biedenharn wrote:

I will investigate writing a helper, thanks.

It already exists:

<%= javascript_tag("some_func()") if x == 42 -%>

Thanks Rob! I was sure I had run across this somewhere, but I have been
rummaging thru so much new material while learning I was totally
clueless as to where. Perhaps I should take more notes...

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??
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

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);

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.

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

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.

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

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,

To me, the greatest gain unobtrusive Javascript provides is
maintainability. You split the client-side logic (that is *all*
Javascript is) from the view for the same reason you split the
controller processing and buisness logic from the view with an MVC
framework. In addition to all Marnen said: your views become much
easier to test; You spend less time adapting the HTML your designer
gives you (or that you mock up yourself); It's *much* easier to focus
on providing an intuitive interface for those with or without
Javascript enabled.

Just a couple specific points:

1) what if this menu is part of a view being loaded into an existing
div, and not part of a fresh page

$(element).live("event", function...)

I'm sure non-JQuery'ers have something similar

Yeah, because you use ruby shortcuts. The JS still ends up in the page.
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.

Don't use the RJS helpers, no inline JS. And if you think not using
the RJS helpers is limiting, I doubt you've really explored the powers
JS frameworks.

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!???!?

Semantic markup that knows little about how it'll be displayed is far
easier to maintain, and offers *more* presentational flexibility via
your stylesheets.

Curious if someone in the Rails community has figured out a good way to
accomplish what Rails helpers do (controller logic in the controller
instead of view, DRY for js idioms, etc) but in an "unobtrusive" idiom
where no JS (apart from <script src> to load external js) is embedded in
the HTML. It's not entirely obvious how to accomplish this, but I think
it's probably possible, probably using some design where the actual
external js files are dynamically created themselves, not just static on
disk.

That's what the UJS plugin does/did (and the rails helpers in rails 3
will apparently be more unobtrusive)

Fred

Mk 27 wrote:

However, "getting the inline js" out will inevitably increase the actual
codebase of the project as whole, because you will have to add *more*
lines to your external scripts than you would have used in the page
source by inlining in *at least some* (if not quite a few) cases.

All I can say is that in the (non-Rails) project where I'm consistently
using unobtrusive JS, this has not been my experience. It hasn't led to
any more lines of code. This does in part depend on your HTML DOM being
fairly well structured with good classes and id's. In my experience,
once you learn how to do it right, it's no more lines of code to
maintain, and forces you to have better-structured HTML to boot, which
is an added advantage. But there is a bit of a learning curve, sure.

Now, if you had to give up all the Rails helper methods (that are
essentially dynamic js-code-generators), then THAT would lead to more
code. I wouldn't want to do that.

So I'm going to check out the UJS Rails plugin that Fred helpfully
alerts us to.

But to each her own.

I was gonna try to look at your example to show you a short concise
unobtrusive JS version that would do the same thing, but I don't
understand the case quite well enough and don't feel like spending the
time trying to just to make a point. But my experience leads me to be
confident it would be possible.

Marnen Laibow-Koser wrote:

Mk 27 wrote:

And
please, do not hand me some basic case involving onload(), and claim "oh
no, it could never be more coding, look...". Certainly, it could never,
ever, logically be *less* coding.

You are absolutely wrong. Since inline JS, by its very nature, is much
harder to refactor, in many, many types of cases, inline JS will lead to
significantly more code than unobtrusive external JS.

I think we are talking about slightly different things. I am not
talking about defining functions inline. I'm talking about calling
them:

<script type="text/javascript>call_my_function(here, forthis)</script>

You can claim whatever you want but you are not going to get rid of that
from the page by adding a single line to a .js file somewhere. Period.
The end.

No. Just iterate over the affected DOM elements and apply an
appropriate abstraction.

Sure, but that is not one line of code. You are trying to make a "rule
with no exceptions" and you are bound to failure because of that.

You said you were snobbish about JS as compared to "real languages".
Well, guess what -- JS is a "real" language, and quite a powerful one
too,

This was a joke about snobbishness, and not really anything else. Sorry
I did not make that clear earlier...

"real" language. That means writing complete routines in one place, not
scattered bits of inline code. [...]

The routines are in one place, a .js file. The calls are, often enough,
made in an html file.

while keeping JS out of the HTML. I guarantee that both
your JS and your HTML will be the better for it.

Inlining CSS is truly pointless, but when I look at a page source and
see a mix of html, javascript, and embedded "whatever", I honestly do
not, never have, never will, have some sort of absurd formatting related
freak-out (like: "See how much tidier your html is now!!" Grow up).
You sound like someone who insists there is only one place to place an
opening {, when in fact there are a number of acceptable styles and that
is all they are: styles.

You are not
talking about any improvement in functionality or performance, after
all.

Wrong again.

No, you are wrong again. If you want to tell me

<script type="text/javascript>call_my_function(here, forthis)</script>

represents some kind of performance issue (considering call_my_function
is already cached), I will tell you are wrong again, because you are.

I would hate to consider a case where an author decided *not* to do
something because it required inline js.

Read my lips: *NOTHING* REQUIRES INLINE JS! Anything doable with inline
JS can also be done without it.

Possibly, although you don't make much of a case to support that. But
just because something *can* be done one way or another doesn't mean it
*has* to be, unless you have a good reason for it, and since you still
have not come up with one, I am satisfied that it doesn't exist.

MK

Marnen Laibow-Koser wrote:

Above all, please realize that nothing I have said was meant as a
personal attack. You seem to be reacting as if I insulted your little
sister (I don't know if that's the impression you meant to convey), when
in fact I'm just trying to give you some useful guidelines for
programming practice. I hope you will take my comments in the spirit in
which they have been intended, as I also have attempted to do.

Grumble. Alright, I surrender. You win, Marnen :wink: ...I think I've
made my point and I'll leave it at that.

MK