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 <[EMAIL PROTECTED]>
Till: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
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" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>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 <[EMAIL PROTECTED]>
>> > 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
>> > [EMAIL PROTECTED]
>> > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>> _______________________________________________
>> Dynapi-Dev mailing list
>> [EMAIL PROTECTED]
>> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>
>_______________________________________________
>Dynapi-Dev mailing list
>[EMAIL PROTECTED]
>http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
