I thought we might use this thread to share some tips on creating self encapsulating scripts when coding, so to minimize the chances of conflicts occurring between our script and others on the same page. I'm sure Alex (mod of XML forum) will have something to say here heh.
Tip on avoiding variable conflicts:
One of the most common conflicts with scripts occurs with identical variable names. This is the result of coders picking common names as variables, such as x, y etc. One way to minimize this problem from occurring is to define variables as properties of a custom object:
Code:
var glidescript=new Object()
glidescript.x=50
glidescript.y=150
glidescript.text="welcome to my homepage!"
This way, we only have to worry about "glidescript" being unique on the page, and not any of its properties such as x, y, speed etc.
Please add your tips here.
__________________
- George
- JavaScript Kit- JavaScript tutorials and 400+ scripts!
- JavaScript Reference- JavaScript reference you can relate to.
Once there is a significant amount of replies, you should make this thread sticky.
Anyway, for DHTML effects I highly recommend looking into IE's element/ViewLink behaviors (not too complicated to learn at all), and Gecko's XBL (definitely a little tougher - but you have a resident expert frequenting these forums ).
You can then assign elements their effect through CSS, instead of hardcoding references, which means infinite code reuse on the same page, and exactly 0 conflicts with other scripts (unless they also use a behavior/binding, which is when you'll need to look into the addBehavior() and addBinding() methods).
OO JavaScript is a little harder to learn but it is possible to turn a conventional procedural JavaScript into an Object so it won't interfere with other scripts or itself.
It is just a pity that there seem to be very few public scripts that use OO methods to learn from.
I have some links somewhere to how to create OO scripts. I'll post them when I find them.
__________________
The answer does not come from thinking outside the box, it comes from realizing the truth :-
"There Is No Box". [JavaScript Gadgets'n'Gizmos][JavaScript-FX]
Good tips guys. I think we also need to take into account rapid deployment though. For example, creating an object class is quite a bit more work than merely creating an object on the fly, and in many situations, the later alone will do nicely.
How about another potential conflict that has to do with two scripts both accessing the same event handler? For example:
NOTE: I have put javascript code examples between [ php ] vbCode as it color codes the syntax (but it really is JavaScript).
Quote:
For example, creating an object class is quite a bit more work than merely creating an object on the fly, and in many situations, the later alone will do nicely.
I agree. It should make converting existing scripts a lot easier.
As for the "onload" one method you could use is
PHP Code:
//Save a reference to the existing onload handler
var oldOnload = window.onload;
function gliderStart()
{
//If there was an old onload handler, execute it
if(oldOnload) oldOnload();
//Code to initialize glider script
}
//point the window.onload to my handler
window.onload=gliderStart;
This relies on your script being inserted last in the document. If another script simply assigns the onload handler :-
window.onload=anotherFunc;
then it will wipe out your handler.
A better solution to the onload problem would be if the window object had an "addOnloadHandler()" method so you could add your init method to a chain of onload handlers without wiping out existing onload handlers. We can implement this ourselves with the following code.
PHP Code:
/**** Start onload Code ****/
var initFuncs = new Array();
function addOnloadHandler(func)
{
initFuncs[ initFuncs.length ] = func;
}
function initAll()
{
for(var i=0 ; i<initFuncs.length ; i++)
initFuncs[i]();
}
window.onload=initAll;
/**** End - onload code ***/
This code could be put into the head of all your documents
You could also place it in an external ".js" file and include it into all documents that require an onload handler.
You would then replace all
"window.onload=myFunc"
with
"window.addOnloadHandler(myFunc);
It may sound arcane but be indulgent: my solution to this riddle was to make an object name so much shared as possible: write once, borrow everywhere.
In Java, each class has its methods, at most you can have an interface (those strongly data typed languages really cause a significant waste of code with the strong call for overloaded methods: we have javas in a nutshell which exhibits for each class at times hundreds of functions that include the very same code and just a couple of commas different to accomodate different input data type). Each class incapsulates its methods.
In my approach, each method is lent to each class, without implementing the interface.
Basically was developed on layers for Dhtml:
var foo= new layerManager("foo");
now you have a method which is cognizant of how that constructor works
function moveEllipse(){
this...
this...
if(!this...){this...=...}
}
then you can borrow to each manager the method by using a second constructor:
foo.moveEllipse=new managerMethod("moveEllipse")
each layerManager can therefore hold methods with an identical name without this causing any conflict and with the method wrtitten only once and not thousand of times to accomodate differnent combinations of layers.
foo.moveEllipse.execute() triggers the method on foo.
I think it may be a curiosity to add to this thread for it is an attempt, partially successful, to solve the problem of shared names by pioneering exactly in the direction one wouldn't have ventured to. I called it ULMA (Universal Layer Management APPROACH), maybe it can give an interesting outlook for further developements on the thread issue.
Just my two cents.
__________________
Alberto http://www.unitedscripters.com/
__________________
"The first step to confirming there is a bug in someone else's work is confirming there are no bugs in your own."
June 30, 2001
author, Verbosio prototype XML Editor
author, JavaScript Developer's Dictionary https://alexvincent.us/blog