String.l and it's replacement

[scho]

Hi Max,

I tried the newest netzke master and I saw, that you got rid of String.l which is totally cool :) But I'm a bit confused how it got replaced. For example the following works great:

js_configure do |c|
  c.some_method = <<-JS
    function(){
      // some stuff
    }
  JS
end

When the component gets serialized, the some_method attribute won't be a String.

But as soon as there's is some nesting, it won't work and I need ActiveSupport::JSON::Variable:

js_configure do |c|
  c.listeners = ActiveSupport::OrderedOptions.new
  c.listeners.special_key = ActiveSupport::JSON::Variable.new(<<-JS)
    function(){
      // some other stuff
    }
  JS
end

So what's the magic behind this? I also updated the CHANGELOG.md.

[scho]

Strange, that this old comment shows up. All changes I made are in this commit: https://github.com/scho/netzke-core/commit/720dd7d4d42457b8ae240b155b750248e016ecba

[mxgrn]

So what's the magic behind this?

The 'magic' was to check whether the string starts with 'function' - and then convert it to JSON::Variable. Hackish, I admit, and I like it even less now that you point at this nesting problem. Generally, I think, it should be discouraged to put JS code into Ruby class at all, and use JS mixing instead (and that's what I suggest to do in your case). But it's still there, because I found it useful for quick experiments and tests. However, as you can see, it's confusing, too.

[scho]

But there are cases, when it's really handy to use this. For example when you define some form elements in a form and you want to add listeners as well. I don't want to search for my textinput in the initComponent method and add the listener afterwards.

One other thing: Could your hack maybe open a door for Cross-Site-Scripting attacks?

[jhaagmans]

@nomadcoder Could you maybe explain how you would add a listener to a component without using JS serialization? I could imagine why scho wouldn't want to do this in the initComponent method.

[mxgrn]

I find it a hard one. From one side, I would like to avoid as much as possible mixing JS and Ruby, from the other side I can't think of a generic way of "hiding" JS behind some conventions the way I did for actions (where you can specify a handler as a Symbol). @jhaagmans, up till now the solution was initComponent. But it's not nice, as echo points out, to hard-code listeners on the fields that are dynamically created in Ruby.

@scho, how about getting the String#l functionality back in a more civilised form? Maybe something like a "js_code" method:

field.listeners = {focus: js_code('function(){}'), click: js_code('function(){}')}

[mxgrn]

Fixed with 59c7aa6. Closing.