I have a small feature request, My gut says Tim's not going to like it, but I'll make my case.

Today I do almost everything Web based in EWB, but sometimes things require a very tiny fragment of JavaScript.  There are a few easy ways to accomplish this presently

1. Write a JavaScript funciton and load it as a script file
2. use eval() or it's EWB namesake CreateObject()
3. mangle things using variants, like I did in the example I posted a few hours ago (previous thread).

In my EWB book I used a fair bit of eval() to sneak in the JavaScript, but that was a few years ago, and eval()'s use is now discouraged and in certain browser situations or in security clearances, is downright disallowed.  Now I use much less eval(), but sometimes it is necessary when interfacing with 3rd party libraries or extended browser features.

BTW, Tim's a JavaScript expert, so I'm writing much of this for others' benefit to understand where I'm coming from.

eval() not only has security implications, it has a performance hit.  Normal JavaScript can be compiled and executed quickly, but the code inside eval() bounces back to the interpreter, which obviously slows to a crawl.

What I propose is this: Many dialects of object pascal have an asm or emit feature, where you can insert a tiny fragment of assembler code.  

So I would like if you could emit a single line at a time of JavaScript code, just enough to handle interfacing.  To simplify implementation, you might only be able to access EWB's local varaiables by name (since they are the same names in EWB as in JS whereas global variables are mangled somewhat).

To do this, EWB would presumably just emit the text between asm and EOL or //

Much of the benefit of EWB comes from its adherence to Pascal's beautiful strongly typed language, and I don't want to do anything to diminish that.  I think that limiting the ASM to one line is a decent strategy to allow interfacing with other people's code, while reducing the chance someone will get into the ugly habits that come with JavaScript, and giving us relief from relying on Eval() which gives reviewers concerns.

This came up for me in the context of a security scanner rejecting some small code because it had eval() embedded in it.  So this forced me to either move to a javascript function which I really didn't want, or hand edit the EWB generated code, which I didn't want to do to either.

Thanks for considering this request.  Maybe you have a better solution.

Erick
EWB Programming Books and Component Library
http://www.erickengelke.com

Erick,

<< So I would like if you could emit a single line at a time of JavaScript code, just enough to handle interfacing.  To simplify implementation, you might only be able to access EWB's local varaiables by name (since they are the same names in EWB as in JS whereas global variables are mangled somewhat). >>

This won't save you much because the EWB compiler will *still* need an external interface to the class, variable, or function/procedure, otherwise it won't know how to resolve it and will issue an error.  There's just no way to have external JS code used by EWB code without telling the compiler how to use it.  And, this has further implications in EWB 3 where server-side code can interface with native Object Pascal classes, variables, and routines.  IOW, what you're proposing won't be compatible with native code interfaces at all, will be a one-off that is specific to JS, and will essentially duplicate what is already fairly easy to do for one-liner JS functions.

<< This came up for me in the context of a security scanner rejecting some small code because it had eval() embedded in it.  So this forced me to either move to a javascript function which I really didn't want, or hand edit the EWB generated code, which I didn't want to do to either. >>

What's your opposition to using a JS function in an external script file ?

Tim Young
Elevate Software
www.elevatesoft.com