Re[2]: [Dynapi-Dev] DynAPI build, Splitting files

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

If you mean doing something like this:
if (is.ns)
 DynLayer.prototype.setHTML = function() {}
}

Then, it looks like you would only use it in the setX/Y, setBgImage,
and setHTML functions.  However, this would also require moving
the BrowserDetection function into the dynapi.js or dynlayer.js,
because it will not be loaded when the dynlayer is loading.

-- 
// Robert Rainwater

On 12/10/2000, 10:54:06 PM EST, Doug wrote about "[Dynapi-Dev] DynAPI build, Splitting files":

> Alreigth then, how about a suggestion made earlier (don't recall by whom)..
> Put some code into dynapi.js which will
> 'complie' the code for the specific browser in use?
> we can use place-holder vars (constants) and have dynapi.js set them
> according to
> what browser/platform is in use..

> Doug Melvin
> ----- Original Message -----
> From: "Pascal Bestebroer" <pa...@dy...>
> To: <dyn...@li...>
> Sent: Sunday, December 10, 2000 2:51 AM
> Subject: RE: [Dynapi-Dev] DynAPI build, Splitting files

>>
>> 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
>>
>> > -----Oorspronkelijk bericht-----
>> > Van: dyn...@li...
>> > [mailto:dyn...@li...]Namens SReindl
>> > Verzonden: zaterdag 9 december 2000 9:14
>> > Aan: dyn...@li...
>> > Onderwerp: 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
>>
>> _______________________________________________
>> 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