What kind of Ruby / Erb is allowed inside HAML's :javascript

It seems that inside of HAML's :javascript filter, no Ruby code is
allowed, not even a comment.

So this is NOT allowed:

:javascript
  - 1.upto(10) do |i|

:javascript
  -# just a comment not to show to public

(somebody said there is not way to hide comment like that inside a
:javascript filter. Is that true?

but it seems the only thing allowed is

:javascript
  $('#aDiv').html('#{a_ruby_variable}';

only this #{ } is allowed. Nothing else that is Ruby is allowed?

Jian Lin wrote:

but it seems the only thing allowed is

:javascript
  $('#aDiv').html('#{a_ruby_variable}';

correction: (missing the ending paren)

    :javascript
      $('#aDiv').html('#{a_ruby_variable}');

Jian Lin wrote:

It seems that inside of HAML's :javascript filter, no Ruby code is
allowed, not even a comment.

I believe that's correct. But you should never need Ruby within
JavaScript, nor should you ever need JavaScript within HTML (it's best
to put it in a separate file).

So this is NOT allowed:

:javascript
  - 1.upto(10) do |i|

:javascript
  -# just a comment not to show to public

(somebody said there is not way to hide comment like that inside a
:javascript filter. Is that true?

Probably.

but it seems the only thing allowed is

:javascript
  $('#aDiv').html('#{a_ruby_variable}';

only this #{ } is allowed. Nothing else that is Ruby is allowed?

I'm surprised that #{} works here.

If you think you need Ruby in your JS, you've got a design problem. Fix
it.

Best,

Marnen Laibow-Koser wrote:

If you think you need Ruby in your JS, you've got a design problem. Fix
it.

i can think of a few cases where Ruby might be wanted inside of
Javascript output:

1) -# to add comment but not to show it to the public
2) using if else to output something based on some condition
3) using loop
4) providing values to javascript code by json

Jian Lin wrote:

Marnen Laibow-Koser wrote:

If you think you need Ruby in your JS, you've got a design problem. Fix
it.

i can think of a few cases where Ruby might be wanted inside of
Javascript output:

And all of them represent design problems and are better handled in
other ways.

1) -# to add comment but not to show it to the public

Use a JS minifier.

2) using if else to output something based on some condition
3) using loop

Use JavaScript control structures for these, not Ruby control
structures.

4) providing values to javascript code by json

Put the JSON in a (hidden) div, have the JavaScript read its content.

Best,

Marnen Laibow-Koser wrote:

1) -# to add comment but not to show it to the public

Use a JS minifier.

2) using if else to output something based on some condition
3) using loop

Use JavaScript control structures for these, not Ruby control
structures.

4) providing values to javascript code by json

Put the JSON in a (hidden) div, have the JavaScript read its content.

JS Minifier when there are 5 lines of code?

Also, I think we can always do things another way... but just that why
embedding values from Ruby to Javascript is bad, while hiding them first
in a div and read it back from the div is good? (suppose they are
simple keywords from our db which keywords like "shirt", "shorts",
"jacket" which will not cause any javascript injection by user input.)

Jian Lin wrote:

Marnen Laibow-Koser wrote:

1) -# to add comment but not to show it to the public

Use a JS minifier.

2) using if else to output something based on some condition
3) using loop

Use JavaScript control structures for these, not Ruby control
structures.

4) providing values to javascript code by json

Put the JSON in a (hidden) div, have the JavaScript read its content.

JS Minifier when there are 5 lines of code?

If there are only 5 lines of code, why do you need private comments in
the first place?

Also, I think we can always do things another way...

Yes.

but just that why
embedding values from Ruby to Javascript is bad, while hiding them first
in a div and read it back from the div is good?

Because it separates the Ruby and JavaScript more cleanly. This makes
the code more maintainable, and also improves performance by allowing
the client to cache one JavaScript file instead of the server having to
regenerate it for each call.

  (suppose they are
simple keywords from our db which keywords like "shirt", "shorts",
"jacket" which will not cause any javascript injection by user input.)

Then they should still be handled in the way I suggested. Dynamically
generating JavaScript is almost always a bad thing.

Best,

Marnen Laibow-Koser wrote:

JS Minifier when there are 5 lines of code?

If there are only 5 lines of code, why do you need private comments in
the first place?

Do you often see other people's way of doing things needing to abide to
your rule book? Such as: if there are only n lines of Javascript code,
they shall never have private comments there.

Jian Lin wrote:

Marnen Laibow-Koser wrote:

JS Minifier when there are 5 lines of code?

If there are only 5 lines of code, why do you need private comments in
the first place?

Do you often see other people's way of doing things needing to abide to
your rule book? Such as: if there are only n lines of Javascript code,
they shall never have private comments there.

You missed my point. It wasn't "shall never". My point was this: a
5-line routine should normally not need comments. If you need comments
on something that short, perhaps your code isn't as clearly written as
it should be...

Best,

Marnen Laibow-Koser wrote:

Jian Lin wrote:

Marnen Laibow-Koser wrote:

JS Minifier when there are 5 lines of code?

If there are only 5 lines of code, why do you need private comments in
the first place?

Do you often see other people's way of doing things needing to abide to
your rule book? Such as: if there are only n lines of Javascript code,
they shall never have private comments there.

You missed my point. It wasn't "shall never". My point was this: a
5-line routine should normally not need comments. If you need comments
on something that short, perhaps your code isn't as clearly written as
it should be...

A reason may be, a comment that says "TODO: we don't have enough time to
do more than this right now. talk to Simon for when it will be done" --
or any other similar comment -- may not be totally appropriate for the
public.

Jian Lin wrote:
[...]

A reason may be, a comment that says "TODO: we don't have enough time to
do more than this right now. talk to Simon for when it will be done" --
or any other similar comment -- may not be totally appropriate for the
public.

I see your point about TODO comments. But the fundamental problem here
is that your client-side JS has to be delivered to the client to get
run. If there are things in the JS that your client shouldn't see, then
you need a minifier or an obfuscator.

Or...hmm. Check out CoffeeScript; it's a bit like Haml for JS.

Best,

Marnen Laibow-Koser wrote:

Or...hmm. Check out CoffeeScript; it's a bit like Haml for JS.

if only there is a Ruby to JS converter.

Jian Lin wrote:

Marnen Laibow-Koser wrote:

Or...hmm. Check out CoffeeScript; it's a bit like Haml for JS.

if only there is a Ruby to JS converter.

Well, there's RJS and CoffeeScript. But Ruby and JS work very
differently. My advice is to write each one directly rather than
relying on converters.

Best,