dynapi-dev — List related to the current DynAPI Core development

[Dynapi-Dev] Error in Netscape 4

[Leon R. <leo...@he...>]

Recently i've been testing Dynapi on my computer and have noticed that i =
get errorrs in netscape 4.04 using  mouseevents. (Even in the latest =
versions of Dynapi.)
I found that placing a default return-false in a subroutine would easily =
fix this.
Could anybody comfirm my findings?

Thanks.

Re: RE: [Dynapi-Dev] Counting so far

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

well.. I know it can work one way...
I'm just now testing my SuperClass, and putting existing 
functionality from the DynAPI is not too hard.... 
The other way around would be worse though.. but it is 
possible.

> Just throwing in two cents again...
> 
> Rather than having the effort disintegrate into camps, 
perhaps the object
> model folks could propose an object model that 
encapsulates the current
> model?  In this way, the object model folks could proceed 
with creating a
> new object framework, and the "old model" people could 
proceed with
> cross-platform/browser compatibilty fixes at the method 
level.  As the new
> object model came online, you wouldn't have to throw out 
all the old code -
> or at least not as much.
> 
> As an OO fan myself, Javascript's prototyping methods are 
arcane to me.  So
> my question is OO-advocates, is there a way to make a 
generic "OO" wrapper
> for the existing prototype model?  In other words, 
encapsulate the existing
> model, then retool and optimize one object at a time to 
take advantage of
> the new model while maintaining the functional code base 
of the existing
> model.  Can the process also work in reverse?  Calls to 
the prototyped
> instances would map back to the new objects?  Am I in the 
ozone here?  (I
> may well be, as I admit Javascript is not my language of 
choice.)
> 
> My intention is not to start a flaming fest or have 
everyone tell why what
> I'm asking can't be done.  I'm only asking if it CAN be 
done.
> 
> My real intention is to see the effort move forward and 
encourage this
> entourage of clearly gifted programmers to find a common 
vision so that
> everyone's efforts can go into the same product and same 
results.
> 
> Hope these thoughts help.
> 
> By the way, I'm not opposed to "real" object orientation 
at all.  I just
> want to be able to point my students to an API that 
legitizes the concept of
> truly interactive HTML.  I'm tired of students turning to 
Flash to get
> things moving - dHTML is supposed to be able to do that, 
and dynAPI seems
> the likeliest, best solution.
> 
> Good luck in your debate.  I am eager to see what 
transpires.  Long term the
> object model seems like a good idea - is their a 
collective, collaborative
> best solution that will satisfy everyone in the near term?
> 
> Dave Gerding
> Columbia College Chicago
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: dyn...@li...
> [mailto:dyn...@li...]On Behalf 
Of Cameron Hart
> Sent: Tuesday, January 30, 2001 10:18 AM
> To: dyn...@li...
> Subject: RE: [Dynapi-Dev] Counting so far
> 
> 
> this seems quite ridiculous, but for what it's worth add 
me to the against.
> i'd rather see x-browser bugs fixed first.
> 
> i really doubt that the current object model is what is 
causing instability,
> if you can actually prove that perhaps i'll change sides.
> 
> > -----Original Message-----
> > From: dyn...@li...
> > [mailto:dyn...@li...]On 
Behalf Of Eytan
> > Heidingsfeld
> > Sent: 30 January 2001 16:13
> > To: Dynapi-Dev
> > Subject: [Dynapi-Dev] Counting so far
> >
> >
> > For:
> > Me
> > Dann
> > Barre
> > Doug
> > Gortsilas
> > Against:
> > Pascal
> >
> > I can't decide what Jordi is. And if anyone wants to 
move to the
> > against or
> > be added to any of the 2 let me know
> >
> > 8an
> >
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> 
> 
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> 
> 
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> 

RE: [Dynapi-Dev] Counting so far

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

Voice of reason reaching us.

thanks.

Pascal Bestebroer
pa...@dy...
http://www.dynamic-core.net

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Richard Bennett
> Verzonden: dinsdag 30 januari 2001 18:36
> Aan: dyn...@li...
> Onderwerp: Re: [Dynapi-Dev] Counting so far
>
>
> Is this a case of win or loose?
> Eytan against Pascal??
>
> We've had all the theoretical explanations, every one has been able to
> demonstrate their in-depth knowledge and their preference regarding object
> model, a discussion is great, but lets get back to work now! Instead of
> breaking up the group with petty rivalries.
>
> There are different things to be done, and several groups of
> people showing
> interest in them:
>
> * NS6 debugging, starting at the core of the API, later the widgets.
> several people showed interest here.
>
> * Mac debugging, now we have some Mac users, their efforts should not be
> shunned.
>
> * Memory management, coupled with the basic structure of the API, OOP etc.
> This is what Doug and Eytan showed a lot of interest in, why not set up a
> test case, of a very basic API, so stability and memory use can be tested.
> If there is an improvement, the benefits should be clear. Also this would
> give people like me a chance to see what you are actually talking about, a
> lot of technical abbreviations make the whole thing a bit confusing.
>
> * User interfaces, several projects going on here, either web
> based or not,
> Dan's Java Builder, or Henrik Våglins DynBuilder.
> These projects might or might not take of, we won't know if we don't try.
>
> * Documentation, Robert and Pascal have put in a great effort
> here, keep up
> the good work.
>
> * Designer access, here I mean access for the normal javascript coder, who
> wants to check out the DynAPI, without necessarily knowing the code inside
> out.
> That's the part I'm working on as much as I can, supplying examples, and
> answering user questions as I can. These people will become our future
> user-base, and the step to DynAPI use should be as low as possible.
> See what happened to PHP in 5 years time, after year one they
> were where we
> are now.
>
> * Widget development, if the widget model has stabilized, it
> would be great
> to see some functional, error free, and logical widgets, we need window
> management, timeline, etc + a whole bank of pathanim add-ons to
> do all kinds
> of animation. There's a lot out there already which I'm trying to group as
> it is.
>
> * Group moderation, this is what Dann Pascal and Robert do (among others)
> and is basically taking the decisions.
> Someone has to do that, otherwise everybody would be overwriting
> each others
> code in CVS 'cause they didn't like the "style".
> There are a few things that could be improved here to, as I feel a lot of
> knowledge gets lost as it's simply ignored, but it should come from two
> sides, submitters should be able to accept at face value that
> their "great"
> fix, wasn't accepted, but the moderator should at least acknowledge having
> seen the submission, if not giving a reason for every line of code they
> reject/accept.
> Also, we should try to restrict any bug reports to something which can be
> reproduced, I mean, if you say, mouse events don't work in a nested layer
> containing an image, while the parent is moving across the screen, you
> expect the moderator to spend time reproducing that specific
> example. If it
> helps I'll open a public ftp account, with the latest snapshot
> preinstalled,
> so bug examples can be uploaded, and are all tested against the latest
> snapshot.
>
> Anyway, I think we have to much work to do, to waste time counting...
>
> Cheers,
> Richard Bennett
>
> ma...@ri...
> www.richardinfo.com
> (Everything running on, and ported to the 19/12/2000 snapshot of DynAPI2)

Re: [Dynapi-Dev] ns6 w/h and browser advocacy

[Dann <da...@to...>]

Hi,

Thanks for the insight ! I have had so many timing related incidents that I was
beginning to suspect multi-threading problems, but I must admit that maybe it
was my imagination running wild there...

Especially with cross-window scripting I started to develop a programming
technique which uses a lot of callbacks to signal the end of actions, to trigger
consecutive actions, instead of relying on the flow of javascript itself, by
doing so, I could get the workings much more stable... anyway, I'll pay some
attention with respect to this issue in the future to see if I can understand it
better with your feedback in mind !

CU,
 Dann

[Dynapi-Dev] A little suggest

[Josep M. <jo...@do...>]

Only one little suggest:

what do you think about changing line #17 of "api.dynlayer.js",
allowing boolean values in the visibility parameter of the dynlayer 
constructor;

         actual line #17:
                 this.visible=a[6]!='hidden';
         out suggest:
                 this.visible = !(a[6] == false || a[6] == 'hidden')

this is compatible with 'visible','hidden', true and false values.


-----------------------------
Josep Maria Soler
jo...@jo...
# ICQ: 7157132

RE: Re[2]: [Dynapi-Dev] [Bug #130357] small typo in list.js

[Jay C. <jch...@ou...>]

IMHO: Using side effects to implement the core logic challenges the
readability of the code. (The present example has provided evidence of
that.) Yet, readability is of primary importance in a large group effort.
The opinion of many is that one should choose readability over
economy/cleverness/performance unless the specific tradeoffs in the case at
hand are compelling. One of those "many" is quoted below.

"The main idea is to regard a program as a communication to human beings
rather than as a set of instructions to a computer. "
- Donald Knuth (http://www-cs-faculty.stanford.edu/~knuth/cweb.html)


-J


-----Original Message-----
From: Doug Melvin [mailto:do...@cr...]
Sent: Tuesday, January 30, 2001 10:51 AM
To: dyn...@li...
Subject: Re: Re[2]: [Dynapi-Dev] [Bug #130357] small typo in list.js


I've just had that conversation with a co-worker.
Can anyone tell me why this is not proper?
The best my co-worker could come up with was 'it doesn't feel right'
....


> Either way, we shouldn't be using if (this.selected=b).  That's not
> very proper.
>
> --
> // Robert Rainwater
>
> On 1/30/2001, 8:47:21 AM EST, Raides wrote about "[Dynapi-Dev] [Bug
#130357] small typo in list.js":
>
> > Michael Pemberton wrote:
> >>
> >> please put the "typo" back.  What is does is set the value of
this.selected to
> >> b and then evaluates the returned value (the new value of
this.selected).  It
> >> is needed to change the selected state of the item.
> >>
>
> >> > if (this.selected=b) {
> >> >
> >> > should be
> >> >
> >> > if (this.selected==b) {
> >> >
> >> > right?
>
> >         I will answer both for NS6's sake:
>
> >         This is indeed a bug in NS6 and prevents normal execution of the
rest of the
> > code. It should read:
>
> > this.selected=b
> > if(this.selected){
> > ...
> > }else{
> > ...
> > }
>
> >         I have done this kind of changes all around my local dynapi
distribution and
> > those pesky errors that NS6 throwed at me and their side effect of code
not
> > executing in that function anymore disappeared. Other special
perso-NS6-ality of
> > this browser is that if you want to dynamically resize an image, you
have to do
> > it TWICE, using a setTimeout to delay appropiately (30 millisecs are
enough) the
> > effect. The code I use to test NS6 comes with this mail. It is spanish
code and
> > HTML, poorly documented but that can be executed in IE4.0 and above with
no
> > changes at all and some errors due to their different underlying model.
>
> >         Raides J.
>
>
> ----------------------
> DynAPI Snapshots: http://dynapi.sourceforge.net/snapshot/
> DynAPI Homepage: http://dynapi.sourceforge.net/
>
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev


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

Re: [Dynapi-Dev] Counting so far

[Richard B. <ma...@ri...>]

Is this a case of win or loose?
Eytan against Pascal??

We've had all the theoretical explanations, every one has been able to
demonstrate their in-depth knowledge and their preference regarding object
model, a discussion is great, but lets get back to work now! Instead of
breaking up the group with petty rivalries.

There are different things to be done, and several groups of people showing
interest in them:

* NS6 debugging, starting at the core of the API, later the widgets.
several people showed interest here.

* Mac debugging, now we have some Mac users, their efforts should not be
shunned.

* Memory management, coupled with the basic structure of the API, OOP etc.
This is what Doug and Eytan showed a lot of interest in, why not set up a
test case, of a very basic API, so stability and memory use can be tested.
If there is an improvement, the benefits should be clear. Also this would
give people like me a chance to see what you are actually talking about, a
lot of technical abbreviations make the whole thing a bit confusing.

* User interfaces, several projects going on here, either web based or not,
Dan's Java Builder, or Henrik Våglins DynBuilder.
These projects might or might not take of, we won't know if we don't try.

* Documentation, Robert and Pascal have put in a great effort here, keep up
the good work.

* Designer access, here I mean access for the normal javascript coder, who
wants to check out the DynAPI, without necessarily knowing the code inside
out.
That's the part I'm working on as much as I can, supplying examples, and
answering user questions as I can. These people will become our future
user-base, and the step to DynAPI use should be as low as possible.
See what happened to PHP in 5 years time, after year one they were where we
are now.

* Widget development, if the widget model has stabilized, it would be great
to see some functional, error free, and logical widgets, we need window
management, timeline, etc + a whole bank of pathanim add-ons to do all kinds
of animation. There's a lot out there already which I'm trying to group as
it is.

* Group moderation, this is what Dann Pascal and Robert do (among others)
and is basically taking the decisions.
Someone has to do that, otherwise everybody would be overwriting each others
code in CVS 'cause they didn't like the "style".
There are a few things that could be improved here to, as I feel a lot of
knowledge gets lost as it's simply ignored, but it should come from two
sides, submitters should be able to accept at face value that their "great"
fix, wasn't accepted, but the moderator should at least acknowledge having
seen the submission, if not giving a reason for every line of code they
reject/accept.
Also, we should try to restrict any bug reports to something which can be
reproduced, I mean, if you say, mouse events don't work in a nested layer
containing an image, while the parent is moving across the screen, you
expect the moderator to spend time reproducing that specific example. If it
helps I'll open a public ftp account, with the latest snapshot preinstalled,
so bug examples can be uploaded, and are all tested against the latest
snapshot.

Anyway, I think we have to much work to do, to waste time counting...

Cheers,
Richard Bennett

ma...@ri...
www.richardinfo.com
(Everything running on, and ported to the 19/12/2000 snapshot of DynAPI2)

----- Original Message -----
From: "Eytan Heidingsfeld" <ey...@tr...>
To: "Dynapi-Dev" <dyn...@li...>
Sent: Tuesday, January 30, 2001 5:12 PM
Subject: [Dynapi-Dev] Counting so far


> For:
> Me
> Dann
> Barre
> Doug
> Gortsilas
> Against:
> Pascal
>
> I can't decide what Jordi is. And if anyone wants to move to the against
or
> be added to any of the 2 let me know
>
> 8an
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> ____________________________________________________________
> Get your free domain name and domain-based e-mail from
> Namezero.com. New!  Namezero Plus domains now available.
> Find out more at: http://www.namezero.com
>

RE: [Dynapi-Dev] Next Generation

[Michael E. <Mic...@il...>]

Just to further clarify... Doug and Raymond's statement are correct. The
www.statmarket.com is much broader based... they collect the stats from
anyone using 'HitBox'. There daily sample is supposed to be based on around
50,000,000 hits. Unfortunately the free report uses old sample data, and the
subscriptions/custom demographic reports aren't cheap (about $950/report, I
don't even know what they charge for a full subscription). 

This is a list of the browsers/platforms that most of our domestic customers
need supported (this may differ for your clients needs. Please feel free to
flame me on this, I don't pretend to have the answers... just a starting
point):

Windows:

IE 4.1 (SP1)
IE 5.0
IE 5.5

NS 4.08
NS 4.76
NS 6.0

Mac:

IE 5.0 (Ugly, I know)
NS 4.08
NS 6.0

Maybe it would make sense for someone in charge of the site to see about a
ASP/strategic alliance (link) with an organization that provides good
statistics. It would certianly help educate us, and lend an air of
credability to our cross platform/cross browser code premise. Then again,
setting up these relationships is usually a pain in the ass.

Mike


-----Original Message-----
From: Doug Melvin [mailto:do...@cr...]
Sent: Tuesday, January 30, 2001 11:23
To: dyn...@li...
Subject: Re: [Dynapi-Dev] Next Generation


that's not 'in the world'
All stats on that site are from visiter to that site, and
represent ONLY visiters to that site.
Not the world.

----- Original Message -----
From: "Cameron Hart" <ca...@bi...>
To: <dyn...@li...>
Sent: Tuesday, January 30, 2001 1:59 AM
Subject: RE: [Dynapi-Dev] Next Generation


> It is quite frightening to know that 5 people in the world are using MSIE
> 1.x ;-)
>
> I mean, has anyone even seen IE 1???
>
> > -----Original Message-----
> > From: dyn...@li...
> > [mailto:dyn...@li...]On Behalf Of Raymond
> > Smith
> > Sent: 30 January 2001 05:50
> > To: dyn...@li...
> > Subject: Re: [Dynapi-Dev] Next Generation
> >
> >
> > Carefull if your using the "sample stats" from there.  They date back to
> > 1999 and reflect an older reality.  Most recent browser stats I have
found
> > are at www.thecounter.com.  From October 2000.
> >
> > ----- Original Message -----
> > From: "Michael Ellis" <Mic...@il...>
> > To: <dyn...@li...>
> > Sent: Monday, January 29, 2001 2:53 PM
> > Subject: RE: [Dynapi-Dev] Next Generation
> >
> >
> > > Amen brother!
> > >
> > > No argument here... Although we can be educated to, we cannot expect
nor
> > > demand which platform/browser our end-users choose. If our
> > software is to
> > be
> > > taken seriously, and serve a broad community we must be reasonable
about
> > > which platforms/browsers we support. If you think I'm full of it,
check
> > the
> > > browser/platform statistics at www.statmarket.com (don't rely on
> > statistics
> > > gathered by developer forums, they attract developers like us and are
> > > typically not representative of our products end-users).
> > >
> > > Mike Ellis
> > >
> > > -----Original Message-----
> > > From: .:: OCB ::. [mailto:oc...@ho...]
> > > Sent: Monday, January 29, 2001 10:15
> > > To: dyn...@li...
> > > Subject: Re: [Dynapi-Dev] Next Generation
> > >
> > >
> > > Next generation ???
> > >
> > > Would it not be a good idea to get the DynApi2 working in all browsers
> > > (basic methods, moveTo, event handlers etc; not wigits, IMO they take
a
> > > backseat to basic functionality) before even discussing another
> > generation
> > > of the API.
> > >
> > > I haven't contributed anything in months (which is beyond my control)
so
> > > feel quite apprehensive about posting this but again, IMO, it
> > makes common
> > > sense to get the basic's of this project crossbrowser (NN6 included)
and
> > bug
> > >
> > > free before launching into another generation of the API.
> > >
> > > Flame away !!!!
> > >
> > >
> > > >From: "Jared Nuzzolillo" <ja...@aa...>
> > > >Reply-To: dyn...@li...
> > > >To: <dyn...@li...>
> > > >Subject: [Dynapi-Dev] Next Generation
> > > >Date: Mon, 29 Jan 2001 11:46:41 -0500
> > > >
> > > >I have a feeling that certain people are wanting to implement
> > class-like
> > > >inheritance because it is more familiar/comfortable to them.
> > > >
> > > >I strongly agree with Pascal. Prototype-based inheritance works
> > > >beautifully,
> > > >and is native to javascript, so why would we want to enforce a
> > different
> > > >type of inheritance to use the API? Most dynapi users will at least
be
> > > >familiar with javascript, and may be expecting Prototype-like
behavior.
> > > >
> > > >It's kind of like creating a number class instead of using built in
> > number
> > > >objects and primitive types. It's pointeless.
> > > >
> > > >As far as the class/prototype argument as to what Netscape says, the
> > first
> > > >line of this article:
> > > >
> > >
> > >http://developer.netscape.com/docs/manuals/communicator/jsobj/con
> tents.htm
> > >
> > >reads as follows:
> > >
> > >"JavaScript is an object-oriented language based on prototypes, rather
> > >than,
> > >as is common, being class-based."
> > >
> > >-jaredn
> > >
> > >
> > >
> > >
> > >_______________________________________________
> > >Dynapi-Dev mailing list
> > >Dyn...@li...
> > >http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> >
> >
_________________________________________________________________________
> > Get Your Private, Free E-mail from MSN Hotmail at
http://www.hotmail.com.
> >
> >
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> >
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev

RE: [Dynapi-Dev] ns6 w/h and browser advocacy

[Jay C. <jch...@ou...>]

It has been my observation that (per window) the JavaScript runs on a single
thread. This thread also handles all of the UI events. Therefore, the two
image event handlers you mention will execute atomically. On the other hand,
using a setTimeout("foo()", 0) allows the current (and possibly other) event
to complete before foo executes. This changes the order of execution and
most importantly the state in which foo executes.

Someone please correct me if I am wrong.

-J

-----Original Message-----
From: Dann [mailto:da...@to...]
Sent: Tuesday, January 30, 2001 7:45 AM
To: dyn...@li...
Subject: Re: [Dynapi-Dev] ns6 w/h and browser advocacy


Hi,

Has anybody ever done some testing or wondered about the safety nature of
concurrent execution of code in JS ? It struck me that this timeout gimmick
has
been discovered over and over again, to apparantly fix a recurring issue. It
was
already pointed out by Cameron, that if you could fix this kind of behaviour
by
using a Timeout, you probably stumbled on a browser bug... usually, in my
years
of fooling around with JS, a Timeout could even prevent a browser from
crashing
entirely.

What exactly happens if you would hook load event handlers to to two images,
who
would fire simultaneously and call the same function, to change some common
global variables ?

CU,
 Dann

SV: Re[2]: [Dynapi-Dev] [Bug #130357] small typo in list.js

[<th...@je...>]

----- Original Message -----=20
From: Doug Melvin <do...@cr...>
To: <dyn...@li...>
Sent: Tuesday, January 30, 2001 19:50
Subject: Re: Re[2]: [Dynapi-Dev] [Bug #130357] small typo in list.js


> I've just had that conversation with a co-worker.
> Can anyone tell me why this is not proper?
> The best my co-worker could come up with was 'it doesn't feel right'
> ....
>=20
>=20
> > Either way, we shouldn't be using if (this.selected=3Db).  That's =
not
> > very proper.
> >
> > --
> > // Robert Rainwater
> >
> > On 1/30/2001, 8:47:21 AM EST, Raides wrote about "[Dynapi-Dev] [Bug
> #130357] small typo in list.js":
> >
> > > Michael Pemberton wrote:
> > >>
> > >> please put the "typo" back.  What is does is set the value of
> this.selected to
> > >> b and then evaluates the returned value (the new value of
> this.selected).  It
> > >> is needed to change the selected state of the item.
> > >>
> >
> > >> > if (this.selected=3Db) {
> > >> >
> > >> > should be
> > >> >
> > >> > if (this.selected=3D=3Db) {
> > >> >
> > >> > right?
> >
> > >         I will answer both for NS6's sake:
> >
> > >         This is indeed a bug in NS6 and prevents normal execution =
of the
> rest of the
> > > code. It should read:
> >
> > > this.selected=3Db
> > > if(this.selected){
> > > ...
> > > }else{
> > > ...
> > > }
> >
> > >         I have done this kind of changes all around my local =
dynapi
> distribution and
> > > those pesky errors that NS6 throwed at me and their side effect of =
code
> not
> > > executing in that function anymore disappeared. Other special
> perso-NS6-ality of
> > > this browser is that if you want to dynamically resize an image, =
you
> have to do
> > > it TWICE, using a setTimeout to delay appropiately (30 millisecs =
are
> enough) the
> > > effect. The code I use to test NS6 comes with this mail. It is =
spanish
> code and
> > > HTML, poorly documented but that can be executed in IE4.0 and =
above with
> no
> > > changes at all and some errors due to their different underlying =
model.
> >
> > >         Raides J.
> >
> >
> > ----------------------
> > DynAPI Snapshots: http://dynapi.sourceforge.net/snapshot/
> > DynAPI Homepage: http://dynapi.sourceforge.net/
> >
> >
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>=20
>=20
>=20
>=20
>=20

RE: Re[2]: [Dynapi-Dev] Counting so far

[Nuno F. <nun...@wi...>]

I agree completely.

Besides, Pascal himself has a different distribution of the
DynAPI, why don't you guys do the same? That way you can try out
your ideas and concepts at your leisure.

NunoF

-----Original Message-----
From: dyn...@li...
[mailto:dyn...@li...]On Behalf Of Robert
Rainwater
Sent: terca-feira, 30 de Janeiro de 2001 16:33
To: DynAPI Development List
Subject: Re[2]: [Dynapi-Dev] Counting so far



You can count all you want, but that serves no useful purpose to this
project other than to detract from the DynAPI.

If you want to build your own library, go ahead.  But Dan created the
DynAPI 2 and we are here to help make the DynAPI 2 a viable api.  If
you don't like it, don't use it.

-- 
// Robert Rainwater

RE: [Dynapi-Dev] Counting so far

[David G. @ C. <dge...@po...>]

Just throwing in two cents again...

Rather than having the effort disintegrate into camps, perhaps the object
model folks could propose an object model that encapsulates the current
model?  In this way, the object model folks could proceed with creating a
new object framework, and the "old model" people could proceed with
cross-platform/browser compatibilty fixes at the method level.  As the new
object model came online, you wouldn't have to throw out all the old code -
or at least not as much.

As an OO fan myself, Javascript's prototyping methods are arcane to me.  So
my question is OO-advocates, is there a way to make a generic "OO" wrapper
for the existing prototype model?  In other words, encapsulate the existing
model, then retool and optimize one object at a time to take advantage of
the new model while maintaining the functional code base of the existing
model.  Can the process also work in reverse?  Calls to the prototyped
instances would map back to the new objects?  Am I in the ozone here?  (I
may well be, as I admit Javascript is not my language of choice.)

My intention is not to start a flaming fest or have everyone tell why what
I'm asking can't be done.  I'm only asking if it CAN be done.

My real intention is to see the effort move forward and encourage this
entourage of clearly gifted programmers to find a common vision so that
everyone's efforts can go into the same product and same results.

Hope these thoughts help.

By the way, I'm not opposed to "real" object orientation at all.  I just
want to be able to point my students to an API that legitizes the concept of
truly interactive HTML.  I'm tired of students turning to Flash to get
things moving - dHTML is supposed to be able to do that, and dynAPI seems
the likeliest, best solution.

Good luck in your debate.  I am eager to see what transpires.  Long term the
object model seems like a good idea - is their a collective, collaborative
best solution that will satisfy everyone in the near term?

Dave Gerding
Columbia College Chicago









-----Original Message-----
From: dyn...@li...
[mailto:dyn...@li...]On Behalf Of Cameron Hart
Sent: Tuesday, January 30, 2001 10:18 AM
To: dyn...@li...
Subject: RE: [Dynapi-Dev] Counting so far


this seems quite ridiculous, but for what it's worth add me to the against.
i'd rather see x-browser bugs fixed first.

i really doubt that the current object model is what is causing instability,
if you can actually prove that perhaps i'll change sides.

> -----Original Message-----
> From: dyn...@li...
> [mailto:dyn...@li...]On Behalf Of Eytan
> Heidingsfeld
> Sent: 30 January 2001 16:13
> To: Dynapi-Dev
> Subject: [Dynapi-Dev] Counting so far
>
>
> For:
> Me
> Dann
> Barre
> Doug
> Gortsilas
> Against:
> Pascal
>
> I can't decide what Jordi is. And if anyone wants to move to the
> against or
> be added to any of the 2 let me know
>
> 8an
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev


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

RE: [Dynapi-Dev] Next Generation

[Michael E. <Mic...@il...>]

Sorry folks, you have to sign up for a subscription to get the latest stats.
You're correct, the sample report is dated!

Mike

-----Original Message-----
From: Raymond Smith [mailto:dst...@or...]
Sent: Monday, January 29, 2001 22:50
To: dyn...@li...
Subject: Re: [Dynapi-Dev] Next Generation


Carefull if your using the "sample stats" from there.  They date back to
1999 and reflect an older reality.  Most recent browser stats I have found
are at www.thecounter.com.  From October 2000.

----- Original Message -----
From: "Michael Ellis" <Mic...@il...>
To: <dyn...@li...>
Sent: Monday, January 29, 2001 2:53 PM
Subject: RE: [Dynapi-Dev] Next Generation


> Amen brother!
>
> No argument here... Although we can be educated to, we cannot expect nor
> demand which platform/browser our end-users choose. If our software is to
be
> taken seriously, and serve a broad community we must be reasonable about
> which platforms/browsers we support. If you think I'm full of it, check
the
> browser/platform statistics at www.statmarket.com (don't rely on
statistics
> gathered by developer forums, they attract developers like us and are
> typically not representative of our products end-users).
>
> Mike Ellis
>
> -----Original Message-----
> From: .:: OCB ::. [mailto:oc...@ho...]
> Sent: Monday, January 29, 2001 10:15
> To: dyn...@li...
> Subject: Re: [Dynapi-Dev] Next Generation
>
>
> Next generation ???
>
> Would it not be a good idea to get the DynApi2 working in all browsers
> (basic methods, moveTo, event handlers etc; not wigits, IMO they take a
> backseat to basic functionality) before even discussing another generation
> of the API.
>
> I haven't contributed anything in months (which is beyond my control) so
> feel quite apprehensive about posting this but again, IMO, it makes common
> sense to get the basic's of this project crossbrowser (NN6 included) and
bug
>
> free before launching into another generation of the API.
>
> Flame away !!!!
>
>
> >From: "Jared Nuzzolillo" <ja...@aa...>
> >Reply-To: dyn...@li...
> >To: <dyn...@li...>
> >Subject: [Dynapi-Dev] Next Generation
> >Date: Mon, 29 Jan 2001 11:46:41 -0500
> >
> >I have a feeling that certain people are wanting to implement class-like
> >inheritance because it is more familiar/comfortable to them.
> >
> >I strongly agree with Pascal. Prototype-based inheritance works
> >beautifully,
> >and is native to javascript, so why would we want to enforce a different
> >type of inheritance to use the API? Most dynapi users will at least be
> >familiar with javascript, and may be expecting Prototype-like behavior.
> >
> >It's kind of like creating a number class instead of using built in
number
> >objects and primitive types. It's pointeless.
> >
> >As far as the class/prototype argument as to what Netscape says, the
first
> >line of this article:
> >
>
>http://developer.netscape.com/docs/manuals/communicator/jsobj/contents.htm
> >
> >reads as follows:
> >
> >"JavaScript is an object-oriented language based on prototypes, rather
> >than,
> >as is common, being class-based."
> >
> >-jaredn
> >
> >
> >
> >
> >_______________________________________________
> >Dynapi-Dev mailing list
> >Dyn...@li...
> >http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>
> _________________________________________________________________________
> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
>
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>

[Dynapi-Dev] Next Generation 9

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

Hey...

I think most of you seem to be missing the point somewhat. 
Let me explain:

There are certain reasons why languages such as Java and 
other OO languages have evolved. Stability, 
reusabilty/modularity, ease of use, security etc. Object 
Orientation exists because people wanted a way to easier 
abstract problems, and represent them in a more human-like 
fashion.
Now what DynLayer tries to do is simulate parts of this 
whilst providing funcionality for robust, consistant and 
simple dHtml creation.

But how can you create a complex API such as DynAPI without 
having some fundamentals already in place? Such as a fast, 
stable, easy and safe way of creating a class 
hierarchy/implementing basic OOP functionality.
I mean, how long has this "current" release been in a 
debugging phase ??! Do you not think that this could have 
been avoided, atleast in part, by having a more stable 
coding ground to develop with?

True, Javascript's prototype based OO provide some 
functionality for creating "classes". But this approach is 
inherantly slow, memory consuming and error prone, since 
some of the most fundamental OOP functionality is not 
supported (such as true encapsulation).
Why go halfway, sort of do OOP, but not really, because 
it's too hard ? It's not! In the long run it's much 
simpler. Which is the exact point of DynAPI in the first 
place. There is a longer learning curve before you can use 
it, but when you do, your efforts are greatly simplified 
and accellerated.

What you would want, is to have somekind of Object 
providing the remaining OOP functionality that Javascript 
does not inherantly support, so that you don't have to 
recreate the wheel everytime you develop somekind of 
application or extension to it.
Pascals DynObject and Eytans SuperObject, are examples of 
what I'm talking about.
DynObject provides better modularity for DynAPI, and a 
SuperObject would provide the tools with which to better 
build a more modular DynAPI (there are a couple of more 
people that have developed a SuperObject/SuperClass).

Yes, you could argue that this would only lead to more 
bugs, and that you should rely on JavaScript's built-in way 
of handling OOP, and that this should be a API for 
designers, not for programmers and what have you...
But this is simply not true. 

1. DynAPI is a programming tool/interface for creating 
dHtml.
Now programming is the key word here. No matter what, you 
still have to PROGRAM. If you would want to create a 
simpler interface for creating dHtml (a WYSIWYG for 
instance), there still has to be someone who creates this 
interface, and I guarantee you, it won't be a designer! ;)

2. Having a SuperClass that provides basic OOP 
functionality, would provide the PROGRAMMER with the tools 
nessessary to create DynAPI with a lot more ease 
(again,this is the goal of OOP). 
For example, say that you would want to split up DynAPI per 
browser basis and make this seamless for the end 
programmer. If you would not have fundamental OOP 
functionality in place, this would be HARD!  

True, the SuperClass would have to be flawless and 
completely without bugs for this premise to work. 
But this is not impossible. I know, because I'm in the 
finishing stages of creating a comprehensive SuperClass 
myself (I might even create an opensource forum for it ;D )
SuperClass is, and should be, inherantly separate from 
DynAPI, and you could create whatever class hierarchy you 
would want with it, including DynAPI. 

In closing, I do hope that what I've said will infact sink 
in, and not just be flamed ;)

Alea Jacta Est, 
Bart

PS. I apoligize if this mail is doubled, my mail client 
seems to have flaked out on me DS

Re[2]: [Dynapi-Dev] Counting so far

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

You can count all you want, but that serves no useful purpose to this
project other than to detract from the DynAPI.

If you want to build your own library, go ahead.  But Dan created the
DynAPI 2 and we are here to help make the DynAPI 2 a viable api.  If
you don't like it, don't use it.

-- 
// Robert Rainwater

On 1/30/2001, 11:25:01 AM EST, Eytan wrote about "[Dynapi-Dev] Counting so far":

>  For:
>  Me
>  Dann
>  Barre
>  Doug
>  Gortsilas

>  Against:
>  Pascal
> Cameron


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


----------------------
DynAPI Snapshots: http://dynapi.sourceforge.net/snapshot/
DynAPI Homepage: http://dynapi.sourceforge.net/

[Dynapi-Dev] new Layer constructor

[Eytan H. <ey...@tr...>]

How exactly does this constructor in NS4 go
new Layer(width,parent-layer)??
8an

Re: [Dynapi-Dev] Counting so far

[Jared N. <ja...@aa...>]

I am very against. Eytan, can you please send me this SuperClass object
please?

Re: [Dynapi-Dev] Counting so far

[Dann <da...@to...>]

Hold on,

I'm not against Pascal's ideas either, so my judgement is hung ! Not me... the
judgement, okay ?

CU,
 Dann

RE: [Dynapi-Dev] Counting so far

[Eytan H. <ey...@tr...>]

 For:
 Me
 Dann
 Barre
 Doug
 Gortsilas

 Against:
 Pascal
Cameron

RE: [Dynapi-Dev] Counting so far

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

this seems quite ridiculous, but for what it's worth add me to the against.
i'd rather see x-browser bugs fixed first.

i really doubt that the current object model is what is causing instability,
if you can actually prove that perhaps i'll change sides.

> -----Original Message-----
> From: dyn...@li...
> [mailto:dyn...@li...]On Behalf Of Eytan
> Heidingsfeld
> Sent: 30 January 2001 16:13
> To: Dynapi-Dev
> Subject: [Dynapi-Dev] Counting so far
>
>
> For:
> Me
> Dann
> Barre
> Doug
> Gortsilas
> Against:
> Pascal
>
> I can't decide what Jordi is. And if anyone wants to move to the
> against or
> be added to any of the 2 let me know
>
> 8an
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev

RE: Re[2]: [Dynapi-Dev] [Bug #130357] small typo in list.js

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

according to the ecmascript-262 spec (i'm being a trainspotter here!), an
assignment should return the assigned value. so ns6 is not doing the right
thing.

the real point of changing this line is if the api is to be cross-browser it
has to work around faults in all the browsers (and lets face it, there's a
lot of them!).

> -----Original Message-----
> From: dyn...@li...
> [mailto:dyn...@li...]On Behalf Of Doug Melvin
> Sent: 30 January 2001 18:51
> To: dyn...@li...
> Subject: Re: Re[2]: [Dynapi-Dev] [Bug #130357] small typo in list.js
>
>
> I've just had that conversation with a co-worker.
> Can anyone tell me why this is not proper?
> The best my co-worker could come up with was 'it doesn't feel right'
> ....
>
>
> > Either way, we shouldn't be using if (this.selected=b).  That's not
> > very proper.
> >
> > --
> > // Robert Rainwater
> >
> > On 1/30/2001, 8:47:21 AM EST, Raides wrote about "[Dynapi-Dev] [Bug
> #130357] small typo in list.js":
> >
> > > Michael Pemberton wrote:
> > >>
> > >> please put the "typo" back.  What is does is set the value of
> this.selected to
> > >> b and then evaluates the returned value (the new value of
> this.selected).  It
> > >> is needed to change the selected state of the item.
> > >>
> >
> > >> > if (this.selected=b) {
> > >> >
> > >> > should be
> > >> >
> > >> > if (this.selected==b) {
> > >> >
> > >> > right?
> >
> > >         I will answer both for NS6's sake:
> >
> > >         This is indeed a bug in NS6 and prevents normal
> execution of the
> rest of the
> > > code. It should read:
> >
> > > this.selected=b
> > > if(this.selected){
> > > ...
> > > }else{
> > > ...
> > > }
> >
> > >         I have done this kind of changes all around my local dynapi
> distribution and
> > > those pesky errors that NS6 throwed at me and their side
> effect of code
> not
> > > executing in that function anymore disappeared. Other special
> perso-NS6-ality of
> > > this browser is that if you want to dynamically resize an image, you
> have to do
> > > it TWICE, using a setTimeout to delay appropiately (30 millisecs are
> enough) the
> > > effect. The code I use to test NS6 comes with this mail. It is spanish
> code and
> > > HTML, poorly documented but that can be executed in IE4.0 and
> above with
> no
> > > changes at all and some errors due to their different
> underlying model.
> >
> > >         Raides J.
> >
> >
> > ----------------------
> > DynAPI Snapshots: http://dynapi.sourceforge.net/snapshot/
> > DynAPI Homepage: http://dynapi.sourceforge.net/
> >
> >
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev

Re[2]: [Dynapi-Dev] [Bug #130357] small typo in list.js

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

Come to think of it, the line is not correct anyway.

If the item is selected then there is no reason to set it.

if (this.selected==b) return;

-- 
// Robert Rainwater

On 1/30/2001, 1:28:49 PM EST, Doug wrote about "[Dynapi-Dev] [Bug #130357] small typo in list.js":

> That just plain silly.
> It's perfectly valid coding technique.

>   perhaps it would be safer to assign the value first and then test the condition...
>     -----Original Message-----
>     From: dyn...@li... [mailto:dyn...@li...]On Behalf Of Michael Pemberton
>     Sent: 30 January 2001 13:28
>     To: dyn...@li...
>     Subject: Re: [Dynapi-Dev] [Bug #130357] small typo in list.js


>     please put the "typo" back.  What is does is set the value of this.selected to b and then evaluates the returned value (the new value of this.selected).  It is needed to change the selected
> state of the item. 
>     no...@so... wrote: 

>       Bug #130357, was updated on 2001-Jan-28 14:27 
>       Here is a current snapshot of the bug. 
>       Project: DynAPI 2 
>       Category: Core - Widgets 
>       Status: Closed 
>       Resolution: Fixed 
>       Bug Group: None 
>       Priority: 5 
>       Submitted by: marstr 
>       Assigned to : rainwater 
>       Summary: small typo in list.js 

>       Details: there's a small typo (i think) in list.js line 76 

>       if (this.selected=b) { 

>       should be 

>       if (this.selected==b) { 

>       right? 

>       Follow-Ups: 

>       Date: 2001-Jan-28 17:50 
>       By: rainwater 

>       Comment: 
>       Doh!  Its been updated in CVS.  Closing this bug. 
>       ------------------------------------------------------- 

>       For detailed info, follow this link: 
>       http://sourceforge.net/bugs/?func=detailbug&bug_id=130357&group_id=5757 

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

>     -- 
>     Michael Pemberton 
>     mp...@ph... 
>     ICQ: 12107010 
      



----------------------
DynAPI Snapshots: http://dynapi.sourceforge.net/snapshot/
DynAPI Homepage: http://dynapi.sourceforge.net/

[Dynapi-Dev] Counting so far

[Eytan H. <ey...@tr...>]

For:
Me
Dann
Barre
Doug
Gortsilas
Against:
Pascal

I can't decide what Jordi is. And if anyone wants to move to the against or
be added to any of the 2 let me know

8an

RE: [Dynapi-Dev] Why, What Where and when

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

again, the first one to respond (just to keep it imaginative :)

> Why
> ---
> One of the reasons for the lack of stability in DynAPI is the
> way it is put
> together. I respect that professor very much and I understand
> he likes the
> model but this exact model is why it crashes and why it
> develops like it
> does.


Uhm? the way it is coded causes it to crash? Common, please explain this a
bit further because I realy don't understand how you came to this logic
(yes, I love logic).

Also, I've been doing ALOT with DynAPI, and never run into any real
stability issues. Things run correctly and maybe I'm not doing any
"advanced" stuff or something  but the most often heard problem here is
about widgets, not the DynAPI.. This might be because the DynAPI was never
finished before we started doing widget coding. Things changed, and widgets
got updated (in a patch like manor) I think that's the reason things crash
and might feel instable  not the DynAPI code it self.

> What
> ----
> What do I mean. I want to rewrite the actual core meaning changing
> everything. Making a DynLayer class that is totally independent. Then
> creating a whole OO environment (it doesn't matter at this
> stage if we use
> prototypes or classes for OO but the current API misuses OO
> completely).

Again, explain more. An OO environment, which means? and it probably depends
on your look of OO, because in my eyes the DynAPI shows how to do OOP in
Javascript. We seperated everthing into objects (dynlayer, dyndocument,
events, mouseevent, widgets, etc)  that interact with each other. Also
remember what we're coding for: browsers.. they use a DOM wich is probably a
direction we should work towards with the DynAPI, making things accesable in
the same way so that you don't really feel a difference between the DOM and
the DynAPI.


> Where
> -----
> I know that you guys want this to be the perfect
> "Dreamweaver" use solution.
> For that this thing has to be modeled in a logical simple
> way.  It also has
> to be a whole lot more stable then it is today

No, it has to be user-friendly and making a friendly WYSIWYG that generates
the code.. which has nothing to do with how logical the DynAPI code is.

> When
> ----
> As they say "Never been a better time then right now!" As I previously
> stated the development of support for other browsers can be
> integrated in
> the rewrite.

True saying :-)
Doing a full rewrite will take another year probably before everything is
browser-friendly... we've been working on this version for more then a year
now, and it is finally getting a firm user-base (strangely this only
happened because Dan closed down his forum !?!). I think webdesigners are
now trusting this API to be stable enough for there cross-browser layer
placing and managing.. If we can finish the widgets we will be able to
compete with other DHTML api's for web-applications.

and uhm, IE6 is already on its way, within a year, we're probably at IE7 and
AOL10 or something, so you'll be at the same position you'r now: patching in
extra code to support those browsers.


> I can see that most ppl disagree with me and like things the
> way they are, I
> hope I can change your mind but I guess its up to the majority.

nothing to add :)


Pascal Bestebroer (pb...@oi...)
Software ontwikkelaar
Oberon Informatiesystemen b.v.
http://www.oibv.com

[Dynapi-Dev] Proper Coding Technique? if(a=b)

[Jared N. <ja...@aa...>]

Some people will tell you it is improper. some people will say it is fine. I
think the only improper thing about it is a lack of comment next to it.
Because it is an unothorodox coding technique (as far as most are concerned)
a simple comment can alleviate any question as to where it was done
purposely.