eval() or What?

[Gene Wirchenko]

Dear JavaScripters:

I am writing an object for handling browser-side field
presentation and validation. Two of the properties will have string
values of code to be executed in order to do validation. The code
could be arbitrary, but it will probably be a function call with
parameters.

How do I handle this? I see three possibilities:

1) eval()

From what I have read, this might be better spelled "evil()", but
I have used similar functionality in another language. I am concerned
with scoping. I ran across one Web reference that stated that it
differs between browsers.

I want the scoping of the variables used to be as at the time of
execution of the validation code. The code will be executed inside
the object code so all of the properties will be available, and I will
-- unless required not to -- probably pass them to the validation
function called. I would like the validation code to be able to
change the value of a parameter or a global value.

One advantage of this approach is that I can append more code to
the string on the fly if I wish.

2) Define a function with new Function()

Something like
var myFunctionName = new Function(arg1, arg2,
"/* function content goes here */");

I do not think that I can append more code as with a string. (I
might not need this functionality, but I would like to keep the option
open if it is not too dear to do so.)

3) Something Else I Wot Not Of

wot: a short word for "know".

Maybe, you know of another way?

Sincerely,

Gene Wirchenko

 

[Gene Wirchenko]

Dear JavaScripters:

I am writing an object for handling browser-side field
presentation and validation. Two of the properties will have string
values of code to be executed in order to do validation. The code
could be arbitrary, but it will probably be a function call with
parameters.

<snip>

Could you explain the step from 'writing an object for handling [...]
presentation and validation' to 'will have string values of code to be
executed in order to do validation'?

I am defining an object called FieldItem. Two of the properties
are ValidationBasic and ValidationExtra. Each of these will hold code
for validation.

My plan is to define many FieldItems and pick from these in
various pages to generate much of the DE code. Some of it is
validation code. (Yes, I will have server-side validation, too.)

I already have a basic proof-of-concept, but now, I have to patch
up a few weaknesses. My validation spec was formerly in the input
control; now, I want it in the FieldItem object.

Sincerely,

Gene Wirchenko

 

[Dr J R Stockton]

In comp.lang.javascript message <fn8nf756jclubi6uu8510fcqjt57lhcd15@4ax.

I am writing an object for handling browser-side field
presentation and validation. Two of the properties will have string
values of code to be executed in order to do validation. The code
could be arbitrary, but it will probably be a function call with
parameters.

Already done. Read my js-valid.htm, particularly #VFF - after which it
is possible that you will no longer need to eval strings.

If you were thinking of writing ... onclick="eval(...)" consider
instead, from my js-quick.htm,

function remoteEval_(St) { return eval(St) /* RC */ }

An RC may be able to explain why that is better.

Aside: In <http://www.merlyn.demon.co.uk/programs/32-bit/>,
seakfyle needs testing.

 

[Gene Wirchenko]

On Thu, 29 Dec 2011 22:39:17 +0100, Jake Jarvis

[snip]

That is not really what I was getting at, sorry for asking so indirectly.

It reads like having two string value properties containing program code
to be eventually evaluated one way or another is a given and not up to
reconsideration, if that is indeed the case, why is that so?

It is simply the design that was most obvious. I did not exclude
anything else from consideration: look at my points 2 and 3 in my
original post.

Sincerely,

Gene Wirchenko