dynapi-dev

Re: [Dynapi-Dev] Splitting the API?

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

 
> I have completed splitting the API into parts for IE and 
NS, even to their
> specific versions. I have nodiced a 10x increase in 
speed. And a great
> increase in stability.

I believe that the current API model is a very sound and 
applicable one. It is coherent and easily followed. But....
Speed and stability easily outweigh ease of implementation. 
This I have concluded trying to create complicated webapps 
in dHtml. 
Another thing is that a split would decrease the amount of 
browser checking in the API, which would also speed things 
up.
 
> If the community was to appoint a maintainer for each 
browser, someone who
> is highly sufficient in the capabilities of the browser, 
then they can
> optimize their versions without fear of gumming up the 
works for other
> browsers and platforms.

This is a VERY valid point. Trying to keep platform 
compatability intact while developing is a royal pain in 
the ass. 
  
 
> I'm not staying it will be easy. But I believe that the 
benifits would
> outway the work it would entail.

This I totally agree with.

/ Bart


> ----- Original Message -----
> From: "Abel Eduardo Cantu Salas" 
<abe...@al...>
> To: <dyn...@li...>
> Sent: Thursday, November 30, 2000 2:00 PM
> Subject: RE: [Dynapi-Dev] inheritance crusade / 
SuperClass stuff
> 
> 
> > > But isn't it better to use optimised versions for the 
browser, not
> > > the one for all?
> >
> > It sound very interesting indeed Alexey... then you can 
also create new js
> > for newer browsers whithout any need to touch other js 
(just like dlls or
> > device drivers, you'll load what you need); it will 
allow you to reduce
> the
> > amount of code that the client most download and most 
important than that
> is
> > the fact that this code will be really very optimised. 
However this has an
> > important drawback that we most consider:
> >
> > Doing this means an extra work in trying to maintain 
standardized all the
> > APIS for diferent platforms and diferent browsers, id 
est, if we add
> > something to an API we must add the same functionality 
to all other; and
> not
> > just that, separating everything so you can then 
optimize a lot, could
> make
> > easy a loss of control in what is disponible for what 
platform.
> >
> > Im sure we don't want a DynAPI that says: "this is 
disponible only for NS"
> > or vice versa, then we most work a lot to keep things 
in the right path.
> >
> > Any opinions or sugestions about this matter?, there is 
a lot of
> advantages
> > and drawbacks in a schema like this...
> >
> > -----Original Message-----
> > From: dyn...@li...
> > [mailto:dyn...@li...]On 
Behalf Of Alexey
> > Medvedev
> > Sent: Jueves, 30 de Noviembre de 2000 10:42 a.m.
> > To: dyn...@li...
> > Subject: Re: Re: Re: [Dynapi-Dev] inheritance crusade / 
SuperClass stuff
> >
> >
> > On Thu, 30 Nov 2000, Barre Bizon wrote:
> >
> > Yes - I told it is JS_1.3_
> >
> > > Another thing... neither the function.call() nor the
> > > function.apply() method work under IE4+.
> > > Unfortunately.
> >
> > Also add .watch() to the list :-/
> >
> >  But isn't it better to use optimised versions for the 
brouser, not
> >  the one for all?
> >
> >   So main "dynapi" whould be a selector 
of "dynlayer_ns4.js"
> > or "dynlayer_ie4.js" but keeping same API?
> >
> > I thinks using "new Layer" in NN4 is better then 
creating
> >  lots of CSS and <div>-s (memory usage and resistance 
to Resize):
> >
> > http://deep.kiev.ua/JS/WebGram/ - resize resistant 
without
> >  any reloads.
> >
> > ps. last one i need to make site as one page , with 
changed layers
> > Same as www.htmlguru.com is.
> >
> > Malx
> >
> > _______________________________________________
> > 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

RE: [Dynapi-Dev] Splitting the API?

[Cameron H. <ca...@bi...>]

I posted a suggestion to Dan's message about using a Makefile system for
building a final version of the code, I thought it would be worth suggesting
it to this thread of the discussion.

I think it would be a good idea to have a C style #define in the src
javascript to allow building final versions for different browsers. I think
the advantage of doing this is the cross-browser API remains in one set of
source, and users people can then build either seperate versions for each
browser, or build them all into one library. From a development point of
view, to me it makes more sense to keep all the code in a canonical form,
rather than split for every major browser/platform that comes into
existence.

Cam.

> -----Original Message-----
> From: dyn...@li...
> [mailto:dyn...@li...]On Behalf Of Eytan
> Heidingsfeld
> Sent: 05 December 2000 09:24
> To: dyn...@li...
> Subject: Re: [Dynapi-Dev] Splitting the API?
>
>
> Although I am not so sure why thing would run so much better with the API
> split I also have 2c. Basically everything that is browser based are the
> actual low-level components (DynLayer, events....) why don't we
> split those
> components in to one for each version. Then when a higher level
> component (a
> decendent) is created in the constructor you add the following code
> if (browser == IE){inherit from IEDynLayer;}
> if (browser == NS){inherit from NSDynLayer;}
> ..
> ..
> ..
> You get the picture. Then although it might be a hassle to orginize the
> low-level comps the higher level one will be relitivly easy.
>
> 8an
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev

Re[2]: [Dynapi-Dev] Splitting the API?

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

I think right now there a bigger issues.  Such as bugs in the
pushpanel, scrollpanel, and loadpanel.  If we can make this version
stable, then creating a parser to separate the code would be nice.
But, it really is not the most important problem right now.  We need
to release a new version soon, but we can't until it becomes stable.

-- 
// Robert Rainwater

On 12/5/2000, 5:51:29 AM EST, Cameron wrote about "[Dynapi-Dev] Splitting the API?":

> I posted a suggestion to Dan's message about using a Makefile system for
> building a final version of the code, I thought it would be worth suggesting
> it to this thread of the discussion.

> I think it would be a good idea to have a C style #define in the src
> javascript to allow building final versions for different browsers. I think
> the advantage of doing this is the cross-browser API remains in one set of
> source, and users people can then build either seperate versions for each
> browser, or build them all into one library. From a development point of
> view, to me it makes more sense to keep all the code in a canonical form,
> rather than split for every major browser/platform that comes into
> existence.

> Cam.

>> -----Original Message-----
>> From: dyn...@li...
>> [mailto:dyn...@li...]On Behalf Of Eytan
>> Heidingsfeld
>> Sent: 05 December 2000 09:24
>> To: dyn...@li...
>> Subject: Re: [Dynapi-Dev] Splitting the API?
>>
>>
>> Although I am not so sure why thing would run so much better with the API
>> split I also have 2c. Basically everything that is browser based are the
>> actual low-level components (DynLayer, events....) why don't we
>> split those
>> components in to one for each version. Then when a higher level
>> component (a
>> decendent) is created in the constructor you add the following code
>> if (browser == IE){inherit from IEDynLayer;}
>> if (browser == NS){inherit from NSDynLayer;}
>> ..
>> ..
>> ..
>> You get the picture. Then although it might be a hassle to orginize the
>> low-level comps the higher level one will be relitivly easy.
>>
>> 8an
>>
>> _______________________________________________
>> 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] Splitting the API?

[Brandon M. <bnd...@ho...>]

ACK! That would make development a nightmare..
Change the original code... run it through the code splitter, run the
test...

I like just changing the code, hit refresh on browser page... much
quicker... one less window.

----- Original Message -----
From: "Cameron Hart" <ca...@bi...>
To: <dyn...@li...>
Sent: Tuesday, December 05, 2000 5:51 AM
Subject: RE: [Dynapi-Dev] Splitting the API?


> I posted a suggestion to Dan's message about using a Makefile system for
> building a final version of the code, I thought it would be worth
suggesting
> it to this thread of the discussion.
>
> I think it would be a good idea to have a C style #define in the src
> javascript to allow building final versions for different browsers. I
think
> the advantage of doing this is the cross-browser API remains in one set of
> source, and users people can then build either seperate versions for each
> browser, or build them all into one library. From a development point of
> view, to me it makes more sense to keep all the code in a canonical form,
> rather than split for every major browser/platform that comes into
> existence.
>
> Cam.
>
> > -----Original Message-----
> > From: dyn...@li...
> > [mailto:dyn...@li...]On Behalf Of Eytan
> > Heidingsfeld
> > Sent: 05 December 2000 09:24
> > To: dyn...@li...
> > Subject: Re: [Dynapi-Dev] Splitting the API?
> >
> >
> > Although I am not so sure why thing would run so much better with the
API
> > split I also have 2c. Basically everything that is browser based are the
> > actual low-level components (DynLayer, events....) why don't we
> > split those
> > components in to one for each version. Then when a higher level
> > component (a
> > decendent) is created in the constructor you add the following code
> > if (browser == IE){inherit from IEDynLayer;}
> > if (browser == NS){inherit from NSDynLayer;}
> > ..
> > ..
> > ..
> > You get the picture. Then although it might be a hassle to orginize the
> > low-level comps the higher level one will be relitivly easy.
> >
> > 8an
> >
> > _______________________________________________
> > 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