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

[Robert R. <rra...@ya...>]

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