From: Pascal <pb...@oi...> - 2001-01-26 07:50:22
|
Now that the release is finished, I think we should change the object model of the dynapi abit. I want to make the same changes as done in dynacore, making a dynobject off which the dyndocument and dynlayer are based. This makes things slightly smaller and also easier to maintain (all parent-child stuff is controlled in the DynObject and updating that will make the DynLayer and DynDocument work the same with one single change) Also dyndocuments should be added to the dynapi, this makes a better object-tree available.. the DynAPI object will then contain child objects (dyndocuments) and this also means that all layers created can be freeed from the unLoad event of the DynAPI (simply walk thru all children of the DynAPI object, and call deleteAllChildren()) I also think the getdocument() is not needed anymore (seeing as I have removed it from dynacore, and everything works) the findLayers() extension should be a method of the DynDocument, not the DynAPI object.. this looks more logicall: DynAPI.document.findLayers() The eventMethod should be possible to combine into one for DynLayer and DynDocument, so that it can be attached to the DynObject (I've done this already, but I think some small bugs for document-events are still happening). any ideas, comments,rocks? Pascal Bestebroer (pb...@oi...) Software ontwikkelaar Oberon Informatiesystemen b.v. http://www.oibv.com > -----Oorspronkelijk bericht----- > Van: dyn...@li... > [mailto:dyn...@li...]Namens Robert Rainwater > Verzonden: vrijdag 26 januari 2001 2:46 > Aan: DynAPI Development List > Onderwerp: [Dynapi-Dev] getDocument > > > > I was wondering if it would be better to move DynAPI.getDocument() to > DynDocument.getDocument(). It seems more logical that getDocument > belongs to DynDocument. Of course DynAPI.getDocument could be kept > for a while too. > > -- > // Robert Rainwater > ---------------------- > 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 > |
From: GORTSILAS A. <ag...@si...> - 2001-01-26 08:01:08
|
I agree with ALL of them!!! Andreas -----Original Message----- From: Pascal [mailto:pb...@oi...] Sent: Friday, January 26, 2001 9:50 AM To: dyn...@li... Subject: RE: [Dynapi-Dev] getDocument Now that the release is finished, I think we should change the object model of the dynapi abit. I want to make the same changes as done in dynacore, making a dynobject off which the dyndocument and dynlayer are based. This makes things slightly smaller and also easier to maintain (all parent-child stuff is controlled in the DynObject and updating that will make the DynLayer and DynDocument work the same with one single change) Also dyndocuments should be added to the dynapi, this makes a better object-tree available.. the DynAPI object will then contain child objects (dyndocuments) and this also means that all layers created can be freeed from the unLoad event of the DynAPI (simply walk thru all children of the DynAPI object, and call deleteAllChildren()) I also think the getdocument() is not needed anymore (seeing as I have removed it from dynacore, and everything works) the findLayers() extension should be a method of the DynDocument, not the DynAPI object.. this looks more logicall: DynAPI.document.findLayers() The eventMethod should be possible to combine into one for DynLayer and DynDocument, so that it can be attached to the DynObject (I've done this already, but I think some small bugs for document-events are still happening). any ideas, comments,rocks? Pascal Bestebroer (pb...@oi...) Software ontwikkelaar Oberon Informatiesystemen b.v. http://www.oibv.com > -----Oorspronkelijk bericht----- > Van: dyn...@li... > [mailto:dyn...@li...]Namens Robert Rainwater > Verzonden: vrijdag 26 januari 2001 2:46 > Aan: DynAPI Development List > Onderwerp: [Dynapi-Dev] getDocument > > > > I was wondering if it would be better to move DynAPI.getDocument() to > DynDocument.getDocument(). It seems more logical that getDocument > belongs to DynDocument. Of course DynAPI.getDocument could be kept > for a while too. > > -- > // Robert Rainwater > ---------------------- > 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 > _______________________________________________ Dynapi-Dev mailing list Dyn...@li... http://lists.sourceforge.net/lists/listinfo/dynapi-dev |
From: labCoat <la...@xe...> - 2001-01-26 08:25:55
|
Pascal, I completely agree! I think that the object model that you are talking about is imperative to the growth of this API. I think that not only should we incorporate it ASAP, but it should have already been done. There are way to many limitations of the existing object model, especially when it comes to using frames. --proteanman On Thu, 25 January 2001, "Pascal" wrote: > > Now that the release is finished, I think we should change the object model > of the dynapi abit. > I want to make the same changes as done in dynacore, making a dynobject off > which the dyndocument and dynlayer are based. This makes things slightly > smaller and also easier to maintain (all parent-child stuff is controlled > in the DynObject and updating that will make the DynLayer and DynDocument > work the same with one single change) > > Also dyndocuments should be added to the dynapi, this makes a better > object-tree available.. the DynAPI object will then contain child objects > (dyndocuments) and this also means that all layers created can be freeed > from the unLoad event of the DynAPI (simply walk thru all children of the > DynAPI object, and call deleteAllChildren()) > > I also think the getdocument() is not needed anymore (seeing as I have > removed it from dynacore, and everything works) > > the findLayers() extension should be a method of the DynDocument, not the > DynAPI object.. this looks more logicall: > > DynAPI.document.findLayers() > > > The eventMethod should be possible to combine into one for DynLayer and > DynDocument, so that it can be attached to the DynObject (I've done this > already, but I think some small bugs for document-events are still > happening). > > > any ideas, comments,rocks? > > Pascal Bestebroer (pb...@oi...) > Software ontwikkelaar > Oberon Informatiesystemen b.v. > http://www.oibv.com > > > -----Oorspronkelijk bericht----- > > Van: dyn...@li... > > [mailto:dyn...@li...]Namens Robert Rainwater > > Verzonden: vrijdag 26 januari 2001 2:46 > > Aan: DynAPI Development List > > Onderwerp: [Dynapi-Dev] getDocument > > > > > > > > I was wondering if it would be better to move DynAPI.getDocument() to > > DynDocument.getDocument(). It seems more logical that getDocument > > belongs to DynDocument. Of course DynAPI.getDocument could be kept > > for a while too. > > > > -- > > // Robert Rainwater > > ---------------------- > > 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 > > > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev |
From: Pascal B. <pa...@dy...> - 2001-01-26 16:34:23
|
> Just two comments (my rocks supply is starving): Probably because of the transportation problems with rocks..you ordered yours from California aswell? Pascal Bestebroer pa...@dy... http://www.dynamic-core.net |
From: Raides J. <ra...@te...> - 2001-01-26 11:58:40
|
Pascal wrote: > > Now that the release is finished, I think we should change the object model > of the dynapi abit. (... snip ...) > The eventMethod should be possible to combine into one for DynLayer and > DynDocument, so that it can be attached to the DynObject (I've done this > already, but I think some small bugs for document-events are still > happening). > > any ideas, comments,rocks? Just two comments (my rocks supply is starving): The main difference between document-events and the rest of events is that the document doesn't have any "onmouseover"-"onmouseout" events and that other elements have no "onload" or "onunload" events in the browser DOM. Other small differences can be spotted by carefully reading the documentation of each browser. A graphical representation of each browser's DOM (from JavaScript developer point of view) will be a good idea for someone to prepare (myself, when my workload is lower) so each developer can have a God's view over the objects at his/her disposal before developping anything and also a good place to look before complaining about this or that bug. These DOM views could be shown in a web page/PDF doc/whatever-the-format so people can use them as basis for every other thing. I hope this lights new roads ahead in DynAPI development... Raides J. |
From: Robert R. <rra...@ya...> - 2001-01-26 19:13:50
|
Yes, I like the way you collected the common properties of both and combined them. It makes the dynlayer and dyndocument much more friendlier to work with. Also, I think that the Netscape 6 problems need to be the highest priority right now. I know there have been fixes to the events. But one of the major problems is with the getContentW/H since NS 6 is a peice of crap, and doesn't initialize these offsetW/Height until it wants to. -- // Robert Rainwater On 1/26/2001, 2:49:53 AM EST, Pascal wrote about "[Dynapi-Dev] getDocument": > Now that the release is finished, I think we should change the object model > of the dynapi abit. > I want to make the same changes as done in dynacore, making a dynobject off > which the dyndocument and dynlayer are based. This makes things slightly > smaller and also easier to maintain (all parent-child stuff is controlled > in the DynObject and updating that will make the DynLayer and DynDocument > work the same with one single change) > Also dyndocuments should be added to the dynapi, this makes a better > object-tree available.. the DynAPI object will then contain child objects > (dyndocuments) and this also means that all layers created can be freeed > from the unLoad event of the DynAPI (simply walk thru all children of the > DynAPI object, and call deleteAllChildren()) > I also think the getdocument() is not needed anymore (seeing as I have > removed it from dynacore, and everything works) > the findLayers() extension should be a method of the DynDocument, not the > DynAPI object.. this looks more logicall: > DynAPI.document.findLayers() > The eventMethod should be possible to combine into one for DynLayer and > DynDocument, so that it can be attached to the DynObject (I've done this > already, but I think some small bugs for document-events are still > happening). > any ideas, comments,rocks? > Pascal Bestebroer (pb...@oi...) > Software ontwikkelaar > Oberon Informatiesystemen b.v. > http://www.oibv.com >> -----Oorspronkelijk bericht----- >> Van: dyn...@li... >> [mailto:dyn...@li...]Namens Robert Rainwater >> Verzonden: vrijdag 26 januari 2001 2:46 >> Aan: DynAPI Development List >> Onderwerp: [Dynapi-Dev] getDocument >> >> >> >> I was wondering if it would be better to move DynAPI.getDocument() to >> DynDocument.getDocument(). It seems more logical that getDocument >> belongs to DynDocument. Of course DynAPI.getDocument could be kept >> for a while too. >> >> -- >> // Robert Rainwater >> ---------------------- >> 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 >> > _______________________________________________ > 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/ |