> * 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
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
