concept to avoid multiple script problems

[djr33]

I was just thinking about a script (the recent slideshow posted in the submitted section), and trying to think about a solution to allow, without a lot of recoding, for the script to have multiple instances.
This is very true of many scripts; users want more than one, and doing so would cause problems due to variable names and such.

So, the idea that we all know about is renaming the variables and names/id's of the elements.

However, this is something of a pain.

Is it possible for javascript to generate javascript?

One could simply make the entire script a string within a host script, then change the variable names upon each creation.

Short of this, the solution I could see if PHP in that the javascript would, upon each request for an instance of the script, call the javascript at "myscript.php" (as an external .js file), using a get variable to specific a prefix (or suffix) to the variables, allowing multiple instances.

Basically, the idea is an instance generator. This could be a very helpful improvement to many scripts and an easy way to solve the frequent questions regarding this issue. It would also allow for no specific recoding of the scripts, but just a quick analysis as to which variables etc should be altered to allow for multiple versions, then that could be built into a standard javascript (or if need be PHP) framework to generate these.

Thoughts?

[jscheuer1]

Actually, this is what the 'this' keyword in Object Oriented javascripting is all about. To oversimplify things, instead of:

var something=whatever;

you use:

this.something=this.whatever;

As I say, it is an oversimplification and generally requires you to also create a master function with prototype functions. Due to coding requirements, other identifiers must sometimes be used in place of the 'this' keyword. The prototype functions are shared by all instances but their threads are kept separate.

Have a look at the code here:

http://home.comcast.net/~jscheuer1/s...onveyor_oo.htm

Compare it with the code here:

http://www.dynamicdrive.com/dynamici...rightslide.htm

[djr33]

Interesting, and that makes sense.

But then why is it so hard to help those who want multiple instances? It just seems like my solution is quite simple and requires no changes except a one-time creation of a generation system, then just picking which variables should be changed each time.

To me, it sounds a lot more simple, but this is do to my unfamiliarity with the above method. It certainly sounds fine, if it works, but also seems, due to the difficulty that seems to exist in making scripts work with multiple instances, that another method might be helpful.

[jscheuer1]

Well, I've had some experience doing these types of conversions. That one went fairly smoothly and I think it took me two hours. It could have been faster. I wasn't working on a deadline. I certainly wasn't being a slow poke about it.

Now, I learn things mostly by doing so, it would be difficult for me to teach this 'conversion method' yet as, even though I've done it about ten times, that isn't enough for me to quite have it down to a formula.

Depending upon the script, it can be a relatively simple or a quite complex operation.

There may well be a simpler method, I've often thought that there should be. But, I haven't found one yet.

[djr33]

Well, here's what I got for this script using this method--
http://www.dynamicdrive.com/forums/s...3081#post83081

View Here:
http://www.ci-pro.com/misc/phptest/j...slideshows.htm

Please move to that thread for specific discussion of that script, obviously.

But discussion of the method is fine here.

It works. I can't say it's pretty, yet, but I think with some work it would be great. Just needs a bit more automation (nothing that wouldn't be needed if you were using the 'this' method), and it should be easy.

[Twey]

It's certainly possible, but it's not very nice. For a large script, that involves packing the whole thing into a string, including escaping quotes and things, and replacing all variable names with dynamically-generated ones, which is one heck of a lot of slog-work. There are also problems with the finished result: code reuse is one of the biggest no-nos in software design, and is, in fact, the whole reason that functions were invented. To have fifteen different instances of a script in the page, it would have to be written out fifteen times. Especially when factoring in the effort involved in implementing a "generator," it's really much easier and neater just to properly object-orient the script.

[djr33]

I can see your points. However--

1. There's no escaping needing. Note the PHP posted in the other thread. I'm using the <<<EOF .... EOF; method.

2. The code, whether by function, explicit text-existance or a work of God, will exist in full in the sense that it is running in your system. 30 instances of a function or 1 instance running 30 times will have the same effect, with the difference of a few kilobytes that are kinda annoying but won't even slow down a 56k modem. Additionally, this is NOT explicitly written out, but rather a function in PHP to generate the instances, able to be called dynamically. This may feel like more generated, but it's the same as would be running in the memory if it were a function and also no more text to deal with for the programmer, just the php generator and one instance of the code, using {$x+} ($x is the variable of the for loop) that allows each variable name to be unique.

3. Sure, there's effort involved in a generator, but there's also effort involved in converting. The generator may be tedious, but the conversion of a javascript function to an object oriented method could be hard and requires knowledge of more than I know about javascript, certainly. This may be easy for you, but, if it is, then why all the complaints when someone asks for an OO script version of something? The generator has potential as a generalized solution with all it requires is someone to look through and find all the variable/function names that need to be individualized. That took very little time compared with the rest of it, from setting up the for loop correctly to setting up the more intricate details like the onLoad call and the CSS. Once those things get a little simpler as I play with the script more, I see it having a lot more use.

[Bob90]

Really OO is all you need. I try to make all my code work with multiple instances (If I think necessary) and it really shouldn't be that hard. All this PHP malarky will get you no-where; surely for each extra call to the dynamic function you add the size of the javascript to the page. I know it's a trivial size nowadays, but PHP it isn't elegant; its a long winded solution.
Well, thats what I think anyway.

[Twey]

1. There's no escaping needing. Note the PHP posted in the other thread. I'm using the <<<EOF .... EOF; method.

You're right, sorry.

2. The code, whether by function, explicit text-existance or a work of God, will exist in full in the sense that it is running in your system. 30 instances of a function or 1 instance running 30 times will have the same effect, with the difference of a few kilobytes that are kinda annoying but won't even slow down a 56k modem.

But not here. One function running multiple times is one function running multiple times: the function need only be created once, and exists only once in memory. Thirty functions exist thirty times, and take up thirty times as much memory.

3. Sure, there's effort involved in a generator, but there's also effort involved in converting. The generator may be tedious, but the conversion of a javascript function to an object oriented method could be hard and requires knowledge of more than I know about javascript, certainly. This may be easy for you, but, if it is, then why all the complaints when someone asks for an OO script version of something?

Not easy, no: it requires a complete rewrite of the script. However, it would probably, for a small, simple script, take roughly the same amount of time as going through said script looking for each and every variable instance, and the end result would be much neater and more efficient.

Bob90 is completely correct, as well: it's just an ugly solution. It's slow, big, and hackish, using slog work over neat, imaginitive and efficient thinking.

[jscheuer1]

I'm with Twey and Bobo9 here. When I left the door open for you to come up with your own 'better' solution this is not at all what I had in mind. I'm reminded a little of the child with a toy hammer, suddenly everything needs hammering. You seem to be (in this case at least) like that, only your hammer is PHP. I do admire your command of that language and wish that I had even half as much but, this is clearly not the way to go here - if for no other reason than it presents another language dependency. With javascript you depend upon its being available, if you include PHP for modularity, you are limiting its utility to servers with PHP and clients with javascript. Since modularity is, relatively speaking easy enough in javascript and, you already require that language, you should stick with it so as to have only one
'language lag'. I also agree with the criticism about the multiple versus reusable functions.