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: Robert R. <rra...@ya...> - 2001-02-23 19:42:11
|
Microsoft also stated there would be no Java support in IE 6. Apparently, a java plugin will have to be used. Of course, only if someone creates one, which I'm sure Sun will do. -- // Robert Rainwater On 2/23/2001, 5:04:50 PM EST, Doug wrote about "[Dynapi-Dev] DynAPI current things": > Actually, MS just paid Sun 20 million dollars to licence java for their own > use. > I don't think we need to worry about there being no Java support in IE6. > ----- Original Message ----- > From: "Raymond Smith" <dst...@or...> > To: <dyn...@li...> > Sent: Thursday, February 22, 2001 2:16 PM > Subject: Re: [Dynapi-Dev] DynAPI current things >> The only thing that concerns me, is our friends over at Microsoft. While >> they were moving towards DOM compliance (around the time they ported IE5 > to >> the Macintosh) they took a hard left with IE5.5 when they decided that war >> with the Java/Unix camp was inevitable. >> >> I have a lot of concerns with the pending Whistler/IE6 combination, > because >> I am pretty sure it's going be a major paradigm shift for them/us (think >> zero support for client side Java). M$ is moving to align all their >> products OS/Software around the .net strategy while at the same time > pushing >> the "disturbance factor" in other alternative platforms (hmmmm, this > seems >> to run like shit on my PC compared to 100% M$ products) as much as they > can >> without flagging the Justice Department "to much". >> >> Additionally, the long awaited arrival of NS6 came and went without so > much >> as a ripple of real impact. I think that good old Netscape finally found >> out how to align the bullet-filled cylinder of business blunders with > their >> head. NS6 is a dead alternative in the eyes of Joe Consumer. I can't > even >> imagine AOL wrapping there consumer online service around this browser >> instead of IE (that they use now), unless they want to hand MSN >> marketshare. >> >> In no way am I supporting an IE concentric approach. We just need to be >> aware that "shit is gonna hit the developer fan" in 3-7 months when they >> release Whistler. They have spent a billion dollars developing this > release >> with two goals in mind. Stunt the growth of Java and kill Linux as a > viable >> "consumer OS" alternative. By consumer OS I mean our average home PC > user. >> >> A scary fact is that M$ has said they don't plan on releasing IE6 as a >> public beta. It's gonna release inside the Whistler OS update. Get >> Whistler, get IE6. This means one thing. IE6 and Whistler are being >> developed in tandem to create strategic havoc for the Java/Unix camps. >> >> Javascript (the DynAPI foundation) will likely survive as a cross-platform >> language; it's to entrenched and strategically means little to M$'s end >> goals. We can :O) a bit here. >> >> This is why I don't want to spend a lot of time developing a Java Applet >> Client/Side I/O device for DynAPI2 Michael. I'm not even sure it will be >> supported with the new IE6. I think Java is going to be a server-side > tool >> for awhile. >> >> In the end, basic DOM support with the DynAPI is probably the best path. >> But lets be smart (as we can be with limited knowledge) about how we > enhance >> that API with input/output shunts to the dynamic server/side world. >> >> Laters, >> >> Ray >> >> >> >> _______________________________________________ >> 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/ |
From: Raymond S. <dst...@or...> - 2001-02-23 19:41:05
|
This is also user "elective". If they turn cookies off anything you developed on top off them ges hosed, hence the desire to look for more dependable solutions. ----- Original Message ----- From: "Doug Melvin" <do...@cr...> To: <dyn...@li...> Sent: Friday, February 23, 2001 2:10 PM Subject: Re: [Re: [Re: [Dynapi-Dev] Dynamic Content Loading (IT WORKS)]] > ANY cookie, regardless of who wrote it, is client-side (stored by the > browser) > But don't get cookies confused with session variables (ASP) > > ----- Original Message ----- > From: "Doc Oliver" <doc...@us...> > To: <dyn...@li...> > Sent: Friday, February 23, 2001 7:49 AM > Subject: Re: [Re: [Re: [Dynapi-Dev] Dynamic Content Loading (IT WORKS)]] > > > "Richard Bennett" <ma...@ri...> wrote: > > I thought client-side javascript couldn't read cookies written by a > > server-side app?? > > Richard. > > sure it can, a cookie is a cookie is a ... > > > ____________________________________________________________________ > Get free email and a permanent address at http://www.amexmail.com/?A=1 > > _______________________________________________ > 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 > |
From: Raymond S. <dst...@or...> - 2001-02-23 19:35:17
|
M$ paid Sun 20 million dollars as a legal settlement in a lawsuit they lost. Here, read this. It's from Business News. As a result of the settlement, Redmond, Wash.-based Microsoft will pay $20 million to Palo Alto, Calif.-based Sun, .terminate all Java licenses, and agree to a permanent injunction against the use of the Java Compatible logo. "They can continue to distribute an outdated version of our technology, but they can't use Java for .NET," said Patricia Sueltz, Sun's executive vice president, Software Systems Group. .NET is Microsoft's Internet applications strategy. What Microsoft can continue doing, under a limited license, is sell existing inventory of products, only with the 1.1.4 implementation of Java that Microsoft currently has, but the company cannot modify those implementations at all, Sueltz added. The limited license covers only the products already containing the Java technology, and lasts only for seven years. Beyond that, Microsoft has no rights to distribute the Java technology, or to otherwise use any of Sun's intellectual property, Sun said. A couple of key takeaways: Can't use Java for .NET and can only distribute it with "existing inventory of products". Whistler isn't this! Ray ----- Original Message ----- From: "Doug Melvin" <do...@cr...> To: <dyn...@li...> Sent: Friday, February 23, 2001 2:04 PM Subject: Re: [Dynapi-Dev] DynAPI current things > Actually, MS just paid Sun 20 million dollars to licence java for their own > use. > I don't think we need to worry about there being no Java support in IE6. > > ----- Original Message ----- > From: "Raymond Smith" <dst...@or...> > To: <dyn...@li...> > Sent: Thursday, February 22, 2001 2:16 PM > Subject: Re: [Dynapi-Dev] DynAPI current things > > > > The only thing that concerns me, is our friends over at Microsoft. While > > they were moving towards DOM compliance (around the time they ported IE5 > to > > the Macintosh) they took a hard left with IE5.5 when they decided that war > > with the Java/Unix camp was inevitable. > > > > I have a lot of concerns with the pending Whistler/IE6 combination, > because > > I am pretty sure it's going be a major paradigm shift for them/us (think > > zero support for client side Java). M$ is moving to align all their > > products OS/Software around the .net strategy while at the same time > pushing > > the "disturbance factor" in other alternative platforms (hmmmm, this > seems > > to run like shit on my PC compared to 100% M$ products) as much as they > can > > without flagging the Justice Department "to much". > > > > Additionally, the long awaited arrival of NS6 came and went without so > much > > as a ripple of real impact. I think that good old Netscape finally found > > out how to align the bullet-filled cylinder of business blunders with > their > > head. NS6 is a dead alternative in the eyes of Joe Consumer. I can't > even > > imagine AOL wrapping there consumer online service around this browser > > instead of IE (that they use now), unless they want to hand MSN > > marketshare. > > > > In no way am I supporting an IE concentric approach. We just need to be > > aware that "shit is gonna hit the developer fan" in 3-7 months when they > > release Whistler. They have spent a billion dollars developing this > release > > with two goals in mind. Stunt the growth of Java and kill Linux as a > viable > > "consumer OS" alternative. By consumer OS I mean our average home PC > user. > > > > A scary fact is that M$ has said they don't plan on releasing IE6 as a > > public beta. It's gonna release inside the Whistler OS update. Get > > Whistler, get IE6. This means one thing. IE6 and Whistler are being > > developed in tandem to create strategic havoc for the Java/Unix camps. > > > > Javascript (the DynAPI foundation) will likely survive as a cross-platform > > language; it's to entrenched and strategically means little to M$'s end > > goals. We can :O) a bit here. > > > > This is why I don't want to spend a lot of time developing a Java Applet > > Client/Side I/O device for DynAPI2 Michael. I'm not even sure it will be > > supported with the new IE6. I think Java is going to be a server-side > tool > > for awhile. > > > > In the end, basic DOM support with the DynAPI is probably the best path. > > But lets be smart (as we can be with limited knowledge) about how we > enhance > > that API with input/output shunts to the dynamic server/side world. > > > > Laters, > > > > Ray > > > > > > > > _______________________________________________ > > 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 > |
From: Jeff G. <je...@we...> - 2001-02-23 19:34:30
|
Thanks. Pascal Bestebroer wrote: > totally amazing stuff! > > you hit straight into my bookmarks with this site :) > > I'll be taking some things into account when optimising the dynlayer code! > > Pascal Bestebroer > pa...@dy... > http://www.dynamic-core.net > > > -----Oorspronkelijk bericht----- > > Van: dyn...@li... > > [mailto:dyn...@li...]Namens Jeff Greenberg > > Verzonden: vrijdag 23 februari 2001 19:57 > > Aan: dyn...@li... > > Onderwerp: [Dynapi-Dev] My JS Optimization Site > > > > |
From: Pascal B. <pa...@dy...> - 2001-02-23 19:26:47
|
totally amazing stuff! you hit straight into my bookmarks with this site :) I'll be taking some things into account when optimising the dynlayer code! Pascal Bestebroer pa...@dy... http://www.dynamic-core.net > -----Oorspronkelijk bericht----- > Van: dyn...@li... > [mailto:dyn...@li...]Namens Jeff Greenberg > Verzonden: vrijdag 23 februari 2001 19:57 > Aan: dyn...@li... > Onderwerp: [Dynapi-Dev] My JS Optimization Site > > > Hey guys... > > With all the discussion lately about optimizing the DynAPI2, I thought > I'd finally get started on a project I have been meaning to get to > lately and which I hope will benefit everyone developing the api. > > My new site (still under construction) is a collection of JavaScript > optimization tips, techniques, tests and explanations. It will deal with > speed, size and memory issues. > > Right now, I only have the speed section "done", but I am now working on > the others. I put done in quotes because I hope the information will > grow from your suggestions and comments. > > This is the link: > > http://home.earthlink.net/~kendrasg/info/js_opt/ > > There are a few things that aren't 100% yet, like the status messages > for the tests on IE don't work right, but I will fix that soon. > > Anyway, let me know what you think. > > Jeff Greenberg > je...@we... > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > |
From: Matthew A. S. <ms...@sh...> - 2001-02-23 19:18:22
|
When you create a cookie via server side script: VB ASP: Response.Cookies("Name") =3D "Value" This actually adds the headers to the web page that is served to the client to create the cookies on the client. When you make a request for a new web page the cookies that qualify are sent to the server along with your request. This way when you want to access a cookie on the server: VB ASP:=20 x =3D Request.Cookies("Name") The values are available to the server. As Doug mentioned this should not be confused with Session Variables, Application Variables, or even some languages call them Server Side Cookies. -- Matthew -----Original Message----- From: Doug Melvin [mailto:do...@cr...] Sent: Friday, February 23, 2001 2:10 PM To: dyn...@li... Subject: Re: [Re: [Re: [Dynapi-Dev] Dynamic Content Loading (IT WORKS)]] ANY cookie, regardless of who wrote it, is client-side (stored by the browser) But don't get cookies confused with session variables (ASP) ----- Original Message ----- From: "Doc Oliver" <doc...@us...> To: <dyn...@li...> Sent: Friday, February 23, 2001 7:49 AM Subject: Re: [Re: [Re: [Dynapi-Dev] Dynamic Content Loading (IT WORKS)]] "Richard Bennett" <ma...@ri...> wrote: > I thought client-side javascript couldn't read cookies written by a > server-side app?? > Richard. sure it can, a cookie is a cookie is a ... ____________________________________________________________________ Get free email and a permanent address at http://www.amexmail.com/?A=3D1 _______________________________________________ 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 |
From: Doug M. <do...@cr...> - 2001-02-23 19:11:44
|
ANY cookie, regardless of who wrote it, is client-side (stored by the browser) But don't get cookies confused with session variables (ASP) ----- Original Message ----- From: "Doc Oliver" <doc...@us...> To: <dyn...@li...> Sent: Friday, February 23, 2001 7:49 AM Subject: Re: [Re: [Re: [Dynapi-Dev] Dynamic Content Loading (IT WORKS)]] "Richard Bennett" <ma...@ri...> wrote: > I thought client-side javascript couldn't read cookies written by a > server-side app?? > Richard. sure it can, a cookie is a cookie is a ... ____________________________________________________________________ Get free email and a permanent address at http://www.amexmail.com/?A=1 _______________________________________________ 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 |
From: Doug M. <do...@cr...> - 2001-02-23 19:06:13
|
Actually, MS just paid Sun 20 million dollars to licence java for their own use. I don't think we need to worry about there being no Java support in IE6. ----- Original Message ----- From: "Raymond Smith" <dst...@or...> To: <dyn...@li...> Sent: Thursday, February 22, 2001 2:16 PM Subject: Re: [Dynapi-Dev] DynAPI current things > The only thing that concerns me, is our friends over at Microsoft. While > they were moving towards DOM compliance (around the time they ported IE5 to > the Macintosh) they took a hard left with IE5.5 when they decided that war > with the Java/Unix camp was inevitable. > > I have a lot of concerns with the pending Whistler/IE6 combination, because > I am pretty sure it's going be a major paradigm shift for them/us (think > zero support for client side Java). M$ is moving to align all their > products OS/Software around the .net strategy while at the same time pushing > the "disturbance factor" in other alternative platforms (hmmmm, this seems > to run like shit on my PC compared to 100% M$ products) as much as they can > without flagging the Justice Department "to much". > > Additionally, the long awaited arrival of NS6 came and went without so much > as a ripple of real impact. I think that good old Netscape finally found > out how to align the bullet-filled cylinder of business blunders with their > head. NS6 is a dead alternative in the eyes of Joe Consumer. I can't even > imagine AOL wrapping there consumer online service around this browser > instead of IE (that they use now), unless they want to hand MSN > marketshare. > > In no way am I supporting an IE concentric approach. We just need to be > aware that "shit is gonna hit the developer fan" in 3-7 months when they > release Whistler. They have spent a billion dollars developing this release > with two goals in mind. Stunt the growth of Java and kill Linux as a viable > "consumer OS" alternative. By consumer OS I mean our average home PC user. > > A scary fact is that M$ has said they don't plan on releasing IE6 as a > public beta. It's gonna release inside the Whistler OS update. Get > Whistler, get IE6. This means one thing. IE6 and Whistler are being > developed in tandem to create strategic havoc for the Java/Unix camps. > > Javascript (the DynAPI foundation) will likely survive as a cross-platform > language; it's to entrenched and strategically means little to M$'s end > goals. We can :O) a bit here. > > This is why I don't want to spend a lot of time developing a Java Applet > Client/Side I/O device for DynAPI2 Michael. I'm not even sure it will be > supported with the new IE6. I think Java is going to be a server-side tool > for awhile. > > In the end, basic DOM support with the DynAPI is probably the best path. > But lets be smart (as we can be with limited knowledge) about how we enhance > that API with input/output shunts to the dynamic server/side world. > > Laters, > > Ray > > > > _______________________________________________ > 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 |
From: Jeff G. <je...@we...> - 2001-02-23 18:56:29
|
Hey guys... With all the discussion lately about optimizing the DynAPI2, I thought I'd finally get started on a project I have been meaning to get to lately and which I hope will benefit everyone developing the api. My new site (still under construction) is a collection of JavaScript optimization tips, techniques, tests and explanations. It will deal with speed, size and memory issues. Right now, I only have the speed section "done", but I am now working on the others. I put done in quotes because I hope the information will grow from your suggestions and comments. This is the link: http://home.earthlink.net/~kendrasg/info/js_opt/ There are a few things that aren't 100% yet, like the status messages for the tests on IE don't work right, but I will fix that soon. Anyway, let me know what you think. Jeff Greenberg je...@we... |
From: Jason H. <jas...@ho...> - 2001-02-23 17:37:10
|
I just want to ask if anyone has some simple examples of how to use a scroll bar. I have the current version of the DynAPI files so I am assuming I should use scrollbar2. Is that right? I started out using a scrollpane and it works really well. My only problem is that I don't want to use the default scrollers of the scrollpane. Basically what I want to do is use my own scrollers/images/buttons but I want the up/down buttons closer together and centered next to the content I am scrolling. Does that make sense? Maybe there is a way to do that with the scrollpane? Currently I use a label with my scrollpane to hold the content. If I switch to a scrollbar can I still use the label or will I have to create a different object?? Any help appreciated Jason _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com |
From: <no...@so...> - 2001-02-23 17:34:58
|
Bug #133785, was updated on 2001-Feb-23 09:36 Here is a current snapshot of the bug. Project: DynAPI 2 Category: Browser-Specific Issue Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: scottsevertson Assigned to : nobody Summary: NS 4 onclick & DragEvent Details: Under Netscape 4.x: Child layers of a draggable layer do not recieve onclick events. Cause: Cancelling an onmousedown event in NS 4.x prevents the onclick event from firing. DragEvent.js (from the current release) calls e.cancelBrowserEvent() in the DragEvent.lyrListener.onmousedown function (line 26). Fix: Commenting out e.cancelBrowserEvent() in DragEvent.js resolves the symptoms, although I am not sure of the possible repercussions of this. Test case: Click the "X" layer. Console does not show onclick event, but does show onmousedown and onmouseup events. Appply the above Fix and try again. the onclick event fires. <HTML> <HEAD> <TITLE>DynAPI Testing</TITLE> <SCRIPT LANGUAGE="JavaScript" SRC="../src/dynapi.js"></SCRIPT> <SCRIPT LANGUAGE="JavaScript"><!-- DynAPI.setLibraryPath("../src/lib/"); DynAPI.include("dynapi.api.*"); DynAPI.include("dynapi.util.console.js"); var lyrChild, lyrParent; DynAPI.onLoad = function() { var evtChild; DynAPI.console.open(); lyrParent = new DynLayer("Parent", 100, 200, 300, 200, "#CCCCCC"); lyrChild = new DynLayer("Child", 270, 10, 20, 20, "#FFFFFF"); lyrParent.setHTML("<EM>Parent</EM>"); lyrChild.setHTML("<STRONG>X</STRONG>"); DragEvent.setDragBoundary(lyrParent); DragEvent.enableDragEvents(lyrParent); evtChild = new EventListener(lyrChild); evtChild.onclick = function(e) { DynAPI.console.write("Child: onclick"); lyrParent.deleteFromParent(); } evtChild.onmousedown = function(e) { DynAPI.console.write("Child: onmousedown"); } evtChild.onmouseup = function(e) { DynAPI.console.write("Child: onmouseup"); } lyrChild.addEventListener(evtChild); lyrParent.addChild(lyrChild); DynAPI.document.addChild(lyrParent) } //--></SCRIPT> </HEAD> <BODY BGCOLOR="#FFFFFF"> </BODY> </HTML> For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=133785&group_id=5757 |
From: Doc O. <doc...@us...> - 2001-02-23 15:48:26
|
"Richard Bennett" <ma...@ri...> wrote: > I thought client-side javascript couldn't read cookies written by a > server-side app?? > Richard. sure it can, a cookie is a cookie is a ... ____________________________________________________________________ Get free email and a permanent address at http://www.amexmail.com/?A=3D1 |
From: Pascal <pb...@oi...> - 2001-02-23 11:16:56
|
what exactly is the idea behind it? (can't figure it out :) Pascal Bestebroer (pb...@oi...) Software ontwikkelaar Oberon Informatiesystemen b.v. http://www.oibv.com > -----Oorspronkelijk bericht----- > Van: dyn...@li... > [mailto:dyn...@li...]Namens Michael > Pemberton > Verzonden: vrijdag 23 februari 2001 4:35 > Aan: dyn...@li... > Onderwerp: [Dynapi-Dev] Advanced include method > > > The following is a modified version of the DynAPI.include method. > > include : function(src,path) { > src=src.split('.'); > if (src[src.length-1] == 'js') src.length--; > var pckg=src[0], grp=src[1], file=src[2], > path=path||DynAPI.librarypath||''; > if (path.substr(path.length-1) != "/") path += "/"; > if (file=='*') { > if (DynAPI.packages[pckg]) > group=DynAPI.packages[pckg][grp]; > > if (group) { > for (var i in group) > if (group[i]!=true) { > document.write('<script > src="'+path+pckg+'/'+grp+'/'+i+'.js"><\/script>'); > group[i]=true; > } else DynAPI.errorHandler("The package > has already > been loaded."); > } else DynAPI.errorHandler("The following package > could not > be loaded."); > } else if (DynAPI.packages[pckg][grp][file]!=true) { > document.write('<script > src="'+path+src.join('/')+'.js"><\/script>'); > DynAPI.packages[pckg][grp][file]=true; > } else DynAPI.errorHandler("The package has already been > loaded."); > } > > I've replaced the libraries so that they are defined as a series of > boolean values > api : { browser:false, layer:false, document:false, > events:false }, > > Is this worth implementing in the API. I see that it would require > rewriting the way that packages are declared. > -- > Michael Pemberton > mp...@ph... > ICQ: 12107010 > > > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > |
From: Raymond S. <dst...@or...> - 2001-02-23 08:57:25
|
The only thing that concerns me, is our friends over at Microsoft. While they were moving towards DOM compliance (around the time they ported IE5 to the Macintosh) they took a hard left with IE5.5 when they decided that war with the Java/Unix camp was inevitable. I have a lot of concerns with the pending Whistler/IE6 combination, because I am pretty sure it's going be a major paradigm shift for them/us (think zero support for client side Java). M$ is moving to align all their products OS/Software around the .net strategy while at the same time pushing the "disturbance factor" in other alternative platforms (hmmmm, this seems to run like shit on my PC compared to 100% M$ products) as much as they can without flagging the Justice Department "to much". Additionally, the long awaited arrival of NS6 came and went without so much as a ripple of real impact. I think that good old Netscape finally found out how to align the bullet-filled cylinder of business blunders with their head. NS6 is a dead alternative in the eyes of Joe Consumer. I can't even imagine AOL wrapping there consumer online service around this browser instead of IE (that they use now), unless they want to hand MSN marketshare. In no way am I supporting an IE concentric approach. We just need to be aware that "shit is gonna hit the developer fan" in 3-7 months when they release Whistler. They have spent a billion dollars developing this release with two goals in mind. Stunt the growth of Java and kill Linux as a viable "consumer OS" alternative. By consumer OS I mean our average home PC user. A scary fact is that M$ has said they don't plan on releasing IE6 as a public beta. It's gonna release inside the Whistler OS update. Get Whistler, get IE6. This means one thing. IE6 and Whistler are being developed in tandem to create strategic havoc for the Java/Unix camps. Javascript (the DynAPI foundation) will likely survive as a cross-platform language; it's to entrenched and strategically means little to M$'s end goals. We can :O) a bit here. This is why I don't want to spend a lot of time developing a Java Applet Client/Side I/O device for DynAPI2 Michael. I'm not even sure it will be supported with the new IE6. I think Java is going to be a server-side tool for awhile. In the end, basic DOM support with the DynAPI is probably the best path. But lets be smart (as we can be with limited knowledge) about how we enhance that API with input/output shunts to the dynamic server/side world. Laters, Ray |
From: <ma...@ab...> - 2001-02-23 08:14:34
|
an idea is to put the mutiple childen-addChild() into an extension, so people can use it if they want. maybe togother with some other functions we move from the core api to an extension, just to speed things up and hold size down. just a dynapi.ext.common.js or something /m > -----Original Message----- > From: dyn...@li... > [mailto:dyn...@li...]On Behalf Of Pascal > Bestebroer > Sent: den 22 februari 2001 22:10 > To: dyn...@li... > Subject: RE: [Dynapi-Dev] DynAPI current things > > > > i don't think ns 6 is a true DOM browser yet > > and also if that's the case then code like : > > ---- snip ---- > > > and this for now it's supported only on ns 6 may be ie 6 > > Agreed, that's why I mentioned this as the first step for DOM > compatibility.. at this point NS6 is the best test for that (don't konquer > this fact) and once these if statements are in place.. we can > start to work > towards real DOM compatibility (if ever needed) > > > > * addChild() change > > > AddChild currently supports multiple children as parameter at > > once.. no body > > > uses it, no body should. > > > > I actually use it a lot and saves a lot of lines of code when u > > have some layer: > > > > DynAPI.document.addChild(layer1) > > DynAPI.document.addChild(layer2) > > DynAPI.document.addChild(layer3) > > DynAPI.document.addChild(layer4) > > DynAPI.document.addChild(layer5) > > DynAPI.document.addChild(layer6) > > > > DynAPI.document.addChild(layer1,layer2,layer3,layer4,layer5,layer6) > > > > sorry I like the second better > > I've never seen any widget or example use it.. and it really saves alot > (getting length of an array takes time, and in a for loop it takes more > time..) .. any other takes on this? > > > wouldn't be enough to check for arguments.length and do an if > > else that will support both > > that also takes more time then passing the variable your work with as > parameter... en speed is still an issue (ask around ;-) > > > > Pascal Bestebroer > pa...@dy... > http://www.dynamic-core.net > > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev |
From: Raymond S. <dst...@or...> - 2001-02-23 07:57:55
|
The only thing that concerns me, is our friends over at Microsoft. While they were moving towards DOM compliance (around the time they ported IE5 to the Macintosh) they took a hard left with IE5.5 when they decided that war with the Java/Unix camp was inevitable. I have a lot of concerns with the pending Whistler/IE6 combination, because I am pretty sure it's going be a major paradigm shift for them/us (think zero support for client side Java). M$ is moving to align all their products OS/Software around the .net strategy while at the same time pushing the "disturbance factor" in other alternative platforms (hmmmm, this seems to run like shit on my PC compared to 100% M$ products) as much as they can without flagging the Justice Department "to much". Additionally, the long awaited arrival of NS6 came and went without so much as a ripple of real impact. I think that good old Netscape finally found out how to align the bullet-filled cylinder of business blunders with their head. NS6 is a dead alternative in the eyes of Joe Consumer. I can't even imagine AOL wrapping there consumer online service around this browser instead of IE (that they use now), unless they want to hand MSN marketshare. In no way am I supporting an IE concentric approach. We just need to be aware that "shit is gonna hit the developer fan" in 3-7 months when they release Whistler. They have spent a billion dollars developing this release with two goals in mind. Stunt the growth of Java and kill Linux as a viable "consumer OS" alternative. By consumer OS I mean our average home PC user. A scary fact is that M$ has said they don't plan on releasing IE6 as a public beta. It's gonna release inside the Whistler OS update. Get Whistler, get IE6. This means one thing. IE6 and Whistler are being developed in tandem to create strategic havoc for the Java/Unix camps. Javascript (the DynAPI foundation) will likely survive as a cross-platform language; it's to entrenched and strategically means little to M$'s end goals. We can :O) a bit here. This is why I don't want to spend a lot of time developing a Java Applet Client/Side I/O device for DynAPI2 Michael. I'm not even sure it will be supported with the new IE6. I think Java is going to be a server-side tool for awhile. In the end, basic DOM support with the DynAPI is probably the best path. But lets be smart (as we can be with limited knowledge) about how we enhance that API with input/output shunts to the dynamic server/side world. Laters, Ray |
From: Michael P. <mp...@ph...> - 2001-02-23 03:38:05
|
The following is a modified version of the DynAPI.include method. include : function(src,path) { src=src.split('.'); if (src[src.length-1] == 'js') src.length--; var pckg=src[0], grp=src[1], file=src[2], path=path||DynAPI.librarypath||''; if (path.substr(path.length-1) != "/") path += "/"; if (file=='*') { if (DynAPI.packages[pckg]) group=DynAPI.packages[pckg][grp]; if (group) { for (var i in group) if (group[i]!=true) { document.write('<script src="'+path+pckg+'/'+grp+'/'+i+'.js"><\/script>'); group[i]=true; } else DynAPI.errorHandler("The package has already been loaded."); } else DynAPI.errorHandler("The following package could not be loaded."); } else if (DynAPI.packages[pckg][grp][file]!=true) { document.write('<script src="'+path+src.join('/')+'.js"><\/script>'); DynAPI.packages[pckg][grp][file]=true; } else DynAPI.errorHandler("The package has already been loaded."); } I've replaced the libraries so that they are defined as a series of boolean values api : { browser:false, layer:false, document:false, events:false }, Is this worth implementing in the API. I see that it would require rewriting the way that packages are declared. -- Michael Pemberton mp...@ph... ICQ: 12107010 |
From: Doc O. <doc...@us...> - 2001-02-23 02:04:46
|
Michael Pemberton <mp...@ph...> wrote: > the problem was that there was no method of downloading content AFTER t= he page > has been rendered. That's what I'm talking about, look: var tmpImg =3D new Image(); tmpImg.src =3D 'site.php?name=3DdonaldDuck&age=3D60; now 'site.php' can read 'name' and 'age', but can also send back data by setting a cookie, see, an image request can be used to 'push' data to the= browser aswell. you could for example set a 'replyCookie=3DGUID' in the request, and then= have an intervall that look for that cookie, and then fires an event when it i= s received. ____________________________________________________________________ Get free email and a permanent address at http://www.amexmail.com/?A=3D1 |
From: <no...@so...> - 2001-02-23 02:01:50
|
Bug #133699, was updated on 2001-Feb-22 18:03 Here is a current snapshot of the bug. Project: DynAPI 2 Category: None Status: Open Resolution: None Bug Group: None Priority: 5 Submitted by: nobody Assigned to : nobody Summary: NS4 mousedown mouseup events broken Details: I noticed that NS4 doesn't give mouseup/down events if a dynlayer is filled by an image. This example shows the problem, it is powered by todays snapshot: http://www.dynapi.f2s.com/dynapi_2001_02_22/dynapi/NS4_Tests/imgtest_Rollover_Button.html This example shows that it was working normally on the 19/12/2000 snapshot: http://www.resass.f2s.com/dynapi/Richard_Examples/imgtest_Rollover_Button.html Richard Bennett For detailed info, follow this link: http://sourceforge.net/bugs/?func=detailbug&bug_id=133699&group_id=5757 |
From: Richard B. <ma...@ri...> - 2001-02-23 01:44:02
|
I thought client-side javascript couldn't read cookies written by a server-side app?? Richard. ----- Original Message ----- From: "Doc Oliver" <doc...@us...> To: <dyn...@li...> Sent: Thursday, February 22, 2001 9:53 AM Subject: Re: [Re: [Dynapi-Dev] Dynamic Content Loading (IT WORKS)] > > Would like to see the java source (if it's an option, if not no problem), > > and start working on a PHP version of this as well; adding in the two other > > components. > > > Did y'all know that you can do all of this with the help of a server-side > script + some cookies ? (create img, set source to ss-file, ss-file can > read from query - writes to cookie, script reads from cookie). I was > working on something like that before, but decided to go with java. > > One problem though, there semes to be some problems with unicode and the > communication between java/js (try loading a chinese file into a chinese > document). > > my 0.02$ > > > ____________________________________________________________________ > Get free email and a permanent address at http://www.amexmail.com/?A=1 > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev > ____________________________________________________________ > Get your domain name and domain-based e-mail from > Namezero.com. New! Namezero Plus domains now available. > Find out more at: http://www.namezero.com > |
From: Michael P. <mp...@ph...> - 2001-02-23 00:28:39
|
I've seen a request for this on the help list and thought it would be fun. I've extended my gragging to no involve a grid option. Just add the following code to the drag onmousemove event after the dragBoundry if section: if (lyr.grid) { x=Math.floor(x/lyr.grid)*lyr.grid; y=Math.floor(y/lyr.grid)*lyr.grid; }; Then just set layer.drag to the value you size of the grid lines. -- Michael Pemberton mp...@ph... ICQ: 12107010 |
From: Michael P. <mp...@ph...> - 2001-02-23 00:01:31
|
oops. I modified the code to work in dynapi/file instead of afroapi/file. I figured it would be easier that way. Check url.js to see where it is looking for the applet. Richard Bennett wrote: > I'm trying to get this working, but I get this error (IE+NS) what am I doing > wrong? > > ------------------------------------------------------------ > JavaScript Error: file:///C|/My Documents/My Webs/dhtml/daily > snapshots/Copy (2) of dynapi3/dynapi/src/lib/afroapi/file/url.js, > line 6: > unable to reflect applet "urlLoad", index 0 - not loaded yet?. > --------------------------------------------------------- > > This is the source; > ---------------------------------------------------------- > <script language="Javascript" src="../src/dynapi.js"></script> > <script language="Javascript"> > > DynAPI.setLibraryPath('../src/lib/'); > DynAPI.include('dynapi.api.*'); > DynAPI.include('afroapi.file.io'); > DynAPI.include('afroapi.file.url'); > > </script> > <script language="Javascript"> > > DynAPI.onLoad = function() { > > block = new DynLayer(null,200,200,200,200); > DynAPI.document.addChild(block); > block.setURL('../clock.html') > > }; > > </script> > ---------------------------------------------------------- > > Thanks, > Richard. > > ----- Original Message ----- > From: "Michael Pemberton" <mp...@ph...> > To: <dyn...@li...> > Sent: Thursday, February 22, 2001 6:09 AM > Subject: [Dynapi-Dev] Dynamic Content Loading (IT WORKS) > > > I now have it working in both NS and IE (only win tested) and can't see > > any bugs. (I should open my eyes) > > > > Just place all the files in their own directory called "file" in your > > libs directory. > > > > Then all DynLayer's will have a new method called setURL: > > DynLayer.prototype.setURL=function(url,js,noevt) > > > > url is the location of the file. > > this can be relative to the current main page or absolute. > > it MUST only be on the current domain, java does not allow external > > server downloads > > js > > do you wish any found javascript to be executed? > > noevt > > do you wish the load events to be triggered? > > > > -- > > Michael Pemberton > > mp...@ph... > > ICQ: 12107010 > > > > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/lists/listinfo/dynapi-dev -- Michael Pemberton mp...@ph... ICQ: 12107010 |
From: Robert R. <rra...@ya...> - 2001-02-22 21:10:43
|
Also, make sure you are setting the correct library path. It seems the files arent loaded, either because Frontpage's preview sucks or you just have the wrong library path set. -- // Robert Rainwater On 2/22/2001, 1:47:04 PM EST, Randy wrote about "[Dynapi-Dev] Using DynAPI II with Frontpage 98 problem": > Hey, > I have looked around in the archives and have not come across an answer. > Maybe it's not there or I just missed it...anyway...I have just downloaded > DynAPI II (dynapi-2001-01-25), and imported all of the source files into my > existing project which is in MS FrontPage 98. When I try to preview the > following, I get an error stating that DynLayer is undefined (Line: > myLayer=new DynLayer()). If I load the same page from outside FP, it works > fine. It seems pretty evident to me that FP is having a hard time with the > js code. Can anyone provide insight or am I just hosed? > Thanks, > Randy > <html><head><title>New Page 1</title> > <script language="JavaScript1.2" src="../src/dynapi.js"></script> > <script language="JavaScript1.2"> > DynAPI.setLibraryPath('../src/lib/') > DynAPI.include('dynapi.api.browser.js') > DynAPI.include('dynapi.api.dynlayer.js') > DynAPI.include('dynapi.api.dyndocument.js') > DynAPI.onLoad=function() { > myLayer=new DynLayer() > myLayer.setSize(100,100) > myLayer.setBgColor('#c0c0c0') > myLayer.moveTo(100,100) > DynAPI.document.addChild(myLayer) > } > </script> > </head><body></body></html> > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.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/ |
From: Pascal B. <pa...@dy...> - 2001-02-22 21:09:46
|
> i don't think ns 6 is a true DOM browser yet > and also if that's the case then code like : ---- snip ---- > and this for now it's supported only on ns 6 may be ie 6 Agreed, that's why I mentioned this as the first step for DOM compatibility.. at this point NS6 is the best test for that (don't konquer this fact) and once these if statements are in place.. we can start to work towards real DOM compatibility (if ever needed) > > * addChild() change > > AddChild currently supports multiple children as parameter at > once.. no body > > uses it, no body should. > > I actually use it a lot and saves a lot of lines of code when u > have some layer: > > DynAPI.document.addChild(layer1) > DynAPI.document.addChild(layer2) > DynAPI.document.addChild(layer3) > DynAPI.document.addChild(layer4) > DynAPI.document.addChild(layer5) > DynAPI.document.addChild(layer6) > > DynAPI.document.addChild(layer1,layer2,layer3,layer4,layer5,layer6) > > sorry I like the second better I've never seen any widget or example use it.. and it really saves alot (getting length of an array takes time, and in a for loop it takes more time..) .. any other takes on this? > wouldn't be enough to check for arguments.length and do an if > else that will support both that also takes more time then passing the variable your work with as parameter... en speed is still an issue (ask around ;-) Pascal Bestebroer pa...@dy... http://www.dynamic-core.net |
From: <ni...@pr...> - 2001-02-22 19:54:31
|
> * Do some speed optimisations > Mainly changes to the createElement that sounds great1 > * 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). i don't think ns 6 is a true DOM browser yet and also if that's the case then code like : doc.captureEvents(Event.MOUSEMOVE | Event.MOUSEDOWN | Event.MOUSEUP | Event.CLICK | Event.DBLCLICK); doc.onmousemove=doc.onmousedown=doc.onmouseup=doc.onclick=doc.ondblclick=DynObject.prototype.MouseEventMethod;}; should be defalut to this : doc.addEventListener('mousemove',DynObject.prototype.MouseEventMethod,false); doc.addEventListener('mousedown',DynObject.prototype.MouseEventMethod,false); doc.addEventListener('mouseup',DynObject.prototype.MouseEventMethod,false); doc.addEventListener('click',DynObject.prototype.MouseEventMethod,false); doc.addEventListener('dblclick',DynObject.prototype.MouseEventMethod,false); and this for now it's supported only on ns 6 may be ie 6 > * 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. both of this make sense > * addChild() change > AddChild currently supports multiple children as parameter at once.. no body > uses it, no body should. I actually use it a lot and saves a lot of lines of code when u have some layer: DynAPI.document.addChild(layer1) DynAPI.document.addChild(layer2) DynAPI.document.addChild(layer3) DynAPI.document.addChild(layer4) DynAPI.document.addChild(layer5) DynAPI.document.addChild(layer6) DynAPI.document.addChild(layer1,layer2,layer3,layer4,layer5,layer6) sorry I like the second better 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. wouldn't be enough to check for arguments.length and do an if else that will support both > * 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. this will give better controll with frames ! > 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 :) I hope I didn't make any one mad now just my opinion rocks welcome ciao Y |