Menu
▾
▴
dynapi-dev
|
From: Barre B. <ba...@ho...> - 2000-11-30 10:20:10
|
Well thanks for the tutorial man... but you obviously
didn't read my previous posts...
Object orientation exists for a purpose, and no, Javascript
isn't "true" OOP, but close enough to be able to use the
most fundamental principles of OOP, for self explanatory
reasons.
I guess it comes down to a matter of taste and preference.
I thought creating a constructor method was a clean and
easy way of doing "extended" functions initialization.
But sure, assigning DynLayer as a method and then calling
it works too... :)
/ Bart
> On Wed, 29 Nov 2000, Barre Bizon wrote:
>
>
> I thinks you have learned too much of OOP languages
like
> Java C++ etc.
> JavaScript is not OOP - it is Object Language - not
> just merely OO :)
>
> I would recomend to look deeper into JavaScript.
> If i'm not mistaken - DunAPI never uses such thing
as "with"
>
> Also ... If only Netscape4 would be standart....
and JavaScrip1.3
> with it:
> ----------------------
> You can use call to chain constructors for an object,
> similar to Java. In the following example, the constructor
> for the product object is defined with two parameters,
> name and value. Another object, prod_dept, initializes its
> unique variable (dept) and calls the constructor for
> product in its constructor to initialize the other
variables.
>
> function product(name, value){
> this.name = name;
> if(value > 1000)
> this.value = 999;
> else
> this.value = value;
> }
>
> function prod_dept(name, value, dept){
> this.dept = dept;
> product.call(this, name, value);
> }
>
> prod_dept.prototype = new product();
>
> // since 5 is less than 100 value is set
> cheese = new prod_dept("feta", 5, "food");
>
> // since 5000 is above 1000, value will be 999
> car = new prod_dept("honda", 5000, "auto");
>
> --------- from JS1.3 documentation.
>
>
> Also I like "watch" method alot. but it is Netscape
only :-/
> It allows you to get rid of methods..
> Just mylayer.x=12 would move the layer.
>
>
> And... why you need to create object , based
> on something but not to extend the one you have?!
>
> ps. In the past you have had ability to make errors...
> Now ! with C++ - you could inherit them! :)
>
> Malx
>
> > Hmm.. but how about wanting widgets to fully extend
> > Dynlayer.. i.e. supporting exactly the same
initialization
> > as Dynlayer has without writing the code over again.
> >
> > Do you not think that a construct() method would be a
good
> > idea? As per my previous posts...
> > It wouldn't alter anything in essence.. nor complicate
> > anything. Just how the Dynlayer is initialized,
allowing
> > widgets to (easily) do a general DynLayer
initialization.
> > Apart from widget specific initialization...
> >
> > / Bart
> >
> > > I absolutely agree. Things are already complicated
> > enought and I don't want to add one single line of code
> > there.
> > >
> > >
> > > Dan Steinman wrote:
> > >
> > > > It is both mine and Pascal's opinion that no
special
> > inheritance system is needed for DynAPI. Just make
careful
> > attention, and structure using basic prototypes and you
can
> > do everything (except doing multiple inheritance).
Don't
> > overwrite variables, and you don't even necessarily
need to
> > overwrite methods, and everything works perfectly. The
> > most simplistic solution is often the best, and I
believe
> > that is the case here.
> > > >
> > > > Dan
> > > >
> > >
> > > _______________________________________________
> > > 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
> >
>
>
>
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
> / Word is not a color, but a
picture. \
> _ _ / To understand it you must draw it by
yourself. ___ \ _ _
> \ ------- __ -- |^ malvin@cad.ntu-
kpi.kiev.ua /
> \ --- --- | http://cad.ntu-
kpi.kiev.ua/~malvin/
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
|
|
From: Barre B. <ba...@ho...> - 2000-11-30 15:18:55
|
Another thing... neither the function.call() nor the
function.apply() method work under IE4+.
Unfortunately.
/ Bart
> On Wed, 29 Nov 2000, Barre Bizon wrote:
>
>
> I thinks you have learned too much of OOP languages
like
> Java C++ etc.
> JavaScript is not OOP - it is Object Language - not
> just merely OO :)
>
> I would recomend to look deeper into JavaScript.
> If i'm not mistaken - DunAPI never uses such thing
as "with"
>
> Also ... If only Netscape4 would be standart....
and JavaScrip1.3
> with it:
> ----------------------
> You can use call to chain constructors for an object,
> similar to Java. In the following example, the constructor
> for the product object is defined with two parameters,
> name and value. Another object, prod_dept, initializes its
> unique variable (dept) and calls the constructor for
> product in its constructor to initialize the other
variables.
>
> function product(name, value){
> this.name = name;
> if(value > 1000)
> this.value = 999;
> else
> this.value = value;
> }
>
> function prod_dept(name, value, dept){
> this.dept = dept;
> product.call(this, name, value);
> }
>
> prod_dept.prototype = new product();
>
> // since 5 is less than 100 value is set
> cheese = new prod_dept("feta", 5, "food");
>
> // since 5000 is above 1000, value will be 999
> car = new prod_dept("honda", 5000, "auto");
>
> --------- from JS1.3 documentation.
>
>
> Also I like "watch" method alot. but it is Netscape
only :-/
> It allows you to get rid of methods..
> Just mylayer.x=12 would move the layer.
>
>
> And... why you need to create object , based
> on something but not to extend the one you have?!
>
> ps. In the past you have had ability to make errors...
> Now ! with C++ - you could inherit them! :)
>
> Malx
>
> > Hmm.. but how about wanting widgets to fully extend
> > Dynlayer.. i.e. supporting exactly the same
initialization
> > as Dynlayer has without writing the code over again.
> >
> > Do you not think that a construct() method would be a
good
> > idea? As per my previous posts...
> > It wouldn't alter anything in essence.. nor complicate
> > anything. Just how the Dynlayer is initialized,
allowing
> > widgets to (easily) do a general DynLayer
initialization.
> > Apart from widget specific initialization...
> >
> > / Bart
> >
> > > I absolutely agree. Things are already complicated
> > enought and I don't want to add one single line of code
> > there.
> > >
> > >
> > > Dan Steinman wrote:
> > >
> > > > It is both mine and Pascal's opinion that no
special
> > inheritance system is needed for DynAPI. Just make
careful
> > attention, and structure using basic prototypes and you
can
> > do everything (except doing multiple inheritance).
Don't
> > overwrite variables, and you don't even necessarily
need to
> > overwrite methods, and everything works perfectly. The
> > most simplistic solution is often the best, and I
believe
> > that is the case here.
> > > >
> > > > Dan
> > > >
> > >
> > > _______________________________________________
> > > 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
> >
>
>
>
^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^~^
> / Word is not a color, but a
picture. \
> _ _ / To understand it you must draw it by
yourself. ___ \ _ _
> \ ------- __ -- |^ malvin@cad.ntu-
kpi.kiev.ua /
> \ --- --- | http://cad.ntu-
kpi.kiev.ua/~malvin/
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/mailman/listinfo/dynapi-dev
|
|
From: Alexey M. <ma...@ca...> - 2000-11-30 16:43:17
|
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 |
|
From: <abe...@al...> - 2000-11-30 18:58:03
|
> 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 |
|
From: Brandon M. <bnd...@ho...> - 2000-11-30 19:56:42
|
I don't know how splitting the API came out of object inheritance. Which are 2 totally sperate issues... but here goes my wordy opinion... 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. 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. The other drawback, from what I see, is that there would be a need to maintain a list of files for each browser type. Or, what files are common, and what files are specific for each browser. I have solved this problem, but the requirement for maintaing a list of files for each category, or browser, is still a necessity. That, although, gives a benifit to the API. Now, we sould no-longer have to specify the fill path of the script file. Just the name of the script would include all necessary files. If, for example, the DynLayer object where to be split, there coujld be 5 possible files generated. 1: The common parts to all browsers. 2: IE4 3: IE5 4: NS4 5: DOM compliant. The common part would obviously be the larger, as there is much that is common to both browsers. But if things are done right, the result of the seperation, when both common and the specific browser version is combined, would be less than the original DynLayer file was before the split. This I have proved with the version I have enhanced. It becomes quite simple to maintain after a list of standards of what the API is actually suppoed to provide is made available. It also allows developers who like the API, and wish to target a specific browser audience with enhanced features not provided by other brosers, to develop highly advcanced sites using the API together with their own proprietary additions. These additions are made easier due to the "pluggable" nature of the resulting split. Supporting browser specific implementation of features available in both browsers also becomes easier. Things such as audio support, a file that glues java objects to javascript events, and vice versa. These features become trivial when this path is followed. I'm not staying it will be easy. But I believe that the benifits would outway the work it would entail. ----- 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 |
|
From: Doug M. <do...@cr...> - 2000-11-30 22:14:53
|
How about posting your efforts.. an increase in speed and stability is something I think we could all use.. (well, I could anyways..) ----- Original Message ----- From: "Brandon Myers" <bnd...@ho...> To: <dyn...@li...> Sent: Thursday, November 30, 2000 11:58 AM Subject: [Dynapi-Dev] Splitting the API? > I don't know how splitting the API came out of object inheritance. Which are > 2 totally sperate issues... but here goes my wordy opinion... > > 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. > > 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. > > The other drawback, from what I see, is that there would be a need to > maintain a list of files for each browser type. Or, what files are common, > and what files are specific for each browser. I have solved this problem, > but the requirement for maintaing a list of files for each category, or > browser, is still a necessity. That, although, gives a benifit to the API. > Now, we sould no-longer have to specify the fill path of the script file. > Just the name of the script would include all necessary files. If, for > example, the DynLayer object where to be split, there coujld be 5 possible > files generated. > 1: The common parts to all browsers. > 2: IE4 > 3: IE5 > 4: NS4 > 5: DOM compliant. > > The common part would obviously be the larger, as there is much that is > common to both browsers. But if things are done right, the result of the > seperation, when both common and the specific browser version is combined, > would be less than the original DynLayer file was before the split. This I > have proved with the version I have enhanced. > > It becomes quite simple to maintain after a list of standards of what the > API is actually suppoed to provide is made available. It also allows > developers who like the API, and wish to target a specific browser audience > with enhanced features not provided by other brosers, to develop highly > advcanced sites using the API together with their own proprietary additions. > These additions are made easier due to the "pluggable" nature of the > resulting split. > > Supporting browser specific implementation of features available in both > browsers also becomes easier. Things such as audio support, a file that > glues java objects to javascript events, and vice versa. These features > become trivial when this path is followed. > > I'm not staying it will be easy. But I believe that the benifits would > outway the work it would entail. > ----- 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 > > > > |
|
From: Brandon M. <bnd...@ho...> - 2000-12-05 04:21:28
|
I cannot do that yet. I can, though, assist in guiding you in whatever efforts you may endevor. ----- Original Message ----- From: "Doug Melvin" <do...@cr...> To: <dyn...@li...> Sent: Thursday, November 30, 2000 8:13 PM Subject: Re: [Dynapi-Dev] Splitting the API? > How about posting your efforts.. an increase in speed and stability is > something I think we could all use.. (well, I could anyways..) > > > ----- Original Message ----- > From: "Brandon Myers" <bnd...@ho...> > To: <dyn...@li...> > Sent: Thursday, November 30, 2000 11:58 AM > Subject: [Dynapi-Dev] Splitting the API? > > > > I don't know how splitting the API came out of object inheritance. Which > are > > 2 totally sperate issues... but here goes my wordy opinion... > > > > 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. > > > > 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. > > > > The other drawback, from what I see, is that there would be a need to > > maintain a list of files for each browser type. Or, what files are common, > > and what files are specific for each browser. I have solved this problem, > > but the requirement for maintaing a list of files for each category, or > > browser, is still a necessity. That, although, gives a benifit to the API. > > Now, we sould no-longer have to specify the fill path of the script file. > > Just the name of the script would include all necessary files. If, for > > example, the DynLayer object where to be split, there coujld be 5 possible > > files generated. > > 1: The common parts to all browsers. > > 2: IE4 > > 3: IE5 > > 4: NS4 > > 5: DOM compliant. > > > > The common part would obviously be the larger, as there is much that is > > common to both browsers. But if things are done right, the result of the > > seperation, when both common and the specific browser version is combined, > > would be less than the original DynLayer file was before the split. This I > > have proved with the version I have enhanced. > > > > It becomes quite simple to maintain after a list of standards of what the > > API is actually suppoed to provide is made available. It also allows > > developers who like the API, and wish to target a specific browser > audience > > with enhanced features not provided by other brosers, to develop highly > > advcanced sites using the API together with their own proprietary > additions. > > These additions are made easier due to the "pluggable" nature of the > > resulting split. > > > > Supporting browser specific implementation of features available in both > > browsers also becomes easier. Things such as audio support, a file that > > glues java objects to javascript events, and vice versa. These features > > become trivial when this path is followed. > > > > I'm not staying it will be easy. But I believe that the benifits would > > outway the work it would entail. > > ----- 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 |
|
From: Eytan H. <ey...@tr...> - 2000-12-05 09:42:40
|
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
|
|
From: Alexey M. <ma...@ca...> - 2000-12-01 09:07:13
|
> Doing this means an extra work in trying to maintain standardized all the Yes. One of the solution is to make test-examples. So you must run this tests every time (automatically , like Pascals test wizard). But it is really a problem. > something to an API we must add the same functionality to all other; and not But. We could separate wich part is independent (DynLayer API) and which is dependent (the dynlayer.js). So widgets have no dependent parts at all. > 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. Of course :))) Malx -- There is no thing in the world, which is more powerfull, than default |
|
From: Alexey M. <ma...@ca...> - 2000-11-30 16:37:41
|
On Thu, 30 Nov 2000, Barre Bizon wrote: > didn't read my previous posts... sorry , I'm new here. Just look in some archive posts... > Object orientation exists for a purpose, and no, Javascript > isn't "true" OOP, but close enough to be able to use the I am telling you that JavaScript is no _OOP_ it is _OP_. It is not "oriented". It is true Object language. Ok - It is IMHO of course :))) But repaeting - JS is much more powerfull then Java/C++ OOP. So - I am very upset you trying to limit it to OOP you know how to work with instead of learning JS!!! :-/ > I thought creating a constructor method was a clean and > easy way of doing "extended" functions initialization. As for OOP - the only way. As for JavaScript - the worst way. Yes it is included in JS1.3 for thouse who likes "Java" , but.... > But sure, assigning DynLayer as a method and then calling > it works too... :) So the question is - which way is better and why :))) Malx |
|
From: Eytan H. <ey...@tr...> - 2000-12-03 09:37:08
|
I too have found the code very complicated. For that reason I wanted to simplfy it and make it even more OOP. To do that I wanted to create a simple type MyObject. Which would be an empty object that all other non-visual widgets inherit from. And then create one widget Component which would inherit from object. Component would have a DynLayer property and on it all the visual parts would be drawn. The only problem is I keep trying to do inheritence in different wayys and it always fails. How do you do simple JS inheritence. Eytan |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X