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" <[EMAIL PROTECTED]>
To: "DynAPI Development List" <[EMAIL PROTECTED]>
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 ([EMAIL PROTECTED])
> > Software ontwikkelaar
> > Oberon Informatiesystemen b.v.
> > http://www.oibv.com
>
>
> > _______________________________________________
> > Dynapi-Dev mailing list
> > [EMAIL PROTECTED]
> > 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
> [EMAIL PROTECTED]
> 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
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
