From: <ni...@pr...> - 2001-02-22 19:54:31
|
> * Do some speed optimisations > Mainly changes to the createElement that sounds great1 > * DOM defaults > All "if (is.xx) else..." statements should be changed so that the NS6 code > is always the default (basically, no NS6 check should be left in the code). i don't think ns 6 is a true DOM browser yet and also if that's the case then code like : doc.captureEvents(Event.MOUSEMOVE | Event.MOUSEDOWN | Event.MOUSEUP | Event.CLICK | Event.DBLCLICK); doc.onmousemove=doc.onmousedown=doc.onmouseup=doc.onclick=doc.ondblclick=DynObject.prototype.MouseEventMethod;}; should be defalut to this : doc.addEventListener('mousemove',DynObject.prototype.MouseEventMethod,false); doc.addEventListener('mousedown',DynObject.prototype.MouseEventMethod,false); doc.addEventListener('mouseup',DynObject.prototype.MouseEventMethod,false); doc.addEventListener('click',DynObject.prototype.MouseEventMethod,false); doc.addEventListener('dblclick',DynObject.prototype.MouseEventMethod,false); and this for now it's supported only on ns 6 may be ie 6 > * Better object arrangement > Split event code up for mouseevents/normalevent-invoking (like Michael did). > And also split DynLayer/DynDocument into DynObject/DynLayer/DynDocument as > did in dynacore. Should prove to be easier to "get into the code" with > DynObject handling ALL parent/child relations, and DynLayer only doing that > what it should: dynamic layers handling. both of this make sense > * addChild() change > AddChild currently supports multiple children as parameter at once.. no body > uses it, no body should. I actually use it a lot and saves a lot of lines of code when u have some layer: DynAPI.document.addChild(layer1) DynAPI.document.addChild(layer2) DynAPI.document.addChild(layer3) DynAPI.document.addChild(layer4) DynAPI.document.addChild(layer5) DynAPI.document.addChild(layer6) DynAPI.document.addChild(layer1,layer2,layer3,layer4,layer5,layer6) sorry I like the second better Removing support for that should also give a slight > speed increase (the child is already supplied as parameter to the function, > so I think it will be seen as a local variable) no need to walk thru an > array, which is an extra loop not needed. the support for multiple children > adding at once, could be created by users them self..not very hard to do. wouldn't be enough to check for arguments.length and do an if else that will support both > * DynDocuments adding to DynAPI > All DynDocuments should be child objects of the DynAPI object, this way you > get a true DynAPI tree which can be used to access ANY object created by the > DynAPI.. Only code that needs to be changed for this by users is code that > used frames (the dyndocument generated should become > DynAPI.addChild(dyndocument-name)) Should also prove handy in any > memory-cleaning needed. this will give better controll with frames ! > Any, helpful, takes on these ideas are welcome.. but please don't make this > a long discussion thread.. if some one doesn't like it we can discuss it, > but otherwise I'll start on it this weekend (unless some one else does it > before that :) I hope I didn't make any one mad now just my opinion rocks welcome ciao Y |