Menu
▾
▴
Re[2]: [Dynapi-Dev] DynAPI current things
|
From: Robert R. <rra...@ya...> - 2001-02-22 17:06:09
|
We have that with the .doc property. The problem is that it doesnt know its .doc until the top level dynlayer has been added to the document using addchild. So when the top level layer is added, it then goes through all the children to set the .doc. Perhaps we can remove the .doc property and replace it with a getDocument(). Then, the traversing is only done when someone requests the document of a layer. -- // Robert Rainwater On 2/22/2001, 2:44:51 PM EST, Doug wrote about "[Dynapi-Dev] DynAPI current things": > would it make things any bigger > if each layer has a this.rootDoc property? > This would allow you to avoid having to > "search all the way to the top of the chain" > no? > ----- Original Message ----- > From: "Robert Rainwater" <rra...@ya...> > To: "DynAPI Development List" <dyn...@li...> > Sent: Thursday, February 22, 2001 8:41 AM > Subject: Re: [Dynapi-Dev] DynAPI current things >> >> One of the things that can slow down layer creation when you have lots >> of children it the addChildID. The reason for this method is because >> it has to search all the way to the top of the chain to find out who >> is dyndoc is. If we can find a way to set the dyndoc during the >> addChild is would speed up things a lot. >> >> -- >> // Robert Rainwater >> >> On 2/22/2001, 6:40:37 AM EST, Pascal wrote about "[Dynapi-Dev] DynAPI > current things": >> >> > Here's a list of thing I want to change in the current DynAPI code. I'm > not >> > searching for long discussions here, but I want to hear some (short) >> > opinions and mainly from the people actually involved in the > development. >> >> >> > * Do some speed optimisations >> > Mainly changes to the createElement as I did on dynacore as test, and > seem >> > to speed things up very nicely, without breaking code. also some > checking >> > on why the latest release is so much slower (have to test this for > myself >> > though because haven't seen it myself, just from others) >> >> > * 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). >> > This should prove first steps towards support for true DOM compliant >> > browsers (they should then work for a large part) >> >> > * 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. >> >> > * addChild() change >> > AddChild currently supports multiple children as parameter at once.. no > body >> > uses it, no body should. 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. >> >> > * 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. >> >> >> > I'm planning on doing the first two points this weekend and possible a > few >> > others.. the only thing that will be time consuming is the "Better > object >> > arrangement" (means ALOT of testing to see if nothing got broken) >> >> > 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 :) >> >> >> >> > Pascal Bestebroer (pb...@oi...) >> > Software ontwikkelaar >> > Oberon Informatiesystemen b.v. >> > http://www.oibv.com >> >> >> > _______________________________________________ >> > Dynapi-Dev mailing list >> > Dyn...@li... >> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev >> >> >> ---------------------- >> DynAPI Snapshots: http://dynapi.sourceforge.net/snapshot/ >> DynAPI Homepage: http://dynapi.sourceforge.net/ >> >> >> >> _______________________________________________ >> Dynapi-Dev mailing list >> Dyn...@li... >> http://lists.sourceforge.net/lists/listinfo/dynapi-dev >> > --- > Outgoing mail is certified Virus Free by AVG Free Edition > Download at: http://www.grisoft.com/html/us_index.cfm > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01 > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev ---------------------- DynAPI Snapshots: http://dynapi.sourceforge.net/snapshot/ DynAPI Homepage: http://dynapi.sourceforge.net/ |
