Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #9745 > unrolled thread

eval() or What?

Back to article view | Back to comp.lang.javascript

Contents

  eval() or What? Gene Wirchenko <genew@ocis.net> - 2011-12-28 15:29 -0800
    Re: eval() or What? Jake Jarvis <pig_in_shoes@yahoo.com> - 2011-12-29 01:08 +0100
      Re: eval() or What? Gene Wirchenko <genew@ocis.net> - 2011-12-28 17:42 -0800
        Re: eval() or What? Jake Jarvis <pig_in_shoes@yahoo.com> - 2011-12-29 22:39 +0100
          Re: eval() or What? Gene Wirchenko <genew@ocis.net> - 2011-12-29 14:08 -0800
            Re: eval() or What? Stefan Weiss <krewecherl@gmail.com> - 2011-12-31 00:17 +0100
    Re: eval() or What? Dr J R Stockton <reply1152@merlyn.demon.co.uk> - 2011-12-29 19:57 +0000

#9745 — eval() or What?

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

[toc] | [next] | [standalone]

#9747

On 29.12.2011 00:29, Gene Wirchenko wrote:
> 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'?

-- 
Jake Jarvis

[toc] | [prev] | [next] | [standalone]

#9750

On Thu, 29 Dec 2011 01:08:37 +0100, Jake Jarvis
<pig_in_shoes@yahoo.com> wrote:

>On 29.12.2011 00:29, Gene Wirchenko wrote:
>> 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

[toc] | [prev] | [next] | [standalone]

#9770

On 29.12.2011 02:42, Gene Wirchenko wrote:
> On Thu, 29 Dec 2011 01:08:37 +0100, Jake Jarvis
> <pig_in_shoes@yahoo.com>  wrote:
>
>> On 29.12.2011 00:29, Gene Wirchenko wrote:
>>> 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.
>

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?

-- 
Jake Jarvis

[toc] | [prev] | [next] | [standalone]

#9771

On Thu, 29 Dec 2011 22:39:17 +0100, Jake Jarvis
<pig_in_shoes@yahoo.com> wrote:

[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

[toc] | [prev] | [next] | [standalone]

#9815

On 2011-12-29 23:08, Gene Wirchenko wrote:
> On Thu, 29 Dec 2011 22:39:17 +0100, Jake Jarvis
>>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.

It doesn't seem obvious to me at all. In fact, when I read "the
properties will have string values of code to be executed", a big red
flag goes up in my mind. There are very few designs which require code
to be evaluated on the fly. A form validator seems like an unlikely
candidate (unless you want your users to enter custom validation code,
or you have other external code sources).

In my experience, 90% of validation tasks can be easily generalized. For
example:

- has the field been filled out?
- does the entered value have the correct format?
    - numeric
       - integer
       - positive/negative
       - precision
    - monetary amount (maybe with currency)
    - email address
    - phone number
    - date
- does the entered value exceed defined boundaries?
    - min/max values for numbers, dates
    - min/max string length
- does the entered value match a given regular expression?

This is not comprehensive, of course, it's just off the top of my head.
Your application will likely have other typical formats which can be
generalized (customer numbers, case numbers, etc). The point is that
these general routines can (and IMHO should) be written as methods of
your validation library, instead of being evaluated as raw code. In the
remaining 10% of cases where automated validation is not (easily)
possible, you can provide a custom callback function.

Instead of directly manipulating local variables, I would define an API
for each of the validation modules/routines. At the very minimum, they
should receive the DOM element being validated or its value, and the
validation options (see list above). As for the return value, this could
be true/false for success/failure, or an error string, an error code, or
whatever else matches your needs.

I have written several form validator objects in the past; they're quite
different from each other, depending on the customer and the framework
they were supposed to fit into. As a minimal (simplified) example, the
validation script for a form with two fields might look like this:

  var fv = new FormValidator(document.forms[0]);
  fv.addWatchedFields({
      datePublished: {
          type: "date",
          min: "1980-01-01",
          max: "today"
      },
      title: {
          type: "string",
          required: true,
          max: 200    // characters
      }
  });

The FormValidator will then monitor the "datePublished" and "title" form
elements. Whenever a value has changed (or the form is being submitted,
or the field sends a blur event, etc), it can call a method like

   function checkWatchedField (node, opts) {
       if (opts.type == "date") {
           return checkDateField(node, opts);
       } elsif (opts.email) {
           return checkEmailField(node, opts);
       }
       // etc
   }

That's just one of many ways to implement a validator. The important
thing is that there is no need for eval()ing code anywhere; it's all
just methods of a FormValidator object.


- stefan

[toc] | [prev] | [next] | [standalone]

#9774

In comp.lang.javascript message <fn8nf756jclubi6uu8510fcqjt57lhcd15@4ax.
com>, Wed, 28 Dec 2011 15:29:43, Gene Wirchenko <genew@ocis.net> posted:

>     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.

-- 
 (c) John Stockton, Surrey, UK.  ?@merlyn.demon.co.uk   Turnpike v6.05   MIME.
   Web  <http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web