SV: [Dynapi-Dev] DynAPI build, Splitting files

[Bart B. <ba...@ho...>]

Clear and precise. My sentiments exactly.

-----Ursprungligt meddelande-----
Från: SReindl <SR...@la...>
Till: dyn...@li... <dyn...@li...>
Datum: den 10 december 2000 10:17
Ämne: 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