Menu
▾
▴
dynapi-dev
|
From: Bill W. <bil...@us...> - 2000-12-05 15:08:16
|
I kind of like the idea too. Perhaps it could be part of the perl make file that Dan (?) made over the weekend. Pass it a param to spit out IE4, IE5, NS4, NS6 etc. Then after the browser sniffer figures out which ua you have, load only the one you need. fast! -bw Alexey Medvedev <ma...@ca...> wrote: > > > versions. If you put equivant of #IFDEF (or whatever, it's been a long time > > code is in one place, and browser specific versions are developed together, > > It is interesting idea. > I thinks it could be done just with a "grep" (grep.exe) and sed :) > > ---src.js--- > > code.... > #IE sghd > #NN uuuuu > ------------ > > cat src.js | grep -v "^#IE" | sed s/"^#NN"//g >out.js > > But! > It would be hard to create the codes :-/ > If implementation ideology of DynLayer in IE and NN would be different. > (for example - use of <layer (or = new Layer())for NN as more > stable , than </div>). > > This one better to keep in different files. > > Malx > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 |
|
From: Bill W. <bil...@us...> - 2000-12-05 22:50:46
|
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
Dan Steinman <dy...@fu...> wrote:
> I just have to clean it up a bit and I'll have it ready to use this evening.
It's really quite a simple system. I'm not sure exactly what you want by
splitting the versions up. I mean, there's ways to do that, but why bother?
Right now it's just an easy way to compress and combine files, it does nothing
more. And we'll use it until we decide that a more sophisticated system is
needed.
>
> Dan
>
> On Tue, Dec 05, 2000 at 10:31:34AM -0000, Cameron Hart wrote:
> > This is probably a good way of splitting the code into different browser
> > versions. If you put equivant of #IFDEF (or whatever, it's been a long
time
> > since I touched C!) in the source Javascript, you could compile browser
> > specific versions from the one source distribution. At least then, all
the
> > code is in one place, and browser specific versions are developed
together,
> > not seperately.
> >
> > Cameron.
> >
> > > -----Original Message-----
> > > From: dyn...@li...
> > > [mailto:dyn...@li...]On Behalf Of Dan
Steinman
> > > Sent: 04 December 2000 03:52
> > > To: dyn...@li...
> > > Subject: [Dynapi-Dev] DynAPI Makefile/code compression almost complete
> > >
> > >
> > > This weekend I took on the task of creating a "build" system for
DynAPI.
> > >
> > > First part involved writing my own JavaScript whitespace/comment
> > > removal script (in Perl). It's pretty much complete and as good
> > > or better than any others I've seen. I'm calling it JSPack and
> > > will release this as a separate program that must be downloaded
> > > in order to "build" the DynAPI.
> > >
> > > It not only compresses JS code, it also packages the files
> > > together. And this will be used to create js packages for the
> > > DynAPI. For example, it will create the files dynapi.api.js,
> > > dynapi.gui.js... which contain all the classes in that
> > > subdirectory. I have to add one more feature to my script that
> > > determines the order that the objects should be added to the
> > > Package. For example, ScrollPane extends off of ViewPort, so in
> > > the dynapi.gui.js file, viewport.js must be added first.
> > > Therefore I plan to add files to the /lib/dynapi/ directories
> > > that state the order of the files. These will be named .jspack
> > > and will be a simple list of the js files in the order they are
> > > to be added to a package. My JSPack program will take care of the
rest.
> > >
> > > Right now JSPack does not parse the JavaScript, so it will not go
> > > through each of your lines and fix and incorrect or missing
> > > semicolon. There for it is essential that all files in the
> > > DynAPI have semi's on each line, as well in the following case:
> > >
> > > f = function() {
> > > }; // absolutely needed
> > >
> > > Second part is the Makefile. Up until now we've just been
> > > editing our files in /js/. But now we can use a separate
> > > directory /src/. This is where we edit our files. Our
> > > JavaScripts can contain comments, and do not have to be bunched
> > > up, because the Makefile will use the /src/ directory, compress
> > > all the code, and produce js packages, and jar files, and output
> > > it to /js/.
> > >
> > > So the /js/ directory will then contain a compressed release of our
code.
> > >
> > > In order to build the DynAPi you need to be using unix/linux or
> > > have Cygwin installed in Windows, along with Perl and the JDK
> > > (for Jarring the files). You need to place JSPack in your path,
> > > and then type:
> > >
> > > make
> > >
> > > in the /dynapi/ source tree. This runs the commands in the
> > > Makefile which does everything needed to produce the /js/ tree.
> > >
> > > I'm going through all of the existing JS code and putting the
> > > necessary semi colons, and will have everything ready to use in
> > > another day or 2. A first run-through of building the DynAPI
> > > produced a Jar file which 16KB!!!! (yes the entire DynAPI with
> > > the existing widgets can be compressed a lot).
> > >
> > > We can also use GZip to compress the files for use in IE 5, these
> > > will be a bit smaller than the Jar files. I don't believe there
> > > is any compression we can do for IE 4 though (other than
> > > whitespace removal).
> > >
> > > over and out,
> > > Dan
> > >
> > > _______________________________________________
> > > 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
____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1
|
|
From: Brandon M. <bnd...@ho...> - 2000-12-05 23:22:56
|
You're right up my ally there. That's some of the same reasoning that I came
up with, with others too.
But the code is reduced by about 1/3. Special browser specific javascript
can be placed where other generic javascript was used, also reducing the
size, and increasing speed.
----- Original Message -----
From: "Bill Wheaton" <bil...@us...>
To: <dyn...@li...>
Sent: Tuesday, December 05, 2000 5:50 PM
Subject: Re: [Re: [Dynapi-Dev] DynAPI Makefile/code compression almost
complete]
> 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
>
> Dan Steinman <dy...@fu...> wrote:
> > I just have to clean it up a bit and I'll have it ready to use this
evening.
> It's really quite a simple system. I'm not sure exactly what you want by
> splitting the versions up. I mean, there's ways to do that, but why
bother?
> Right now it's just an easy way to compress and combine files, it does
nothing
> more. And we'll use it until we decide that a more sophisticated system
is
> needed.
> >
> > Dan
> >
> > On Tue, Dec 05, 2000 at 10:31:34AM -0000, Cameron Hart wrote:
> > > This is probably a good way of splitting the code into different
browser
> > > versions. If you put equivant of #IFDEF (or whatever, it's been a long
> time
> > > since I touched C!) in the source Javascript, you could compile
browser
> > > specific versions from the one source distribution. At least then, all
> the
> > > code is in one place, and browser specific versions are developed
> together,
> > > not seperately.
> > >
> > > Cameron.
> > >
> > > > -----Original Message-----
> > > > From: dyn...@li...
> > > > [mailto:dyn...@li...]On Behalf Of Dan
> Steinman
> > > > Sent: 04 December 2000 03:52
> > > > To: dyn...@li...
> > > > Subject: [Dynapi-Dev] DynAPI Makefile/code compression almost
complete
> > > >
> > > >
> > > > This weekend I took on the task of creating a "build" system for
> DynAPI.
> > > >
> > > > First part involved writing my own JavaScript whitespace/comment
> > > > removal script (in Perl). It's pretty much complete and as good
> > > > or better than any others I've seen. I'm calling it JSPack and
> > > > will release this as a separate program that must be downloaded
> > > > in order to "build" the DynAPI.
> > > >
> > > > It not only compresses JS code, it also packages the files
> > > > together. And this will be used to create js packages for the
> > > > DynAPI. For example, it will create the files dynapi.api.js,
> > > > dynapi.gui.js... which contain all the classes in that
> > > > subdirectory. I have to add one more feature to my script that
> > > > determines the order that the objects should be added to the
> > > > Package. For example, ScrollPane extends off of ViewPort, so in
> > > > the dynapi.gui.js file, viewport.js must be added first.
> > > > Therefore I plan to add files to the /lib/dynapi/ directories
> > > > that state the order of the files. These will be named .jspack
> > > > and will be a simple list of the js files in the order they are
> > > > to be added to a package. My JSPack program will take care of the
> rest.
> > > >
> > > > Right now JSPack does not parse the JavaScript, so it will not go
> > > > through each of your lines and fix and incorrect or missing
> > > > semicolon. There for it is essential that all files in the
> > > > DynAPI have semi's on each line, as well in the following case:
> > > >
> > > > f = function() {
> > > > }; // absolutely needed
> > > >
> > > > Second part is the Makefile. Up until now we've just been
> > > > editing our files in /js/. But now we can use a separate
> > > > directory /src/. This is where we edit our files. Our
> > > > JavaScripts can contain comments, and do not have to be bunched
> > > > up, because the Makefile will use the /src/ directory, compress
> > > > all the code, and produce js packages, and jar files, and output
> > > > it to /js/.
> > > >
> > > > So the /js/ directory will then contain a compressed release of our
> code.
> > > >
> > > > In order to build the DynAPi you need to be using unix/linux or
> > > > have Cygwin installed in Windows, along with Perl and the JDK
> > > > (for Jarring the files). You need to place JSPack in your path,
> > > > and then type:
> > > >
> > > > make
> > > >
> > > > in the /dynapi/ source tree. This runs the commands in the
> > > > Makefile which does everything needed to produce the /js/ tree.
> > > >
> > > > I'm going through all of the existing JS code and putting the
> > > > necessary semi colons, and will have everything ready to use in
> > > > another day or 2. A first run-through of building the DynAPI
> > > > produced a Jar file which 16KB!!!! (yes the entire DynAPI with
> > > > the existing widgets can be compressed a lot).
> > > >
> > > > We can also use GZip to compress the files for use in IE 5, these
> > > > will be a bit smaller than the Jar files. I don't believe there
> > > > is any compression we can do for IE 4 though (other than
> > > > whitespace removal).
> > > >
> > > > over and out,
> > > > Dan
> > > >
> > > > _______________________________________________
> > > > 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
>
>
> ____________________________________________________________________
> Get free email and a permanent address at http://www.netaddress.com/?N=1
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
>
|
|
From: Cameron H. <ca...@bi...> - 2000-12-06 12:56:46
|
> 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. <snip> > 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 It would be smaller and faster in all cases because the client would only load and run code specific to their browser. for example, if (is.ie) ... would only get executed once when the client needed to select the ie specific version of the API to load at run time. That's pretty much the rational behind my suggestion. I'd seen a bit of discussion on the list about splitting the API source into different .js files for different browsers, the right one being imported when the user visits the page. IMHO splitting the API into browser specific .js files sounds like a bad idea, keeping the source together and letting a Makefile split it would be safer. Of course none of the developers have said they were going to split the API in this fashion. I imagine that doing this would be a hell of a lot of work, and you probably all have more important things to do :-) However if it ever did happen, I think a Makefile solution with #define and #ifdef style macros would be a good way of acheiving this. |
|
From: Doug M. <do...@cr...> - 2000-12-06 18:27:27
|
I second the humble opinions stated in this preceeding message.. :-) ----- Original Message ----- From: "Cameron Hart" <ca...@bi...> To: <dyn...@li...> Sent: Wednesday, December 06, 2000 4:56 AM Subject: RE: [Re: [Dynapi-Dev] DynAPI Makefile/code compression almost complete] > > 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. > <snip> > > 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 > > It would be smaller and faster in all cases because the client would only > load and run code specific to > their browser. for example, if (is.ie) ... would only get executed once when > the client needed to select the ie specific version of the API to load at > run time. > > That's pretty much the rational behind my suggestion. I'd seen a bit of > discussion on the list about splitting the API source into different .js > files for different browsers, the right one being imported when the user > visits the page. IMHO splitting the API into browser specific .js files > sounds like a bad idea, keeping the source together and letting a Makefile > split it would be safer. Of course none of the developers have said they > were going to split the API in this fashion. I imagine that doing this would > be a hell of a lot of work, and you probably all have more important things > to do :-) > > However if it ever did happen, I think a Makefile solution with #define and > #ifdef style macros would be a good way of acheiving this. > > |
|
From: Dougal C. <do...@gu...> - 2000-12-06 13:58:36
|
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." |
|
From: Dan S. <dy...@fu...> - 2000-12-06 15:17:46
|
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 |
|
From: Doug M. <do...@cr...> - 2000-12-06 18:34:09
|
I don't know what you consider crucial.. but, a recent study suggests that if your page takes more than 7 seconds to load (that's right, 7 seconds) then more than half of your viewer will get board and leave before they get to see all of the 'cool' and 'clever' stuff you have put on or done to your site Doug Melvin > 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 > |
|
From: Pascal B. <pa...@dy...> - 2000-12-06 21:28:23
|
according to my websites traffice.. the study is incorrect :)
Anyway, when you split things up you still have way to much to load within
7seconds, but compressions should give you that extra, and splitting things
up should not be done to gain size only speed.. which can actually be done
in an easier way in most cases.
the is variable is declared before anything loads, so you can use that in
the code at a few places that are "speed-critical".
I changed my moveTo method to this:
if (is.ns) {
DynLayer.prototype._setX=function(x){ this.css.left=this.x=x }
DynLayer.prototype._setY=function(y){ this.css.top=this.y=y }
} else {
DynLayer.prototype._setX=function(x){ this.css.pixelLeft=this.x=x }
DynLayer.prototype._setY=function(y){ this.css.pixelTop=this.y=y }
}
DynLayer.prototype.moveTo=function(x,y) {
if (x!=null) this._setX(x)
if (y!=null) this._setY(y)
this.invokeEvent('move')
}
which makes the correct method for the correct browser before running
things, so it's only called once without creating complete seperate files..
just moving the if statement out of the loop.
Pascal Bestebroer
pa...@dy...
http://www.dynamic-core.net
> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Doug Melvin
> Verzonden: woensdag 6 december 2000 22:33
> Aan: dyn...@li...
> Onderwerp: Re: [Dynapi-Dev] DynAPI build, Splitting files
>
>
> I don't know what you consider crucial.. but, a recent study suggests that
> if your page takes more than 7 seconds to load (that's right, 7 seconds)
> then more than half of your viewer will get board and leave
> before they get
> to see all of the 'cool' and 'clever' stuff you have put on or
> done to your
> site
>
> Doug Melvin
>
> > 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
>
|
|
From: Nuno F. <nun...@wi...> - 2000-12-07 00:21:21
|
That would mean that Flash is a failure, because I don't seem to remember a single flash page that takes less than 7 seconds to load, on a normal 56k connection. usually people tend to forget about load-times when they're expecting flash pages, especially with "cool" pre-loading screens. It's just a question that when you(generally speaking) know that a page is in HTML you raise your standards in terms of load times, and when you're expecting a Flash Page, suddenly 2min of waiting don't seem a long time.... NunoF -----Original Message----- From: dyn...@li... [mailto:dyn...@li...]On Behalf Of Doug Melvin Sent: quarta-feira, 6 de Dezembro de 2000 21:33 To: dyn...@li... Subject: Re: [Dynapi-Dev] DynAPI build, Splitting files I don't know what you consider crucial.. but, a recent study suggests that if your page takes more than 7 seconds to load (that's right, 7 seconds) then more than half of your viewer will get board and leave before they get to see all of the 'cool' and 'clever' stuff you have put on or done to your site Doug Melvin > 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 > |
|
From: Brandon M. <bnd...@ho...> - 2000-12-06 21:41:57
|
(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 |
|
From: Scott A. L. <sc...@sc...> - 2000-12-06 23:20:20
|
If there's going to be any splitting, I think it should only be done in the core files and maybe some of the heavier extensions. I'd rather not have to create split versions of a widget; at that point, it stops being cross-browser, so why bother having an API? It would be difficult enough just to maintain the core files for all browsers. -- scott andrew lepera ----------------------------------- web stuff: www.scottandrew.com music stuff: www.walkingbirds.com |
|
From: Brandon M. <bnd...@ho...> - 2000-12-07 03:07:28
|
Right... widgets should not be split. I agree that that's the entire purpose of a core API. The extensions, by definition, should be split due to their inherent purpose... extending a core object, or a sub class of a core. The number of core objects may increase in the future, and that could cause the API to grow to a level that is too much for a user to handle.. waiting for a download that is... ----- Original Message ----- From: "Scott Andrew LePera" <sc...@sc...> To: <dyn...@li...> Sent: Wednesday, December 06, 2000 6:20 PM Subject: Re: [Dynapi-Dev] DynAPI build, Splitting files > If there's going to be any splitting, I think it should only be done in > the core files and maybe some of the heavier extensions. I'd rather not > have to create split versions of a widget; at that point, it stops being > cross-browser, so why bother having an API? It would be difficult enough > just to maintain the core files for all browsers. > > -- > scott andrew lepera > ----------------------------------- > web stuff: www.scottandrew.com > music stuff: www.walkingbirds.com > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev |
|
From: Cameron H. <ca...@bi...> - 2000-12-07 09:58:10
|
> If there's going to be any splitting, I think it should only be done in > the core files and maybe some of the heavier extensions. I'd rather not > have to create split versions of a widget; at that point, it stops being > cross-browser, so why bother having an API? It would be difficult enough > just to maintain the core files for all browsers. I agree, if the whole thing gets split into lots of different browser specific files, it will potentially stop being a cross-browser API. Being cross-browser and abstracting site developers from the underlying cross-browser muck to me is one of the best reasons for using the API. I don't know if my Makefile idea is workable, it would be a pain to add a compile stage into the code/test development process. But then again, the API does mimick Java in many ways already ;-) On another note, does IE on Solaris and Mac even support VB? |
|
From: SReindl <SR...@la...> - 2000-12-07 17:14:02
|
Can someone pls explain me the mneaning of this whole discussion? An API is a set of uniquely defined functions to perform a given task, isn't it? What do the widgets have to do with the API? Why should it be so difficult to develop the API in separate files? The discussion would be which function of the API should be added / removed / corrected / ... The rest will be done by the respective browser gurus. The charme of the split file version is that a nn specialist doesn't have to analyze a bulk of ie code in order to do his task. The increase in speed an code transparency should overweigh the difficulties of a split version by far. If a solution fullfills the defined function, who cares about the details? I mean, I want to develop mainly for IE and am not interested in the nn specifics at all. I am satisfied when it works. Stephan |
|
From: Robert R. <rra...@ya...> - 2000-12-07 17:29:15
|
There is one major problem with splitting the files and having different people working on them. The separate versions for each browser will become inconsistent with each other when people make changes to one and not the other. People will add "features" to some versions and not to others. Then, you don't have a cross-browser library, but a useless waste of files. By the way has anybody looked at the compresses files that are now apart of the DynAPI? -- // Robert Rainwater On 12/7/2000, 12:13:07 PM EST, SReindl wrote about "AW: [Dynapi-Dev] DynAPI build, Splitting files": > Can someone pls explain me the mneaning of this whole discussion? > An API is a set of uniquely defined functions to perform a given task, isn't > it? > What do the widgets have to do with the API? > Why should it be so difficult to develop the API in separate files? > The discussion would be which function of the API should be added / removed > / corrected / ... > The rest will be done by the respective browser gurus. > The charme of the split file version is that a nn specialist doesn't have to > analyze a bulk of ie code in order to do his task. > The increase in speed an code transparency should overweigh the difficulties > of a split version by far. > If a solution fullfills the defined function, who cares about the details? > I mean, I want to develop mainly for IE and am not interested in the nn > specifics at all. I am satisfied when it works. > Stephan > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev |
|
From: Alexey M. <ma...@ca...> - 2000-12-07 18:39:53
|
> browser will become inconsistent with each other when people make This one could be solved: 2) you need tests for all specific API calls and screenshots of what must be (see Pascal page). 1) you need definite group of people , who will run this tests on all possible architectures Arch/OS/brows. And they must notify all if they do not like to make tests any more. > changes to one and not the other. People will add "features" to some This must be mirrored as "change to API" in some TXT file with list of all object/methods. CVS will make all work to keep who change what. Idea of API chage must be approved by developers here in list. Malx -- There is no thing in the world, which is more powerfull, than default |
|
From: Robert R. <rra...@ya...> - 2000-12-07 19:44:27
|
Yes, thats great, but who is going to oversee all of this? Why can't we spend more time on testing and debugging the code that is there now. All of the stuff you are talking about can be done by creating a parser, but I don't feel it needs to be done to the official distro. -- // Robert Rainwater On 12/7/2000, 1:38:00 PM EST, Alexey wrote about "AW: [Dynapi-Dev] DynAPI build, Splitting files": >> browser will become inconsistent with each other when people make > This one could be solved: > 2) you need tests for all specific API calls and screenshots of > what must be (see Pascal page). > 1) you need definite group of people , who will run this > tests on all possible architectures Arch/OS/brows. > And they must notify all if they do not like to make tests > any more. >> changes to one and not the other. People will add "features" to some > This must be mirrored as "change to API" > in some TXT file with list of all object/methods. > CVS will make all work to keep who change what. > Idea of API chage must be approved by developers here in list. > Malx |
|
From: Pascal B. <pa...@dy...> - 2000-12-07 18:05:34
|
An API is a middle-layer between the code and the "environment" seeing as you want to have cross-browser code it sounds better to see one single api file that takes care of all browsers.. not having seperate files for every browser (that would create a DHTML library, not an API.. simple solution change the name to DynLib :) Developing in seperate files for seperate browsers WILL create seperate things, even though there is talk about setting "rules" for the development, we have to face it that streaming this whole project is not something any of us is good at.. so sticking to the development rules (even when you could do cool things like using behaviours in IE5 for filter effects and stuff) will be, in my opinion, impossible to maintain. Almost the same as asking Netscape and Microsoft to stick to the W3C standard.. (and then making sure that the W3C doesn't change everything every year :-) Someone debugging NN code should just skip the part that says if (is.ie) .. that's not a hard thing to do. Also I don't see where you could make the speed advantages? the slowness of it all is within the browsers.. try changing a single stylesheet property, in IE it looks like it's rerendering everything on screen and I believe that's the main problem, so how can you increase speed when splitting things up? "I mean, I want to develop mainly for IE and am not interested in the nn specifics at all. I am satisfied when it works." Then why use a cross-browser API (or library for that matter)? Pascal Bestebroer pa...@dy... http://www.dynamic-core.net > -----Oorspronkelijk bericht----- > Van: dyn...@li... > [mailto:dyn...@li...]Namens SReindl > Verzonden: donderdag 7 december 2000 18:13 > Aan: dyn...@li... > Onderwerp: AW: [Dynapi-Dev] DynAPI build, Splitting files > > > Can someone pls explain me the mneaning of this whole discussion? > An API is a set of uniquely defined functions to perform a given > task, isn't > it? > What do the widgets have to do with the API? > Why should it be so difficult to develop the API in separate files? > The discussion would be which function of the API should be added > / removed > / corrected / ... > The rest will be done by the respective browser gurus. > The charme of the split file version is that a nn specialist > doesn't have to > analyze a bulk of ie code in order to do his task. > The increase in speed an code transparency should overweigh the > difficulties > of a split version by far. > If a solution fullfills the defined function, who cares about the details? > I mean, I want to develop mainly for IE and am not interested in the nn > specifics at all. I am satisfied when it works. > > Stephan > > > > _______________________________________________ > Dynapi-Dev mailing list > Dyn...@li... > http://lists.sourceforge.net/mailman/listinfo/dynapi-dev > |
|
From: Dan S. <dy...@fu...> - 2000-12-07 18:37:25
|
I would much sooner do Pascals earlier suggestion of creating different methods and adding them based on the browser:
if (is.ns4) DynLayer.prototype.moveTo = DynLayer_moveToNS4;
if (is.ie4) ...
function DynLayer_moveToNS4() {}
But keep all the code in the same file. After compressing the DynAPI the difference in file size is almost a non-issue (like 1 or 2Kb difference). It's not out of the question to have a script that splits the files for build releases though, but it by no means has to be done right away.
Dan
On Thu, Dec 07, 2000 at 07:09:10PM +0100, Pascal Bestebroer wrote:
> An API is a middle-layer between the code and the "environment" seeing as
> you want to have cross-browser code it sounds better to see one single api
> file that takes care of all browsers.. not having seperate files for every
> browser (that would create a DHTML library, not an API.. simple solution
> change the name to DynLib :)
>
> Developing in seperate files for seperate browsers WILL create seperate
> things, even though there is talk about setting "rules" for the development,
> we have to face it that streaming this whole project is not something any of
> us is good at.. so sticking to the development rules (even when you could do
> cool things like using behaviours in IE5 for filter effects and stuff) will
> be, in my opinion, impossible to maintain. Almost the same as asking
> Netscape and Microsoft to stick to the W3C standard.. (and then making sure
> that the W3C doesn't change everything every year :-)
>
> Someone debugging NN code should just skip the part that says if (is.ie) ..
> that's not a hard thing to do.
>
> Also I don't see where you could make the speed advantages? the slowness of
> it all is within the browsers.. try changing a single stylesheet property,
> in IE it looks like it's rerendering everything on screen and I believe
> that's the main problem, so how can you increase speed when splitting things
> up?
>
> "I mean, I want to develop mainly for IE and am not interested in the nn
> specifics at all. I am satisfied when it works."
>
> Then why use a cross-browser API (or library for that matter)?
>
>
> Pascal Bestebroer
> pa...@dy...
> http://www.dynamic-core.net
>
> > -----Oorspronkelijk bericht-----
> > Van: dyn...@li...
> > [mailto:dyn...@li...]Namens SReindl
> > Verzonden: donderdag 7 december 2000 18:13
> > Aan: dyn...@li...
> > Onderwerp: AW: [Dynapi-Dev] DynAPI build, Splitting files
> >
> >
> > Can someone pls explain me the mneaning of this whole discussion?
> > An API is a set of uniquely defined functions to perform a given
> > task, isn't
> > it?
> > What do the widgets have to do with the API?
> > Why should it be so difficult to develop the API in separate files?
> > The discussion would be which function of the API should be added
> > / removed
> > / corrected / ...
> > The rest will be done by the respective browser gurus.
> > The charme of the split file version is that a nn specialist
> > doesn't have to
> > analyze a bulk of ie code in order to do his task.
> > The increase in speed an code transparency should overweigh the
> > difficulties
> > of a split version by far.
> > If a solution fullfills the defined function, who cares about the details?
> > I mean, I want to develop mainly for IE and am not interested in the nn
> > specifics at all. I am satisfied when it works.
> >
> > Stephan
> >
> >
> >
> > _______________________________________________
> > 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
|
|
From: Alexey M. <ma...@ca...> - 2000-12-07 18:52:38
|
> Netscape and Microsoft to stick to the W3C standard.. (and then making sure
> that the W3C doesn't change everything every year :-)
Have you heard about "emulation" of brouser DOM library?
if(ie) {document.layers=new Array()
document.layers[0]=document.all[xxx]
etc....
}
So you really could make library,
which makes browser W3C compatible
You need to make "document.getElementById = My_nn_func()"
and others....
But is it worth to do so?
(also could in IE be done catching of Event , when user makes a.a="b" ?)
> Also I don't see where you could make the speed advantages? the slowness of
"if" statemant always use much CPU.
and here it is in cycles.
> in IE it looks like it's rerendering everything on screen and I believe
> that's the main problem,
:)
Netscape4 will not rerender - it also called a problem of NN :)))
(you could do it manually if you know function name - I do not :-/
Malx
|
|
From: Scott A. L. <sc...@sc...> - 2000-12-07 19:56:47
|
I'm really enjoying the discussion this thread is producing, but it seems to me that, at this point, splitting the API up by browser shouldn't be a priority. I agree that the benefits of splitting are minimal at this point and would require lots of careful maintenance that a lot of people won't bother to do. I don't think imposing tight restrictions on development is really true to the spirit of this API. Once we decide to have official requirements -- whether it be splitting, an "official" widget model or inheritance scheme -- then we'll also have to have to impose rules so that people won't doing things that will break our precious standard. The only thing that should be standard for now is the core. Everything else can be done however you want to. If you wanted, you can do as Pascal did and use the DynAPI2 source to build in whatever modifications you desired. That doesn't mean that we won't do it in the future, though. -- scott andrew lepera ----------------------------------- web stuff: www.scottandrew.com music stuff: www.walkingbirds.com |
|
From: SReindl <SR...@la...> - 2000-12-10 09:17:50
|
Well, call it as you like: Lib ode API, ... An API has the task to supply
you with a unique set of functions in order to perform some development
tasks. In this case this is cross browser compatible programming of web
sites (btw, an API can be stored in a lib ;-))
I agree, that the API is not meant to be a play ground for fancy stuff which
may be possible only for one particular browser.
But I don't see why the "streaming of the project" should be more work for
separate files than for monolithic ones.
It's the definition of the basis of functions which is important, and this
task has already been done, since the DynAPI is up and running.
Look at this piece (from events.js):
this.pageX=is.ie?e.x+document.body.scrollLeft:e.pageX-window.pageXOffset
this.pageY=is.ie?e.y+document.body.scrollTop:e.pageY-window.pageYOffset
this.x=is.ie?e.offsetX:e.layerX
this.y=is.ie?e.offsetY:e.layerY
var b = is.ie?e.button:e.which
if (is.ie){
if (b==2) b = 3
else if (b==4) b = 2
} else { }
All this is done only to define two basic paisr of vars. Terrible. And
impossible just to skip the nn stuff, becoause it's not clear, what refers
to nn but only what is not for ie. I have to go through it and to learn the
syntax of several browsers (document.body.scrollLeft vs window.pageXOffset,
etc., and do not forget the sign).
My
> "I mean, I want to develop mainly for IE and am not interested in the nn
> specifics at all. I am satisfied when it works."
if of course *an example* only and not the goal of my programs.
last not least, in addition to decrease in loading and rendering time there
is one more feature which speaks for a split: control over completeness. If
you have to assure that your implementation is complete you will have to
code all the functions. The chance just to forget an if branch is smaller.
I do not say that cross browser compatibility should be given up, I think of
how this task can be done in a more transparent way.
Stephan
> An API is a middle-layer between the code and the "environment" seeing as
> you want to have cross-browser code it sounds better to see one single api
> file that takes care of all browsers.. not having seperate files for every
> browser (that would create a DHTML library, not an API.. simple solution
> change the name to DynLib :)
>
> Developing in seperate files for seperate browsers WILL create seperate
> things, even though there is talk about setting "rules" for the
> development,
> we have to face it that streaming this whole project is not
> something any of
> us is good at.. so sticking to the development rules (even when
> you could do
> cool things like using behaviours in IE5 for filter effects and
> stuff) will
> be, in my opinion, impossible to maintain. Almost the same as asking
> Netscape and Microsoft to stick to the W3C standard.. (and then
> making sure
> that the W3C doesn't change everything every year :-)
>
> Someone debugging NN code should just skip the part that says if
> (is.ie) ..
> that's not a hard thing to do.
>
> Also I don't see where you could make the speed advantages? the
> slowness of
> it all is within the browsers.. try changing a single stylesheet property,
> in IE it looks like it's rerendering everything on screen and I believe
> that's the main problem, so how can you increase speed when
> splitting things
> up?
>
> "I mean, I want to develop mainly for IE and am not interested in the nn
> specifics at all. I am satisfied when it works."
>
> Then why use a cross-browser API (or library for that matter)?
>
>
> Pascal Bestebroer
> pa...@dy...
> http://www.dynamic-core.net
>
>
> >
> > Can someone pls explain me the mneaning of this whole discussion?
> > An API is a set of uniquely defined functions to perform a given
> > task, isn't
> > it?
> > What do the widgets have to do with the API?
> > Why should it be so difficult to develop the API in separate files?
> > The discussion would be which function of the API should be added
> > / removed
> > / corrected / ...
> > The rest will be done by the respective browser gurus.
> > The charme of the split file version is that a nn specialist
> > doesn't have to
> > analyze a bulk of ie code in order to do his task.
> > The increase in speed an code transparency should overweigh the
> > difficulties
> > of a split version by far.
> > If a solution fullfills the defined function, who cares about
> the details?
> > I mean, I want to develop mainly for IE and am not interested in the nn
> > specifics at all. I am satisfied when it works.
> >
> > Stephan
> >
|
|
From: Robert R. <rra...@ya...> - 2000-12-10 16:55:39
|
What advantage would you gain by splitting up your example? Speed
wise, that is not the reason for loading taking a long time. The
speed problems are due to DynLayer creation. If you haven't seen yet,
Dan is creating a new inline dynlayer creation system that will speed
up this process. While splitting up the core files may seem nice, it
offers no real advantage. Especially with the new jspack files, the
file sizes are going to be small anyways.
--
// Robert Rainwater
On 12/9/2000, 3:13:32 AM EST, SReindl wrote about "AW: [Dynapi-Dev] DynAPI build, Splitting files":
> Well, call it as you like: Lib ode API, ... An API has the task to supply
> you with a unique set of functions in order to perform some development
> tasks. In this case this is cross browser compatible programming of web
> sites (btw, an API can be stored in a lib ;-))
> I agree, that the API is not meant to be a play ground for fancy stuff which
> may be possible only for one particular browser.
> But I don't see why the "streaming of the project" should be more work for
> separate files than for monolithic ones.
> It's the definition of the basis of functions which is important, and this
> task has already been done, since the DynAPI is up and running.
> Look at this piece (from events.js):
> this.pageX=is.ie?e.x+document.body.scrollLeft:e.pageX-window.pageXOffset
> this.pageY=is.ie?e.y+document.body.scrollTop:e.pageY-window.pageYOffset
> this.x=is.ie?e.offsetX:e.layerX
> this.y=is.ie?e.offsetY:e.layerY
> var b = is.ie?e.button:e.which
> if (is.ie){
> if (b==2) b = 3
> else if (b==4) b = 2
> } else { }
> All this is done only to define two basic paisr of vars. Terrible. And
> impossible just to skip the nn stuff, becoause it's not clear, what refers
> to nn but only what is not for ie. I have to go through it and to learn the
> syntax of several browsers (document.body.scrollLeft vs window.pageXOffset,
> etc., and do not forget the sign).
> My
>> "I mean, I want to develop mainly for IE and am not interested in the nn
>> specifics at all. I am satisfied when it works."
> if of course *an example* only and not the goal of my programs.
> last not least, in addition to decrease in loading and rendering time there
> is one more feature which speaks for a split: control over completeness. If
> you have to assure that your implementation is complete you will have to
> code all the functions. The chance just to forget an if branch is smaller.
> I do not say that cross browser compatibility should be given up, I think of
> how this task can be done in a more transparent way.
> Stephan
>> An API is a middle-layer between the code and the "environment" seeing as
>> you want to have cross-browser code it sounds better to see one single api
>> file that takes care of all browsers.. not having seperate files for every
>> browser (that would create a DHTML library, not an API.. simple solution
>> change the name to DynLib :)
>>
>> Developing in seperate files for seperate browsers WILL create seperate
>> things, even though there is talk about setting "rules" for the
>> development,
>> we have to face it that streaming this whole project is not
>> something any of
>> us is good at.. so sticking to the development rules (even when
>> you could do
>> cool things like using behaviours in IE5 for filter effects and
>> stuff) will
>> be, in my opinion, impossible to maintain. Almost the same as asking
>> Netscape and Microsoft to stick to the W3C standard.. (and then
>> making sure
>> that the W3C doesn't change everything every year :-)
>>
>> Someone debugging NN code should just skip the part that says if
>> (is.ie) ..
>> that's not a hard thing to do.
>>
>> Also I don't see where you could make the speed advantages? the
>> slowness of
>> it all is within the browsers.. try changing a single stylesheet property,
>> in IE it looks like it's rerendering everything on screen and I believe
>> that's the main problem, so how can you increase speed when
>> splitting things
>> up?
>>
>> "I mean, I want to develop mainly for IE and am not interested in the nn
>> specifics at all. I am satisfied when it works."
>>
>> Then why use a cross-browser API (or library for that matter)?
>>
>>
>> Pascal Bestebroer
>> pa...@dy...
>> http://www.dynamic-core.net
>>
>>
>> >
>> > Can someone pls explain me the mneaning of this whole discussion?
>> > An API is a set of uniquely defined functions to perform a given
>> > task, isn't
>> > it?
>> > What do the widgets have to do with the API?
>> > Why should it be so difficult to develop the API in separate files?
>> > The discussion would be which function of the API should be added
>> > / removed
>> > / corrected / ...
>> > The rest will be done by the respective browser gurus.
>> > The charme of the split file version is that a nn specialist
>> > doesn't have to
>> > analyze a bulk of ie code in order to do his task.
>> > The increase in speed an code transparency should overweigh the
>> > difficulties
>> > of a split version by far.
>> > If a solution fullfills the defined function, who cares about
>> the details?
>> > I mean, I want to develop mainly for IE and am not interested in the nn
>> > specifics at all. I am satisfied when it works.
>> >
>> > Stephan
>> >
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
|
|
From: Pascal B. <pa...@dy...> - 2000-12-10 17:21:56
|
This is a repost (previous one seems to have gotten lost :) Once you split up parts of the API for every browser (that could eventually include Opera, and other flavours) it means that people will start focusing on a single browser because that's the browser they'll be using. Ofcourse this is already being done on a smaller scale (Dan's main focus seems to be Netscape, and my focus is more IE5+) but at this point because of the code being one , we know that what ever we do should also work Netscape.. once you split things up I think this "awareness" will disappear and people will just enhance the code for that single browser and let someone else worry about the other browsers files. "All this is done only to define two basic paisr of vars. Terrible. And impossible just to skip the nn stuff, becoause it's not clear, what refers to nn but only what is not for ie. I have to go through it and to learn the" that's correct, just two basic pairs of vars, so you want to split all code up for simple things like these? And the fact that you have to go thru it and learn the differences is exactly my point, if you have the chance to only do your coding for IE, you will forget about NS and this might cause you to implement things in IE that are not possible in NS. Ofcourse this means we're holding back one browser because of the incompatibilities with the other, but that's the problem with cross-browser coding, and if you need that extra functionality you should added it in your own code, not in the general API. The problem with speed that everybody talks about is not such a big issue, we're not developing for 386 or 486 machines anymore, Pentium machines don't take 2 or 3 clock-cycles to do a simple IF statement. Besides the IF statements are only called at initialisation and when changing styles, the main bottle-neck is not the IF statement but the time it takes browsers to redo the style sheet (and rerender things). This is just a browser problem, not a code problem. And ofcourse size isn't such a big issue neither, seeing that most of the differences (I know, not all) are done on single lines as you pointed out: is.ie?e.x+document.body.scrollLeft:e.pageX-window.pageXOffset this will only be a few bytes difference once you split it up: e.x+document.body.scrollLeft so maybe you save some bytes with the split but you have to include all files multiple times and maintain all files multiple times for your site to look good on all browsers. apologies for the long post :) cya, Pascal Bestebroer pa...@dy... http://www.dynamic-core.net |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X