dynapi-dev

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

[Darin K. <dka...@ef...>]

Amen.

-----Original Message-----
From: Scott Andrew LePera [mailto:sc...@sc...]
Sent: Wednesday, December 06, 2000 3:21 PM
To: dyn...@li...
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

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

[Guangyi Wu <gua...@al...>]

The life would be simpler if widgets should not be split. However, when
performance is an considerable issue, we might find later it is also an
admired feature if we can get widgets with an uniformed interface and
browser depended implementation. If we decide to split the API, why don't we
split it in a graceful and general way, so that other modules can also be
benifit?

I would sugest to open a new package to implement this feature after the
current version becomes stable. Only when a class applies this feature, the
correct files/objects would be included. In this way, we do not have to
break the worked version, and get a more generally useful package.

br
George

> 
> 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
> 
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
> 

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

[Pascal B. <pa...@dy...>]

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

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

[Doug M. <do...@cr...>]

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

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

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

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

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

[Pascal B. <pb...@oi...>]

The problem with this (dynapi) situation and your example is that in the
DynAPI not ALL code is browser independend, in your example all text would
be different for every language.

"..but it's important to see all the versions together in order to be sure
that any change is done simultaneoulsy"

yes.

"split the files and let the german version be done by a native german
speaking (if available)"

I think when you'r doing cross-browser dhtml you should already be aware of
what browsers can do, so I don't think this applies. If you don't know the
capabilities of both browsers you will get the differences in the
implementation, something we don't want because we're creating a
cross-browser api that should work on all browser in the same way with the
same functionality.



Pascal Bestebroer
pb...@oi...
http://www.oibv.com


-----Oorspronkelijk bericht-----
Van: dyn...@li...
[mailto:dyn...@li...]Namens Stephan Reindl
Verzonden: maandag 11 december 2000 15:53
Aan: dyn...@li...
Onderwerp: AW: [Dynapi-Dev] DynAPI build, Splitting files


Oh come on. If you're supposed to write an international site for visitors
in 5 languages, would you really consider writing (and editing) all the
different texts, labels, figure captions, etc in ONE file only and
separating the languages by deeply nested if`s ?
Would you say, ok, I don't know german so well, but it's important to see
all the versions together in order to be sure that any change is done
simultaneoulsy. I try to learn german (and french and kisuaheli, etc.)
Or would you prefer to define the "look & feel" of the site, split the files
and let the german version be done by a native german speaking (if
available)?

Stephan


>
> 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.
>
> --


_______________________________________________
Dynapi-Dev mailing list
Dyn...@li...
http://lists.sourceforge.net/mailman/listinfo/dynapi-dev