Menu
▾
▴
dynapi-dev — List related to the current DynAPI Core development
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(75) |
Nov
(252) |
Dec
(418) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(659) |
Feb
(1039) |
Mar
(870) |
Apr
(235) |
May
(329) |
Jun
(251) |
Jul
(123) |
Aug
(119) |
Sep
(67) |
Oct
(194) |
Nov
(535) |
Dec
(133) |
| 2002 |
Jan
(122) |
Feb
(24) |
Mar
(29) |
Apr
(28) |
May
(16) |
Jun
(20) |
Jul
(11) |
Aug
(12) |
Sep
(13) |
Oct
(14) |
Nov
(23) |
Dec
(19) |
| 2003 |
Jan
(28) |
Feb
(170) |
Mar
(288) |
Apr
(211) |
May
(126) |
Jun
(166) |
Jul
(131) |
Aug
(102) |
Sep
(211) |
Oct
(301) |
Nov
(22) |
Dec
(6) |
| 2004 |
Jan
(14) |
Feb
(16) |
Mar
(7) |
Apr
|
May
(8) |
Jun
(25) |
Jul
(21) |
Aug
(2) |
Sep
(7) |
Oct
|
Nov
(2) |
Dec
(1) |
| 2005 |
Jan
(4) |
Feb
(2) |
Mar
(14) |
Apr
(24) |
May
(3) |
Jun
(7) |
Jul
(30) |
Aug
(5) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
(1) |
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
|
From: Dann <da...@to...> - 2001-01-29 14:15:14
|
This is also a must read, me thinks : http://www.urc.bl.ac.yu/manuals/jsobj/index.html |
|
From: Dann <da...@to...> - 2001-01-29 14:06:06
|
Hi 8tan, First let's get some common ground through this article, note the use of '-based' and '-oriented' : http://www.mactech.com/articles/frameworks/7_6/Prototype-based_OOLs_Evins.html and then come to terms with the fact that the terms prototype-based and object-based (<>object-oriented !!!) are very close : http://www.cpsc.ucalgary.ca/~gao/60903/60903021.htm Were we talking about the same thing all along ? The irony :)) LOL ! CU, Dann |
|
From: Dann <da...@to...> - 2001-01-29 13:53:04
|
Hi 8tan, You are looking for the stones from the computer science theory people too, aren't you ? LOL ! No really, where the hell do you get this stuff from ? It sounds like revisionist CS theory to me :)) CU, Dann Eytan Heidingsfeld wrote: > Lets really get the terms straight. > > Class-Oriented: You develop classes. You do this be using the prototype of > an object. Then this object becomes basically a prototype, a class and then > for inheritance an object says use this objects prototype and add these > members. > Object-Oriented: You develop classes by defining an interface and then > implementing this interface. To use this object you create a new object > based on this class. Inheritance is dealt with by saying I want to inherit > this and this class. Then your new object has the same members as those > classes with pointers to their implementation. > > There is no PO only CO and OO the difference is inheritance and memory > management but since there is no memory management in JS there is no > difference but inheritance. > 8an > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev |
|
From: Eytan H. <ey...@tr...> - 2001-01-29 13:14:49
|
Lets really get the terms straight. Class-Oriented: You develop classes. You do this be using the prototype of an object. Then this object becomes basically a prototype, a class and then for inheritance an object says use this objects prototype and add these members. Object-Oriented: You develop classes by defining an interface and then implementing this interface. To use this object you create a new object based on this class. Inheritance is dealt with by saying I want to inherit this and this class. Then your new object has the same members as those classes with pointers to their implementation. There is no PO only CO and OO the difference is inheritance and memory management but since there is no memory management in JS there is no difference but inheritance. 8an |
|
From: Dann <da...@to...> - 2001-01-29 13:02:36
|
Hold on there, ... take care with the terms you use ! That's not how I understood it : the OO philosophy embraces both class-based (CO) and prototype-based (PO) objects. It's not OO versus CO, it's CO versus PO ! And if I read the specs correctly, JS is supposed to be a prototype-based language, not a class-based language. CU, Dann Eytan Heidingsfeld wrote: > OO in JS or ECMA script is documented. If you read carefully you will notice > that JS was designed as a Class Oriented language that is basically the same > as OO (Objects and Classes are basically the same). The only difference > between OO and CO is the way it does inheritance hence my new inherit > function. > > About the NS6 I think that can be worked on at the same time while the NG is > being worked on. One of the reasons of designing the NG like this is so that > we can update the Core of DynAPI without having to change everything just > one file (dynlayer.js). > 8an > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev |
|
From: Eytan H. <ey...@tr...> - 2001-01-29 12:51:26
|
OO in JS or ECMA script is documented. If you read carefully you will notice that JS was designed as a Class Oriented language that is basically the same as OO (Objects and Classes are basically the same). The only difference between OO and CO is the way it does inheritance hence my new inherit function. About the NS6 I think that can be worked on at the same time while the NG is being worked on. One of the reasons of designing the NG like this is so that we can update the Core of DynAPI without having to change everything just one file (dynlayer.js). 8an |
|
From: Michael P. <mp...@ph...> - 2001-01-29 11:00:17
|
I am under the impression that the JavaVM used by Mac IE 5 did not allow for the URLConnection class used to download the data. Cameron Hart wrote: > I think that this is only a problem using IE on the Mac, Mac Netscape has > LiveConnect. > > > -----Original Message----- > > From: dyn...@li... > > [mailto:dyn...@li...]On Behalf Of Jay Chalfant > > Sent: 26 January 2001 18:20 > > To: 'dyn...@li...' > > Subject: RE: [Dynapi-Dev] LoadPanel alternative. > > > > > > Aaaugh! Why? Is this documented by MS or NS? > > > > thanks, > > > > -J > > > > > -----Original Message----- > > > From: Matthew Alan Shirey [mailto:ms...@go...] > > > Sent: Friday, January 26, 2001 9:34 AM > > > To: dyn...@li... > > > Subject: RE: [Dynapi-Dev] LoadPanel alternative. > > > > > > > > > There's also the minor problem that JavaScript cannot talk to > > > an Applet on > > > the Mac... > > > > > > M. > > > > > > -----Original Message----- > > > From: dyn...@li... > > > [mailto:dyn...@li...]On Behalf Of francesco > > > AGATI > > > Sent: Friday, January 26, 2001 12:46 AM > > > To: dyn...@li... > > > Subject: Re: [Dynapi-Dev] LoadPanel alternative. > > > > > > > > > Hi, > > > > > > i have make something of similar with an applet like the > > > Remote Scripting of > > > Microsoft > > > and i have tested that this don't work with IE5 on > > > Machintosh, is like if > > > the virtual machine > > > don't see the class urlconnection > > > > > > > > > ----- Original Message ----- > > > From: "Michael Pemberton" <mp...@ph...> > > > To: <dyn...@li...> > > > Sent: Friday, January 26, 2001 5:11 AM > > > Subject: [Dynapi-Dev] LoadPanel alternative. > > > > > > > > > > I've created a method of using Java to download the URL contents. > > > > > > > > It appears to work in bot NS4.7+ and IE5+. I haven't got > > > access to an > > > > IE4 installation to test it. > > > > > > > > Is there a developer out there who would be able to test it > > > in IE4 for > > > > me? > > > > Is there a developer out there who knows how I could parse > > > the contents > > > > to extract the different sections of the page (<title> / <body> / > > > > <script> sections). The code used in the IO.js parseHTML > > > method works > > > > only if the openning and closing tags are on the same line. > > > This is ok > > > > for the <title> but is not great for the <body> and <script> tags. > > > > > > > > Thanks. > > > > -- > > > > Michael Pemberton > > > > mp...@ph... > > > > ICQ: 12107010 > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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-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 -- Michael Pemberton mp...@ph... ICQ: 12107010 |
|
From: Cameron H. <ca...@bi...> - 2001-01-29 10:35:30
|
I think that this is only a problem using IE on the Mac, Mac Netscape has LiveConnect. > -----Original Message----- > From: dyn...@li... > [mailto:dyn...@li...]On Behalf Of Jay Chalfant > Sent: 26 January 2001 18:20 > To: 'dyn...@li...' > Subject: RE: [Dynapi-Dev] LoadPanel alternative. > > > Aaaugh! Why? Is this documented by MS or NS? > > thanks, > > -J > > > -----Original Message----- > > From: Matthew Alan Shirey [mailto:ms...@go...] > > Sent: Friday, January 26, 2001 9:34 AM > > To: dyn...@li... > > Subject: RE: [Dynapi-Dev] LoadPanel alternative. > > > > > > There's also the minor problem that JavaScript cannot talk to > > an Applet on > > the Mac... > > > > M. > > > > -----Original Message----- > > From: dyn...@li... > > [mailto:dyn...@li...]On Behalf Of francesco > > AGATI > > Sent: Friday, January 26, 2001 12:46 AM > > To: dyn...@li... > > Subject: Re: [Dynapi-Dev] LoadPanel alternative. > > > > > > Hi, > > > > i have make something of similar with an applet like the > > Remote Scripting of > > Microsoft > > and i have tested that this don't work with IE5 on > > Machintosh, is like if > > the virtual machine > > don't see the class urlconnection > > > > > > ----- Original Message ----- > > From: "Michael Pemberton" <mp...@ph...> > > To: <dyn...@li...> > > Sent: Friday, January 26, 2001 5:11 AM > > Subject: [Dynapi-Dev] LoadPanel alternative. > > > > > > > I've created a method of using Java to download the URL contents. > > > > > > It appears to work in bot NS4.7+ and IE5+. I haven't got > > access to an > > > IE4 installation to test it. > > > > > > Is there a developer out there who would be able to test it > > in IE4 for > > > me? > > > Is there a developer out there who knows how I could parse > > the contents > > > to extract the different sections of the page (<title> / <body> / > > > <script> sections). The code used in the IO.js parseHTML > > method works > > > only if the openning and closing tags are on the same line. > > This is ok > > > for the <title> but is not great for the <body> and <script> tags. > > > > > > Thanks. > > > -- > > > Michael Pemberton > > > mp...@ph... > > > ICQ: 12107010 > > > > > > > > > > > > _______________________________________________ > > 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-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev |
|
From: <no...@so...> - 2001-01-29 06:10:34
|
Bug #130356, was updated on 2001-Jan-28 14:25 Here is a current snapshot of the bug. Project: DynAPI 2 Category: Core API Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: marstr Assigned to : rainwater Summary: bug in library-order Details: When the libraries are added in dynapi.js the order needs some changes, because if you dynapi.gui.* are included, the ViewPort needs to be included before the pushpanel and scrollpane, while these classes use the ViewPort. Some thing with dynapi.util.*. Thread should be added before pathanim, circleanim, imganim and hoveranim. i dont know if anyone ever will us gui.* or util.* but the order should be correct anyway. console.js should be added to the util-library. Follow-Ups: Date: 2001-Jan-28 22:10 By: rainwater Comment: I fixed the library order of dynapi.gui and added console.js to the addLibrary call. The other issue is a separate and more complex issue. One solution would be to move thread into the gui library. Based on this, it would require that subclassing can only be done by widgets in the same library (aka dynapi.gui). This would have to always be the class, except for subclassing dynlayer. The way it is now, you have to include dynlayer.js before any of the widgets. Perhaps this needs to be documented. ------------------------------------------------------- Date: 2001-Jan-28 17:51 By: rainwater Comment: I will post a patch to the patches section soon. ------------------------------------------------------- Date: 2001-Jan-28 14:30 By: marstr Comment: wasn't meant to be a "Feature Request", don't know how this happend, uhm.. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130356&group_id=5757 |
|
From: <no...@so...> - 2001-01-29 01:51:39
|
Bug #130356, was updated on 2001-Jan-28 14:25 Here is a current snapshot of the bug. Project: DynAPI 2 Category: Core API Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: marstr Assigned to : rainwater Summary: bug in library-order Details: When the libraries are added in dynapi.js the order needs some changes, because if you dynapi.gui.* are included, the ViewPort needs to be included before the pushpanel and scrollpane, while these classes use the ViewPort. Some thing with dynapi.util.*. Thread should be added before pathanim, circleanim, imganim and hoveranim. i dont know if anyone ever will us gui.* or util.* but the order should be correct anyway. console.js should be added to the util-library. Follow-Ups: Date: 2001-Jan-28 17:51 By: rainwater Comment: I will post a patch to the patches section soon. ------------------------------------------------------- Date: 2001-Jan-28 14:30 By: marstr Comment: wasn't meant to be a "Feature Request", don't know how this happend, uhm.. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130356&group_id=5757 |
|
From: <no...@so...> - 2001-01-29 01:50:51
|
Bug #130357, was updated on 2001-Jan-28 14:27
Here is a current snapshot of the bug.
Project: DynAPI 2
Category: Core - Widgets
Status: Closed
Resolution: Fixed
Bug Group: None
Priority: 5
Submitted by: marstr
Assigned to : rainwater
Summary: small typo in list.js
Details: there's a small typo (i think) in list.js line 76
if (this.selected=b) {
should be
if (this.selected==b) {
right?
Follow-Ups:
Date: 2001-Jan-28 17:50
By: rainwater
Comment:
Doh! Its been updated in CVS. Closing this bug.
-------------------------------------------------------
For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=130357&group_id=5757
|
|
From: Michael P. <mp...@ph...> - 2001-01-29 01:40:08
|
I've used a java applet (won't work with the mac JavaVM) and it works
great. I parse the actual content and extract the title and body tags.
I'm working on extracting the script tags also. It also works without
the need for a loadpanel and can simply be used with the setHTML method
of a dynlayer. The only bug is with permissions and rights to access
the specified url from java.
martin str=F6m wrote:
> maybe I'm wrong, but wasn't there a problem that
> only the content within the <body> and </body>
> was loaded using the LoadPanel?
>
> one way to fix this is by replacing the way LoadPanel
> gets the content. now it uses document.body.innerHTML
> (ie4) and a behavior-download method (ie5).
>
> if we replace this with:
>
> document.all.tags('html')[0].innerHTML //ie4
> document.getElementsByTagName('html').item(0).innerHTML //ie5, ns6
>
> Loadpanel should get everything between <html> and </html>
>
> haven't really test it, just thought this could be a solution.
>
> /martin
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
--
Michael Pemberton
mp...@ph...
ICQ: 12107010
|
|
From: Doug M. <do...@cr...> - 2001-01-29 00:46:16
|
I was just wondering..
What would be wronge with using conditional compilation to reduce the =
foot print of the object in DynAPI?
By this I mean not actually initializing a member function until needed.
I.E.
DynLayer.setBgColor.
when you make the very first call the this function in a specific =
instance the object woul;d say 'have I initialized this function?' if =
not then it will..
eval("myOBJ.prototype.setBgColor=3D"..."); or some such..
The reason I am bringin this up, is that there is no good reason for a =
document consisting of a single toolbar, 5 lables and two dynlayers =
should have a memory footprint of almost a meg..
Doug Melvin
|
|
From: Dann <da...@to...> - 2001-01-28 23:20:29
|
Hi, I have my doubts about the power of ECMAscript as well, but the practice of doing OO in prototype-based languages (like ECMAscript) is documented, albeit not in the particular case of ECMAscript itself. I'll take a closer look on the subject to see what I can dig up... CU, Dann |
|
From: Robert R. <rra...@ya...> - 2001-01-28 22:43:55
|
Yeah, the order was fixed for the api.*, but never for the others. I can fix this easily. -- // Robert Rainwater On 1/28/2001, 5:30:18 PM EST, noreply wrote about "[Dynapi-Dev] [Bug #130356] bug in library-order": > Bug #130356, was updated on 2001-Jan-28 14:25 > Here is a current snapshot of the bug. > Project: DynAPI 2 > Category: Core API > Status: Open > Resolution: None > Bug Group: Feature Request > Priority: 5 > Submitted by: marstr > Assigned to : nobody > Summary: bug in library-order > Details: When the libraries are added in dynapi.js the order > needs some changes, because if you dynapi.gui.* are > included, the ViewPort needs to be included before > the pushpanel and scrollpane, while these classes use > the ViewPort. > Some thing with dynapi.util.*. Thread should be added > before pathanim, circleanim, imganim and hoveranim. > i dont know if anyone ever will us gui.* or util.* > but the order should be correct anyway. > console.js should be added to the util-library. > Follow-Ups: > Date: 2001-Jan-28 14:30 > By: marstr > Comment: > wasn't meant to be a "Feature Request", don't know how this happend, uhm.. > ------------------------------------------------------- > For detailed info, follow this link: > http://sourceforge.net/bugs/?func=detailbug&bug_id=130356&group_id=5757 > _______________________________________________ > 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/ |
|
From: <no...@so...> - 2001-01-28 22:30:32
|
Bug #130356, was updated on 2001-Jan-28 14:25 Here is a current snapshot of the bug. Project: DynAPI 2 Category: Core API Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Submitted by: marstr Assigned to : nobody Summary: bug in library-order Details: When the libraries are added in dynapi.js the order needs some changes, because if you dynapi.gui.* are included, the ViewPort needs to be included before the pushpanel and scrollpane, while these classes use the ViewPort. Some thing with dynapi.util.*. Thread should be added before pathanim, circleanim, imganim and hoveranim. i dont know if anyone ever will us gui.* or util.* but the order should be correct anyway. console.js should be added to the util-library. Follow-Ups: Date: 2001-Jan-28 14:30 By: marstr Comment: wasn't meant to be a "Feature Request", don't know how this happend, uhm.. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130356&group_id=5757 |
|
From: <no...@so...> - 2001-01-28 22:28:14
|
Bug #130357, was updated on 2001-Jan-28 14:27
Here is a current snapshot of the bug.
Project: DynAPI 2
Category: Core - Widgets
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: marstr
Assigned to : nobody
Summary: small typo in list.js
Details: there's a small typo (i think) in list.js line 76
if (this.selected=b) {
should be
if (this.selected==b) {
right?
For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=130357&group_id=5757
|
|
From: <no...@so...> - 2001-01-28 22:25:37
|
Bug #130356, was updated on 2001-Jan-28 14:25 Here is a current snapshot of the bug. Project: DynAPI 2 Category: Core API Status: Open Resolution: None Bug Group: Feature Request Priority: 5 Submitted by: marstr Assigned to : nobody Summary: bug in library-order Details: When the libraries are added in dynapi.js the order needs some changes, because if you dynapi.gui.* are included, the ViewPort needs to be included before the pushpanel and scrollpane, while these classes use the ViewPort. Some thing with dynapi.util.*. Thread should be added before pathanim, circleanim, imganim and hoveranim. i dont know if anyone ever will us gui.* or util.* but the order should be correct anyway. console.js should be added to the util-library. For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=130356&group_id=5757 |
|
From: martin <ma...@ab...> - 2001-01-28 22:12:28
|
maybe I'm wrong, but wasn't there a problem that
only the content within the <body> and </body>
was loaded using the LoadPanel?
one way to fix this is by replacing the way LoadPanel
gets the content. now it uses document.body.innerHTML
(ie4) and a behavior-download method (ie5).
if we replace this with:
document.all.tags('html')[0].innerHTML //ie4
document.getElementsByTagName('html').item(0).innerHTML //ie5, ns6
Loadpanel should get everything between <html> and </html>
haven't really test it, just thought this could be a solution.
/martin
|
|
From: Robert R. <rra...@ya...> - 2001-01-28 21:45:04
|
I would love to see a more modular approach to the DynAPI as well. For instance I like Pascal's DynObject for which DynLayer and DynDocument belong since they share common functionality. The same could also be done for events (mouse and keyevents, etc all have some common functionality). I think the much of the dynlayer/dyndocument stuff could be moved out of the DynAPI.js so that the DynAPI can be used to support more than just dynlayers. I don't really like the idea of OO in JS. The problem is Javascript does not support OO. The DynAPI as it is now uses an Object-oriented approach. There is no standard for trying to make javascript use OO and their are lots of problems trying to do this in JS. As it stands now, the widgets use proper subclassing, atleast as close as possible in Javascript. I don't see why the next gener. couldn't use the same approach. Its not really and OO issue, but a DynAPI design issue. Maybe people can make some proposals to the list as to how to design the next version. However, the current version still needs to be improved with Mozilla/NS 6 support (as well as other fixes) before any thoughts of starting the next version begins. -- // Robert Rainwater On 1/28/2001, 8:23:31 AM EST, Eytan wrote about "[Dynapi-Dev] Next Generation": > Hi, > Since recent discussion has led to the reorganization of the code, and > basically rewriting it I wanted to know what you guys think about a serious > redo and not only a face lift. Then (yes I know I'm bugging you about this > again but hey maybe someone will get convinced) we can at least implement > some of the real OO code. Is there any way I can convince some of you. There > are many reasons I want to do this but mainly stability. And also changing > the amount of DynLayers used for everything and the weight of dynlayers. I > have an example (will try to get it on a public server so you can see the > bug too) that when you add more and more dynlayers suddenly some of them > start to disappear and then appear out of the blue. > all rocks will be accepted, > 8an > _______________________________________________ > 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/ |
|
From: Matthew A. S. <ms...@go...> - 2001-01-28 21:14:05
|
Very well said. The foundation of this project the DynLayer is not stable yet we just keep piling more and more onto it... M. -----Original Message----- From: dyn...@li... [mailto:dyn...@li...]On Behalf Of Dann Sent: Sunday, January 28, 2001 5:54 AM To: dyn...@li... Subject: Re: [Dynapi-Dev] Next Generation Hi Eytan, As you know, I am interested. I would also like to see this project maturing with respect to the insight into some of the other problems that keep this effort from becoming a true reference in the field, it has tremendous value but it falls short of expectations : 1. It fails to be cross-platform/cross-browser because there are no levels of functionality identified. Instead it's a single-shot full whistles and bells API, of which 'this' doesn't work on Mozilla, that doesn't work on IE5 for Mac... etc... 2. It fails to be stable because some in the dev community find their little sinewave animation bull* more important than stabilizing DynLayer itself. It's like some prefer a funny racoon tail hanging from their rearview mirror, instead of a decent running engine. At least I detracted some of the stones coming your way - they're now heading my way :)) CU, Dann Eytan Heidingsfeld wrote: > Hi, > Since recent discussion has led to the reorganization of the code, and > basically rewriting it I wanted to know what you guys think about a serious > redo and not only a face lift. Then (yes I know I'm bugging you about this > again but hey maybe someone will get convinced) we can at least implement > some of the real OO code. Is there any way I can convince some of you. There > are many reasons I want to do this but mainly stability. And also changing > the amount of DynLayers used for everything and the weight of dynlayers. I > have an example (will try to get it on a public server so you can see the > bug too) that when you add more and more dynlayers suddenly some of them > start to disappear and then appear out of the blue. > > all rocks will be accepted, > 8an > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev |
|
From: <no...@so...> - 2001-01-28 18:34:47
|
Bug #129784, was updated on 2001-Jan-23 01:12 Here is a current snapshot of the bug. Project: DynAPI 2 Category: Browser-Specific Issue Status: Open Resolution: Later Bug Group: None Priority: 5 Submitted by: mweinelt Assigned to : nobody Summary: dynapi.js not loading in NS 4.04 X11, NS 4.05 NT Details: dynapi.js won't load on these browsers:. Javascript -error : >function does not always return a value. between line 80 and 100 depending on the snapshot I use. Martin Follow-Ups: Date: 2001-Jan-28 10:34 By: dakhran Comment: I can confirm that this bug also occurs on NS 4.04 [en]-97313, Standard Edition on Win9x. Apparently, the JavaScript engine in these browsers must either always return a value, or never return a value. Changing the functions affected to return a value of null if not returning a value does address this error, but causes other errors to occur. ------------------------------------------------------- Date: 2001-Jan-25 17:39 By: rainwater Comment: I don't think there is anyway to fix this. The DynAPI will probaly never work on those browsers. ------------------------------------------------------- For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=129784&group_id=5757 |
|
From: Eytan H. <ey...@tr...> - 2001-01-28 14:01:22
|
I owe you for the stones bit. ;-) |
|
From: Dann <da...@to...> - 2001-01-28 13:55:23
|
Hi Eytan, As you know, I am interested. I would also like to see this project maturing with respect to the insight into some of the other problems that keep this effort from becoming a true reference in the field, it has tremendous value but it falls short of expectations : 1. It fails to be cross-platform/cross-browser because there are no levels of functionality identified. Instead it's a single-shot full whistles and bells API, of which 'this' doesn't work on Mozilla, that doesn't work on IE5 for Mac... etc... 2. It fails to be stable because some in the dev community find their little sinewave animation bull* more important than stabilizing DynLayer itself. It's like some prefer a funny racoon tail hanging from their rearview mirror, instead of a decent running engine. At least I detracted some of the stones coming your way - they're now heading my way :)) CU, Dann Eytan Heidingsfeld wrote: > Hi, > Since recent discussion has led to the reorganization of the code, and > basically rewriting it I wanted to know what you guys think about a serious > redo and not only a face lift. Then (yes I know I'm bugging you about this > again but hey maybe someone will get convinced) we can at least implement > some of the real OO code. Is there any way I can convince some of you. There > are many reasons I want to do this but mainly stability. And also changing > the amount of DynLayers used for everything and the weight of dynlayers. I > have an example (will try to get it on a public server so you can see the > bug too) that when you add more and more dynlayers suddenly some of them > start to disappear and then appear out of the blue. > > all rocks will be accepted, > 8an > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev |
|
From: Eytan H. <ey...@tr...> - 2001-01-28 13:24:17
|
Hi, Since recent discussion has led to the reorganization of the code, and basically rewriting it I wanted to know what you guys think about a serious redo and not only a face lift. Then (yes I know I'm bugging you about this again but hey maybe someone will get convinced) we can at least implement some of the real OO code. Is there any way I can convince some of you. There are many reasons I want to do this but mainly stability. And also changing the amount of DynLayers used for everything and the weight of dynlayers. I have an example (will try to get it on a public server so you can see the bug too) that when you add more and more dynlayers suddenly some of them start to disappear and then appear out of the blue. all rocks will be accepted, 8an |
175 messages has been excluded from this view by a project administrator.
