dynapi-dev

[Dynapi-Dev] DynAPI current things

[Pascal <pb...@oi...>]

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

Re: [Dynapi-Dev] DynAPI current things

[Richard B. <ma...@ri...>]

Good points overall,
> * 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)

I think DOM code should always be default, tested on the latest Mozilla
milestone, so no is.dom checks should be found, because NS6 has lots of bugs
which might require workarounds.

Richard

----- Original Message -----
From: "Pascal" <pb...@oi...>
To: <dyn...@li...>
Sent: Thursday, February 22, 2001 12:40 PM
Subject: [Dynapi-Dev] DynAPI current things

Re: [Dynapi-Dev] DynAPI current things

[Jordi - I. - M. <jmi...@or...>]

I agree in all four points ( damm I can't remember not agreeing with Pascal, I
wonder if it is healthy ). If browsers are moving towards DOM compliance (insert
your favourite joke here) then so should the API.

I'll try to give it a shot myself this weekend. We'll see. I foresee that Eytan
will have plenty to say regarding the object structure, as well as many others.
Please do.

Quoting Richard's quote: "Don't go crazy with multiple soft levels. Keep it
simple"

Richard Bennett wrote:

> Good points overall,
> > * 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)
>
> I think DOM code should always be default, tested on the latest Mozilla
> milestone, so no is.dom checks should be found, because NS6 has lots of bugs
> which might require workarounds.
>
> Richard
>
> ----- Original Message -----
> From: "Pascal" <pb...@oi...>
> To: <dyn...@li...>
> Sent: Thursday, February 22, 2001 12:40 PM
> Subject: [Dynapi-Dev] DynAPI current things
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev

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

Re: [Dynapi-Dev] DynAPI current things

[Robert R. <rra...@ya...>]

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/

Re: [Dynapi-Dev] DynAPI current things

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

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

Re[2]: [Dynapi-Dev] DynAPI current things

[Robert R. <rra...@ya...>]

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/

Re: Re[2]: [Dynapi-Dev] DynAPI current things

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

that sounds like a distinct possiblity


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

RE: Re[2]: [Dynapi-Dev] DynAPI current things

[Pascal B. <pa...@dy...>]

Hmm..

Just noticed I'm not using any of that code in dynacore.. (went back to old
addchild() code)
not sure, but I think I don't have problems with anything...

other thought, can't we set the .dyndoc in the createelement? (already done
for "top-level" child layers -they get the doc property according to the
parent) and child layers are created after that, so could then have there
dyndoc set.

strange... needs some looking into I guess.

Pascal Bestebroer
pa...@dy...
http://www.dynamic-core.net

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Robert Rainwater
> Verzonden: donderdag 22 februari 2001 18:09
> Aan: DynAPI Development List
> Onderwerp: Re[2]: [Dynapi-Dev] DynAPI current things
>
>
>
> 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/
>
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>