[OPEN] [#1362] [4.1.0] FieldTrigger - Handler - Literal string newline - bug

[sveins12]

Hi, the generated javascript will be invalid if a FieldTrigger handler is a literal string with newline in it:

@{ 
    var x = Html.X(); 
}

@(    
    x.TextField()
        .Triggers(
            x.FieldTrigger()
                .Icon(TriggerIcon.Ellipsis)
                .Handler(@"
                    alert('test');
                ")
        )
)

[fabricio.murta]

Hello!

If you need a more comprehensive javascript bound to your field's trigger buttons, please use a full listener.

[sveins12]

Yes, I do that as a workaround. But the strange behavior described is different from the behavior of other handlers in the library. I have never had problems using the Handler function like this other places, or other "inline" functions. The javascript has never got invalid because of newline in literal c# strings. Besides, in the newer examples from Sencha they use the handler-config on FieldTriggerstriggers. And the TriggerClick-event is not even there:

http://docs.sencha.com/extjs/6.0.1-c...l#cfg-triggers

There is a workaround like you say, to use the TriggerClick-event. But it will result in more code. First, each triggers must have a Tag to be identified, second the event-handler must have if-s in it to check which trigger has been clicked based on that Tag.

[fabricio.murta]

Hello @sveins12!

Well, after all, there's a conversion error there when it outputs JavaScript code with "invented" backslash plus 'n' characters, where that should be the line break itself.

So, please stick to the workaround for now. Actually, I'd advice you (this is not a rule though) to avoid javascript under quotes, as it just makes it hard for you and your team to debug the code. Instead, you may define functions inside JavaScript script blocks in HTML (or .js files) and in addition to what's already said, get nice syntax hilighting, auto indent and code completion -- at least from Visual Studio. As well as leaving the component definition code as small as possible.

Well, at least I believe what you get in your example withing VS is something similar to this:


Anyway, yes, we've logged the issue, your test case is so simple and reproduces the issue so clearly that well, I got no arguments against logging an issue to fix this!

That said, issue #1362 has been logged in our issues tracker. We're going to update here as soon as we get that piece of code fixed!

Thanks for taking your time to not only report the issue, but support the need and usefulness in fixing it!

[sveins12]

No problem :)