Re: [Dynapi-Dev] DynAPI current things

[Doug M. <do...@cr...>]

since I am insterested in anything that speeds up the API,
I will help test if code is broken.
(if you like)
----- Original Message -----
From: "Pascal" <pb...@oi...>
To: <dyn...@li...>
Sent: Thursday, February 22, 2001 3:40 AM
Subject: [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


---
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