A valid use of eval?

[Mike]

After reading much on the evils of eval, I have a question using my
own personal use of the function...

We have a reports system that will generate reports based on a number
of parameters available on a blotter at the top of our report system.
Each report could (and does) use a combination of some (but not all)
of these 15 parameters.

Each report also has a series of precalculations that need to be run
before the report can execute.

My solution was to create a string for each report
"ReportName~parameter~parameter~parameter"
built dynamically, and eventually parse the string in an execution
function that resolves it to a full function call

"ReportName('parameter','parameter','parameter ');"
which is the Evalled to execute

As this is only a single line of code to Eval, it seemed the most
logical and probably reasonably inexpensive.

My question is is this a common misuse of eval, or one of the few
cases where it makes sense to use? I realize that my example doesn't
necessarily flesh out enough detail regarding judgement of the entire
report launching concept, but trust me when I say that "eval" has cut
my code down by several 100 lines!

Regards
Mike

[Erwin Moller]

Mike wrote:

Hi Mike

After reading much on the evils of eval, I have a question using my
own personal use of the function...

We have a reports system that will generate reports based on a number
of parameters available on a blotter at the top of our report system.
Each report could (and does) use a combination of some (but not all)
of these 15 parameters.

Each report also has a series of precalculations that need to be run
before the report can execute.

My solution was to create a string for each report
"ReportName~parameter~parameter~parameter"
built dynamically, and eventually parse the string in an execution
function that resolves it to a full function call

"ReportName('parameter','parameter','parameter ');"
which is the Evalled to execute

As this is only a single line of code to Eval, it seemed the most
logical and probably reasonably inexpensive.

My question is is this a common misuse of eval, or one of the few
cases where it makes sense to use? I realize that my example doesn't
necessarily flesh out enough detail regarding judgement of the entire
report launching concept, but trust me when I say that "eval" has cut
my code down by several 100 lines!
I think you just described a perfectly good situation to use eval.
:-)

And people who think eval is evil are zealots IMHO.
If it suits your needs: use it.

It is just that many people use eval where they could also use a perfectly
normal, valid, easy-to-read alternative...

Regards,
Erwin Moller

Regards
Mike

[Lee]

Mike said:

After reading much on the evils of eval, I have a question using my
own personal use of the function...

We have a reports system that will generate reports based on a number
of parameters available on a blotter at the top of our report system.
Each report could (and does) use a combination of some (but not all)
of these 15 parameters.

Each report also has a series of precalculations that need to be run
before the report can execute.

My solution was to create a string for each report
"ReportName~parameter~parameter~parameter"
built dynamically, and eventually parse the string in an execution
function that resolves it to a full function call

If you're building this string dynamically on the server, why not
just build the function call dynamically, instead?

[Csaba Gabor]

You are parsing a string to construct a function call,
then using eval on that.
The following sample script shows how to avoid your use of eval:

<script type='text/javascript'>
function ReportName () { // just shows the arguments
report = "";
for (var i=0;i<arguments.length;++i)
report += (i ? ", " : "") + arguments[i];
alert (report);
}
var ReportString = "ReportName~my param~parameter 2~parm 3";
var aRep = ReportString.split("~");
window[aRep[0]].apply(window, aRep.slice(1)); // replaces the eval
</script>

Something that struck me in your description: that string you are
constructing - would it not make sense to have it be an array in
the first place? Or better yet, an object where each key is the
parameter name. Strikes me that your code might be more
understandable that way.

For example,
oReport = {}; // this object collects report parameters
oReport.functionName = "ReportToRun";
oReport.source = "Mike's database"; // parameter 1

Csaba Gabor from Vienna
Mike wrote:

After reading much on the evils of eval, I have a question using my
own personal use of the function...

My solution was to create a string for each report
"ReportName~parameter~parameter~parameter"
built dynamically, and eventually parse the string in an execution
function that resolves it to a full function call

"ReportName('parameter','parameter','parameter ');"
which is the Evalled to execute

As this is only a single line of code to Eval, it seemed the most
logical and probably reasonably inexpensive.

My question is is this a common misuse of eval, or one of the few
cases where it makes sense to use? I realize that my example doesn't
necessarily flesh out enough detail regarding judgement of the entire
report launching concept, but trust me when I say that "eval" has cut
my code down by several 100 lines!

Regards
Mike

[Lasse Reichstein Nielsen]

mi**********@uk.standardchartered.com (Mike) writes:

My solution was to create a string for each report
"ReportName~parameter~parameter~parameter"
built dynamically, and eventually parse the string in an execution
function that resolves it to a full function call

"ReportName('parameter','parameter','parameter ');"
which is the Evalled to execute
This fails if any of the parameters contain the single-quote
character.

One of the reasons using eval is dangerous is that turning values into
literals is neeed, and forgetting it will work in most cases ... (yes,
that is bad, not good!)

I assume the "ReportName" function is defined as a global variable.
Then try this as a global function:
---
function doReport(codedString) {
var parts = codedString.split("~");
this[parts[0]].apply(this, parts.slice(1));
}
---
No eval, and probably shorter than your code :)
As this is only a single line of code to Eval, it seemed the most
logical and probably reasonably inexpensive.
Probably not too dangerous either.
My question is is this a common misuse of eval, or one of the few
cases where it makes sense to use?
It depends. If you are targeting browsers too old to have "apply",
it's probably the simplest way. You could do:
---
function doReportNoApply(codedString) {
var p = codedString.split("~");
this[p[0]](p[1],p[2],p[3],p[4],p[5],p[6],p[7],p[8],p[9],
p[10],p[11],p[12],p[13],p[14],p[15]);
}
---
since you know that there are at most 15 arguments.
I realize that my example doesn't necessarily flesh out enough
detail regarding judgement of the entire report launching concept,
but trust me when I say that "eval" has cut my code down by several
100 lines!

Sounds likke 100 lines deserving to be cut :)

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[Dr John Stockton]

JRS: In article <7b**************************@posting.google.com >,
dated Thu, 14 Apr 2005 07:45:07, seen in news:comp.lang.javascript, Mike
<mi**********@uk.standardchartered.com> posted :

After reading much on the evils of eval, I have a question using my
own personal use of the function...

We have a reports system that will generate reports based on a number
of parameters available on a blotter at the top of our report system.
Each report could (and does) use a combination of some (but not all)
of these 15 parameters.
But each report function can be given, with negligible overhead, all 15
parameters - you're only passing the identity of an object, and within
the report function you can give sensible names to the wanted ones and
names such as x0 x1 ... to the others. Calling them all x would be
inelegant, unless it can be shown both legitimate and safe.

You can now put the report function names in an array

function RepFn0(p1, ..., p15) { ... }
function RepFn1(p1, ..., p15) { ... }
function RepFn2(p1, ..., p15) { ... }
....

var AllRepFns = [RepFn0, ...]
Each report also has a series of precalculations that need to be run
before the report can execute.
The entries in AllRepFns can be enhanced to be objects containing not
only the function name but also a list of names of precalculations.

....
My solution was to create a string for each report
"ReportName~parameter~parameter~parameter"
built dynamically, and eventually parse the string in an execution
function that resolves it to a full function call

"ReportName('parameter','parameter','parameter'); "
which is the Evalled to execute
.... and execute by AllRepFns[n](P1, ..., P15)

Or the array could be generalised into a simple Object, using the name
of the report to select the correct RepFn# or the Object holding it.

You end up with table-driven control, with the table held in objects
and/or arrays.

Take a glance at "Data", in the textarea, at the end of <URL:http://www.
merlyn.demon.co.uk/holidays.htm>, and similar in the source.
As this is only a single line of code to Eval, it seemed the most
logical and probably reasonably inexpensive.
All you need do is see if the process is significantly slower using eval
for (say) the quickest and slowest functions in comparison with a direct
call, on your slowest target machine. Not detectably but significantly.
My question is is this a common misuse of eval, or one of the few
cases where it makes sense to use? I realize that my example doesn't
necessarily flesh out enough detail regarding judgement of the entire
report launching concept, but trust me when I say that "eval" has cut
my code down by several 100 lines!

It is at worst a rare misuse, IMHO.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 IE 4 ©
<URL:http://www.jibbering.com/faq/> JL/RC: FAQ of news:comp.lang.javascript
<URL:http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources.
<URL:http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.

[fox]

Mike wrote:

After reading much on the evils of eval, I have a question using my
own personal use of the function...

We have a reports system that will generate reports based on a number
of parameters available on a blotter at the top of our report system.
Each report could (and does) use a combination of some (but not all)
of these 15 parameters.

Each report also has a series of precalculations that need to be run
before the report can execute.

My solution was to create a string for each report
"ReportName~parameter~parameter~parameter"
built dynamically, and eventually parse the string in an execution
function that resolves it to a full function call
window["ReportName~parameter~parameter~parameter"](/*optional args*/);

should have the same result... no eval() necessary...

"ReportName('parameter','parameter','parameter ');"
which is the Evalled to execute

As this is only a single line of code to Eval, it seemed the most
logical and probably reasonably inexpensive.

My question is is this a common misuse of eval, or one of the few
cases where it makes sense to use? I realize that my example doesn't
necessarily flesh out enough detail regarding judgement of the entire
report launching concept, but trust me when I say that "eval" has cut
my code down by several 100 lines!

Regards
Mike

[runonthespot]

Interesting idea, the apply code. I'm going to look into this,
possibly in combination with Csaba's ideas on using a Report Object.

Perhaps a good combination is to build a report object with an array
for parameters, and then use apply function to apply said array to the
report function?

I guess it makes it nice and readable too, and I have the added plus
that I can use array methods to tag additional items to the parameter
array if required (sometimes the report is able to recall itself with
additional optional parameters to allow drill down), which would be
easier to understand than a bunch of gratuitous splits and dynamic
function building.

Since I'll be calling the launcher function seperately, I can just pull
the reportname from the Report object and apply precalculations if
necessary before launching.

Should I then have an array of those objects?

Sigh... it all gets complicated way too quickly. One of my favourite
and worst things about Javascript, is that it really makes it easy to
"go" with a idea and get really far before discovering a Better Way :-)

I think I'm going to have to go back to coding in Paper Script for a
bit...

I think I quite like this approach...

[runonthespot]

Maybe a generic scenario will help get this solved.

Let's say for example I have 3 reports with the following parameters
OrderReport (Location [,Customer Number]);
ProductReport (ProductId [,Location [,Customer Number] ] );
StockReport (ProductId [,Location [,ProductAisle]]);

Initially from a combo, you could run an Order or Stock report for a
location, a Product Report for a specific Product.

Once the report is up, it could contain within it a dropdown of all
Customers (Order), Locations (Product/Stock Report), that would rerun
the report with that added layer of detail. (As the report is actually
dynamically generated XSLT in my case, lets just assume that it is
necessary to rerun the report when drilling down)

Let's say that there are 2 dropdowns at the top of the form for these
parameters (Location, ProductId) which always have at least one value.

Should I build an array of those functions? How do I ensure that those
functions get the right parameters each time, but can also be called
from within the reports with additional parameters?

Should the parameters be summarily scrapped in this instance and
replaced with a "parameters object" that contains all of the possible
parameters that each function can dip into as and when required?

Thanks so far to all who have contributed to this thread. Really great
ideas being thrown around.
Mike

[runonthespot]

Maybe a generic scenario will help get this solved.

Let's say for example I have 3 reports with the following parameters
OrderReport (Location [,Customer Number]);
ProductReport (ProductId [,Location [,Customer Number] ] );
StockReport (ProductId [,Location [,ProductAisle]]);

Initially from a combo, you could run an Order or Stock report for a
location, a Product Report for a specific Product.

Once the report is up, it could contain within it a dropdown of all
Customers (Order), Locations (Product/Stock Report), that would rerun
the report with that added layer of detail. (As the report is actually
dynamically generated XSLT in my case, lets just assume that it is
necessary to rerun the report when drilling down)

Let's say that there are 2 dropdowns at the top of the form for these
parameters (Location, ProductId) which always have at least one value.

Should I build an array of those functions? How do I ensure that those
functions get the right parameters each time, but can also be called
from within the reports with additional parameters?

Should the parameters be summarily scrapped in this instance and
replaced with a "parameters object" that contains all of the possible
parameters that each function can dip into as and when required?

Thanks so far to all who have contributed to this thread. Really great
ideas being thrown around.
Mike