Menu
▾
▴
SV: [Dynapi-Dev] DynAPI build, Splitting files
|
From: Bart B. <ba...@ho...> - 2000-12-06 22:50:56
|
True.. I don't see how people can miss the obvious advantages of having browser specific code. Yes, it might be a hassle if you only have to do a couple of browser flagging here and there... but DynAPI is pretty complex... and growing. Don't want to be a parrot .. but here goes anyway: 1. Speed - you can implement more browser specific solutions that will increase speed:execution of code and rendering (such as perhaps VB code... actually some things you CANNOT do without VB.. printing frames from another frame in IE4, for instance) 2. Clarity - doing the above mentioned in the current library would make it even more obscure than it already is. 3. Size - the code the end user will have to dowload will be very optimized and will not contain reduntant code. 4. Modularity - right now everything depends on browser.js. And a lot more of the code is inter-dependant quite extensivly. This could more easily be improved upon through separating general and browser-specific functionality. 5. Just for the hell of it - Which I believe to be the most important reason... ;-) / Bart -----Ursprungligt meddelande----- Från: Brandon Myers <bnd...@ho...> Till: dyn...@li... <dyn...@li...> Datum: den 6 december 2000 23:11 Ämne: Re: [Dynapi-Dev] DynAPI build, Splitting files >(Oh.. and Dan.. not only do DynLayer/DynDocument and LoadPanel have specific >code, DragEvent and several other extentions have much browser specific >code.) >Drag event code could really be improved by splitting it. IE could use VB >enhancements (I know.. it's not JS..) to give it better performance. > >----- Original Message ----- >From: "Dan Steinman" <dy...@fu...> >To: <dyn...@li...> >Sent: Wednesday, December 06, 2000 3:44 PM >Subject: Re: [Dynapi-Dev] DynAPI build, Splitting files > > >> The only files in the DynAPI that are browser related are DynLayer, >DynDocument, and Loadpanel. So if everyone feels we should have nn4,ie, and >dom.js separations we can certainly do this. For the rest of the files it's >completely unnecessary. For the time being I'd not worry about it too much. >Everythings working fine, I'd prefer on concentrating on building more >widgets. After we have a larger codebase we can better decide what changes >are really necessary (at this point I don't think such a change is crutial >for continued developement). >> >> Dan >> >> On Wed, Dec 06, 2000 at 07:58:53AM -0600, Dougal Campbell wrote: >> > On 5 Dec 2000, Bill Wheaton wrote: >> > >> > > What I meant (can't say about Cameron), was that it would be nice to >have all >> > > of the functionality of the API without even worrying if it is cross >browser >> > > compatible. >> > > Quite often, I have to write intranet apps where my customer can and >> > > absolutely does control which ua their users use. (via SMS or >whatever). It >> > > doesn't matter as much over a lan, but for their remote sales people >dialing >> > > up from his customer's pots line to check product allocation during >the lunch >> > > break, it can be slow. If I could _only_ include IE code when I knew >it was >> > > the standard, then I could speed things up some.... maybe even a lot. >> > > maybe I'm dreaming >> > > -bw >> > >> > Those of you interested in browser-targeted code might want to take a >> > look at <URL:http://www.dx0.org/>. This is a cross-browser library with >> > a difference: it uses server-side technology to detect which browser is >> > making the connection, then it delivers JavaScript targeted to that >> > particular browser. >> > >> > In other words, if you view the site with Netscape 4.x, you only receive >> > JavaScript for NS4 (there's no "if is.ie" conditionals). If you browse >> > in with IE5, you get Javascript specifically for IE5 (no "if >> > is.ns4"). Or Mozilla, or NS6, or whatever (they might be supporting >> > Opera, if the new release has decent DOM). >> > >> > The project is still in heavy development, but there are already a few >> > skinnable widgets built and working (a menu, a floating toolbar, and a >> > viewBox (a scrollbar/window). >> > >> > You build your DHTML code in PHP, Perl, or Python. The server then >> > delivers appropriate JS to the browser. >> > >> > Also check out <URL:http://deathstar.eng.utah.edu/~kroford/930/dx0/> >> > >> > Keep in mind that the library and the site are still under development, >> > and there are sections of the web site that aren't complete yet. But >> > from what I've seen on the mailing list, it looks like a few people are >> > using it in production already. >> > >> > -- >> > Ernest MacDougal Campbell III, MCP <do...@gu...> >> > http://www.gunters.org/~dougal/ >> > Lumber Cartel Unit #1654 (tinlc): http://come.to/the.lumber.cartel/ >> > "The medium is not the message. The *message* is the message." >> > >> > _______________________________________________ >> > Dynapi-Dev mailing list >> > Dyn...@li... >> > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev >> _______________________________________________ >> Dynapi-Dev mailing list >> Dyn...@li... >> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev > >_______________________________________________ >Dynapi-Dev mailing list >Dyn...@li... >http://lists.sourceforge.net/mailman/listinfo/dynapi-dev |
