> Let's hear the views of the other developers: > > 1) Should we implement a common-base file system for > dynlayers?
Yes. > 2) Do you think it will be easier to maintain a > common-base dynlayer file? Yes. Clarification. While having to export a function once you have a browser specific fix is a hassle.. It's an even bigger hassle to have to update code in four seperate files for one fix. If code is common.. it should be common. Then a simple fix can be done once, and in one place. If a browser specific fix does happen, then you can worry about exporting the functions. An idea: instead of having to expore the function to each dynlayer_XXX file.. Is there some way we can 'notify' the main file that a certain function should _NOT_ be inited if it exists in a dynlayer_XXX file for the given browser/platform? Or better, simply overwrite the function in the specific case IE: (fictional case) Given we have a function setBlarg() Given that this function is common for all browsers except for NS 4.x The common code would be loaded first then when the DynLayer_NS4x.js is loaded, it would overwrite the function setBlarg() with the NS specific code. if any other filre (ie; DynLayer_IE5x.js) is loaded the function setBlarg() would stand as declared as the file DynLAyer_IE5X.js would not overwrite it.. SO: case 1 NS4.71 on Windows: load DynLayer_Common.js: setBlarg() is defined then Load DynLayer_NS4.js: setBlarg() is overwritten case 2 IE 5.55 on Windows: load DynLayer_Common.js: setBlarg() is defined then Load DynLayer_IeE5X.js: setBlarg() is not overwritten as the is no defination in this file ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dynapi-Dev mailing list [EMAIL PROTECTED] http://www.mail-archive.com/[EMAIL PROTECTED]/
