dynapi-dev Mailing List for DynAPI (Page 246)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Happened to me a few times.

I don't think email really cares about timezones :p

there might be a problem with the list server I guess (to many persons on
the list ? :-)

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

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Richard Bennett
> Verzonden: dinsdag 30 januari 2001 11:55
> Aan: dyn...@li...
> Onderwerp: Re: [Dynapi-Dev] Loosing mail
>
>
> Hi,
> Yes, I have the same problem, I thought it had something to do with
> timezones; the people who are six hours ahead of the others
> are responding
> to messages the others still have to write. (it's great for meeting
> deadlines).
>
> Cheers,
> Richard Bennett
>
> ma...@ri...
> www.richardinfo.com
> (Everything running on, and ported to the 19/12/2000 snapshot
> of DynAPI2)
>
> ----- Original Message -----
> From: "Pascal" <pb...@oi...>
> To: <dyn...@li...>
> Sent: Tuesday, January 30, 2001 8:46 AM
> Subject: [Dynapi-Dev] Loosing mail
>
>
> > Uhm, is it just me or am I missing emails now and then?
> >
> > I sometimes read replies on email I haven't seen on the list.
> >
> > One example, the mail from Michael Ellis into reply on OCB.. I never
> > received the OCB mail!? I had the same thing yesterday also
> a reply on
> > something I never saw on the list?
> >
> > Has my email been hit by rocks or something? Anyone else
> has this problem?
> > (not the rock problem, but email problem)
> >
> > Pascal Bestebroer (pb...@oi...)
> > Software ontwikkelaar
> > Oberon Informatiesystemen b.v.
> > http://www.oibv.com
> >
> >
> > _______________________________________________
> > 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
> >
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>

Hi,
Yes, I have the same problem, I thought it had something to do with
timezones; the people who are six hours ahead of the others are responding
to messages the others still have to write. (it's great for meeting
deadlines).

Cheers,
Richard Bennett

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

----- Original Message -----
From: "Pascal" <pb...@oi...>
To: <dyn...@li...>
Sent: Tuesday, January 30, 2001 8:46 AM
Subject: [Dynapi-Dev] Loosing mail

> Uhm, is it just me or am I missing emails now and then?
>
> I sometimes read replies on email I haven't seen on the list.
>
> One example, the mail from Michael Ellis into reply on OCB.. I never
> received the OCB mail!? I had the same thing yesterday also a reply on
> something I never saw on the list?
>
> Has my email been hit by rocks or something? Anyone else has this problem?
> (not the rock problem, but email problem)
>
> Pascal Bestebroer (pb...@oi...)
> Software ontwikkelaar
> Oberon Informatiesystemen b.v.
> http://www.oibv.com
>
>
> _______________________________________________
> 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
>

Hi,

I remember a post from Robert saying he'd got offsetWidth and offsetHeight
working in NS6 using a setTimeout. Was this specific to one of the widgets
Robert, or did it fix W/H for everything in NS6?

If you need a setTimeout for the thing to work properly, it sounds like a
bug in the browser. The great thing about Mozilla is if you post a bug,
they'll fix it for you ;-) It can take a while, it depends on how important
the developers feel that peice of functionality is. But I think it would be
worth writing a test case and a bug report for the W/H bug. I can submit one
if someone (Robert I guess) tells me how to reproduce the bug, that is how
it works versus how you think it should work.

Something else which might be if interest to DOM enthusiasts, I was
wondering why offsetHeight and offsetWidth and similar measurements aren't
in any of the DOM's. I posted a query about this to ww...@w3..., and the
response was it's been put on the back burner as there hasn't been that much
interest in this functionality. Apparently it will probably end up in DOM3.
I thought it would have been pretty core functionality...

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

Take a look at my Dynacore.. it contains the following:

DynObject - contains child-parent relation handling (add/remove/delete)
  DynLayer - contains only Layer handling (move,size,create,etc..)
  DynDocument - contains only document handling.

Events - are attached to DynObject, and making events available to all
sub-classes (DynLayer, DynDocument, widets, managers, etc..)

Which is, as far as I can tell, what you'r talking about.

I'm not sure about your "application" object, if you mean a basic
application-framework I think that should not be part of the DynAPI  (it's
an API) layout managing should be simpler using seperate managers for it
(widget - like objects) That could be inheriting (there we have it again :)
from the DynObject, automatically having the add/delete/remove functionality
needed by other widgets.

But again, I don't see the point of "starting" a next generation of this
API.. The differences between DynAPI1 and DynAPI2 is huge, it's better
coded, includes the main feature "on-the-fly" creation of layers and a
kick-ass event system. What would be the extra functionality the "next
generation" could supply us with? and don't look at the way you code it.. if
you want another coding style in the DynAPI start your own distribution (an
idea that works :-) it would add nothing extra to the end-users
(site-developers.. the creative rock throwing people).

I actually prefer the idea of getting a DynBuilder type thing working
instead of a new DynAPI generation, this would give such a boost to the
user-base of the DynAPI, and might actually make the DynAPI competing with
things as Flash.

Let's just finish this one up getting it to run cross-browser (and if
possible cross-platform) and make it more user-friendly (widgets,editor,
etc)

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

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Eytan
> Heidingsfeld
> Verzonden: dinsdag 30 januari 2001 9:32
> Aan: dyn...@li...
> Onderwerp: [Dynapi-Dev] Next Generation part II
>
>
> Ok, so now we have all discussed and recommended and finished throwing
> stones. After we all got in-depth about OO and prototypes and
> classes where
> are we going. My recommendation of how to act is as such:
> * Create a DynLayer(mayber change it's name) that is totally
> seprate and
> stand alone. It includes only methods to affect the layer and
> events that
> are triggered from the outside(mouse and keyboard events).
> * Create the basic objects: Application, Object, Component
> Application:
> Manages the DynLayers focus and events
> Object:
> Basic object with create and destroy
> Component:
> Basic object with dynlayer.
>
> I'd be glad to change the model if anyone has new and improved ideas.
>
> Now except for the actual model I want to know if we have
> enough ppl who
> want a next generation to continue.
>
> 8an
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>

Ok, so now we have all discussed and recommended and finished throwing
stones. After we all got in-depth about OO and prototypes and classes where
are we going. My recommendation of how to act is as such:
* Create a DynLayer(mayber change it's name) that is totally seprate and
stand alone. It includes only methods to affect the layer and events that
are triggered from the outside(mouse and keyboard events).
* Create the basic objects: Application, Object, Component
Application:
Manages the DynLayers focus and events
Object:
Basic object with create and destroy
Component:
Basic object with dynlayer.

I'd be glad to change the model if anyone has new and improved ideas.

Now except for the actual model I want to know if we have enough ppl who
want a next generation to continue.

8an

Uhm, is it just me or am I missing emails now and then?

I sometimes read replies on email I haven't seen on the list.

One example, the mail from Michael Ellis into reply on OCB.. I never
received the OCB mail!? I had the same thing yesterday also a reply on
something I never saw on the list?

Has my email been hit by rocks or something? Anyone else has this problem?
(not the rock problem, but email problem)

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

Yes but....

the CORE must be good enough to support all those users (and their
requests)...

That's why I beleive that a good object model in the core will help (A LOT)
this task!!!

What Pascal recommends (for example the DynObject) I think is necessary! I
beleive that especially this one is obvious!!!

We need strong core lib (and flexible) in order to accomplishe the DynAPI
it's purpose!

I agree that documentation is a MUST also... I am also new tp DynAPI and it
was difficult to me with out Pascal's documentation...

Andreas Gortsilas

-----Original Message-----
From: David Gerding - Columbia College Chicago
[mailto:dge...@po...]
Sent: Monday, January 29, 2001 10:23 PM
To: dyn...@li...
Subject: RE: [Dynapi-Dev] Next Generation

As a complete newcomer to DynApi, I'm a little reluctant to speak up.  But
since I'm a professor considering whether or not "evangelize" DynApi to our
undergraduate class of over 300 interactive media designers, maybe a
different perspective is worth something to those of you who have worked so
hard to make DynApi.

PLEASE don't do a major object model overhaul.  The current model seems
sufficient.  If your goal is to get DynApi widely adopted then stabilizing
the core and working on cross-platform compatibility seem the top priority.
For instance, the new documentation in the latest release is a godsend.  Now
I can work my way through learning this thing in a logical manner.

I look forward to helping develop the project in some way in the future.
But first, I need to learn and understand it.

I've got a lot of hope about this project.  Thank you all for your efforts,
and thanks for listening.

Dave Gerding
Columbia College Chicago

p.s. has anyone contacted opera software directly about actively joining the
development effort?  It would seem to be in their interest to do so... just
another thought.

-----Original Message-----
From: dyn...@li...
[mailto:dyn...@li...]On Behalf Of Pascal
Bestebroer
Sent: Monday, January 29, 2001 1:14 PM
To: dyn...@li...
Subject: RE: [Dynapi-Dev] Next Generation

And to target the subject of this thread: Next Generation ? Huh?  why? what?
how?

The current DynAPI should just be made ready for NS6 (and mac systems where
possible)

Even my proposal for combining DynLayer and DynDocument into a DynObject
might be considered unneeded (although I think this structure would make it
possible to create "managers" like a layout-manager, etc. which are not
visual components but DO need the parent-child functionality as used in all
other DynAPI components and am very willing to receive the flames and rocks
on that one)

I'm not sure what the extra functionality of that "next generation" DynAPI
would be.. it would just be programmed in another style but that's it, at
least as far as I can tell from the posts in this thread.

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

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Jordi 'IlMaestro'
> Ministral
> Verzonden: maandag 29 januari 2001 19:07
> Aan: dyn...@li...
> Onderwerp: Re: [Dynapi-Dev] Next Generation
>
>
> In a perfect future, the target of this API would be the current
> dreamweaver user. You should not need any programming skills to
> build pages using DynAPI. Discussing if this or that programming
> model is better makes sense when you are in a computer science
> forum but in this case, if overloading this already-bloated API
> with additional complexities does not result in a better
> cross-browser support or a better end-user ( read desinger )
> interface, then I'm against it.
>
> Sometimes the code is the objective, the goal of a project, and
> then it makes sense to discuss how should code behave and be
> structured. In this case the code is nothing but a tool: it has
> to be properly programmed, but that's enough.
>
>
> Henrik Våglin wrote:
>
> > About the current discussion on OO, JS, OOJS and the confusion
> on what they are:
> >
> > OO is the model.
> > OOM is the method.
> > OOP is the technique.
> >
> > Therefor JS is a tool of the prottyping OO technique. It's
> unnecessary to create a more classbased structure of what is
> essentially a merge of prototyping and class-inheritance (ie
> DynAPI). It's merely a question of approach wheter to use
> prototyping - which is more towards experimental development - or
> class inheritance. the only real different is wheter to allow for
> more unconditional extensability that is the default of
> javascript and which DynAPI is mostly today VS a more conditional
> class inheriting technique.
> >
> > Personally I vote for the previous and I think most others who
> are more designers at heart prefer it to remain so. The only
> reason to make DynAPI more class inheriting would be to attract
> more OOP developers (who generally are more used to
> class-inheritencing tools), which of course would be great for
> development, but distracts more from those who need the API more
> - the designers. Consider the folloowing...
> >
> > Developers don't need a new language as much as designer does.
> There's enough class-inheriting OOP tools around for developers.
> I also think Microsoft is moving out of range for designers with
> their new .NET structure which the new ASP+ currently in beta is
> part of. Is DynAPI OO (or next gen) to compete with .NET? I vote
> for keeping DynAPI structure developing as it is and remain a
> real API, not a programming semi-language!
> >
> > My plead is to focusing on targetting DynAPI for designers. A
> OO DynAPI might instead be bringing design enhancement for
> programmers to comprehand. In other words: keep it separated and
> focus more on different users, but of course all kind of exchange
> of knowledge is a good thing - so also keep a symbiotic
> relationship between the two (and maybe designers and developers
> will come to understand eachothers expertise areas more).
> >
> > Henrik Våglin [ hv...@ya... ]
> >
> > _________________________________________________________
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.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

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

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
>

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.

Bug #130415, was updated on 2001-Jan-29 13:29
Here is a current snapshot of the bug.

Project: DynAPI 2
Category: None
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: mibuerge
Assigned to : nobody
Summary: Mac/IE5: problem with elm-property

Details: the first child added to a widget gets a wrong elm-property, it
points the elm-Object of its parent.
i've put a testpage with more explanations on the web:
http://n.ethz.ch/student/mibuerge/dynapi/testcase.htm

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

----- Original Message -----=20
From: "David Gerding - Columbia College Chicago" =
<dge...@po...>
To: <dyn...@li...>
Sent: Monday, January 29, 2001 12:23 PM
Subject: RE: [Dynapi-Dev] Next Generation

> As a complete newcomer to DynApi, I'm a little reluctant to speak up.  =
But
> since I'm a professor considering whether or not "evangelize" DynApi =
to our
> undergraduate class of over 300 interactive media designers, maybe a
> different perspective is worth something to those of you who have =
worked so
> hard to make DynApi.

This is a VERY good thing.. It could lead to wide-spread commercial =
acceptance of DynAPI as a tool

> PLEASE don't do a major object model overhaul.  The current model =
seems
> sufficient.  If your goal is to get DynApi widely adopted then =
stabilizing
> the core and working on cross-platform compatibility seem the top =
priority.

Agreed!

> For instance, the new documentation in the latest release is a =
godsend.  Now
> I can work my way through learning this thing in a logical manner.

Let's hear it for Documentation!!!
=20
> I look forward to helping develop the project in some way in the =
future.
> But first, I need to learn and understand it.
>=20
> I've got a lot of hope about this project.  Thank you all for your =
efforts,
> and thanks for listening.
>=20
> Dave Gerding
> Columbia College Chicago
>=20
> p.s. has anyone contacted opera software directly about actively =
joining the
> development effort?  It would seem to be in their interest to do so... =
just
> another thought.

And a very valid thought indeed! Robert? Pascal?

> -----Original Message-----
> From: dyn...@li...
> [mailto:dyn...@li...]On Behalf Of Pascal
> Bestebroer
> Sent: Monday, January 29, 2001 1:14 PM
> To: dyn...@li...
> Subject: RE: [Dynapi-Dev] Next Generation
>=20
>=20
> And to target the subject of this thread: Next Generation ? Huh?  why? =
what?
> how?
>=20
> The current DynAPI should just be made ready for NS6 (and mac systems =
where
> possible)
>=20
> Even my proposal for combining DynLayer and DynDocument into a =
DynObject
> might be considered unneeded (although I think this structure would =
make it
> possible to create "managers" like a layout-manager, etc. which are =
not
> visual components but DO need the parent-child functionality as used =
in all
> other DynAPI components and am very willing to receive the flames and =
rocks
> on that one)
>=20
> I'm not sure what the extra functionality of that "next generation" =
DynAPI
> would be.. it would just be programmed in another style but that's it, =
at
> least as far as I can tell from the posts in this thread.
>=20
>=20
>=20
> Pascal Bestebroer
> pa...@dy...
> http://www.dynamic-core.net
>=20
> > -----Oorspronkelijk bericht-----
> > Van: dyn...@li...
> > [mailto:dyn...@li...]Namens Jordi =
'IlMaestro'
> > Ministral
> > Verzonden: maandag 29 januari 2001 19:07
> > Aan: dyn...@li...
> > Onderwerp: Re: [Dynapi-Dev] Next Generation
> >
> >
> > In a perfect future, the target of this API would be the current
> > dreamweaver user. You should not need any programming skills to
> > build pages using DynAPI. Discussing if this or that programming
> > model is better makes sense when you are in a computer science
> > forum but in this case, if overloading this already-bloated API
> > with additional complexities does not result in a better
> > cross-browser support or a better end-user ( read desinger )
> > interface, then I'm against it.
> >
> > Sometimes the code is the objective, the goal of a project, and
> > then it makes sense to discuss how should code behave and be
> > structured. In this case the code is nothing but a tool: it has
> > to be properly programmed, but that's enough.
> >
> >
> > Henrik V=E5glin wrote:
> >
> > > About the current discussion on OO, JS, OOJS and the confusion
> > on what they are:
> > >
> > > OO is the model.
> > > OOM is the method.
> > > OOP is the technique.
> > >
> > > Therefor JS is a tool of the prottyping OO technique. It's
> > unnecessary to create a more classbased structure of what is
> > essentially a merge of prototyping and class-inheritance (ie
> > DynAPI). It's merely a question of approach wheter to use
> > prototyping - which is more towards experimental development - or
> > class inheritance. the only real different is wheter to allow for
> > more unconditional extensability that is the default of
> > javascript and which DynAPI is mostly today VS a more conditional
> > class inheriting technique.
> > >
> > > Personally I vote for the previous and I think most others who
> > are more designers at heart prefer it to remain so. The only
> > reason to make DynAPI more class inheriting would be to attract
> > more OOP developers (who generally are more used to
> > class-inheritencing tools), which of course would be great for
> > development, but distracts more from those who need the API more
> > - the designers. Consider the folloowing...
> > >
> > > Developers don't need a new language as much as designer does.
> > There's enough class-inheriting OOP tools around for developers.
> > I also think Microsoft is moving out of range for designers with
> > their new .NET structure which the new ASP+ currently in beta is
> > part of. Is DynAPI OO (or next gen) to compete with .NET? I vote
> > for keeping DynAPI structure developing as it is and remain a
> > real API, not a programming semi-language!
> > >
> > > My plead is to focusing on targetting DynAPI for designers. A
> > OO DynAPI might instead be bringing design enhancement for
> > programmers to comprehand. In other words: keep it separated and
> > focus more on different users, but of course all kind of exchange
> > of knowledge is a good thing - so also keep a symbiotic
> > relationship between the two (and maybe designers and developers
> > will come to understand eachothers expertise areas more).
> > >
> > > Henrik V=E5glin [ hv...@ya... ]
> > >
> > > _________________________________________________________
> > > Do You Yahoo!?
> > > Get your free @yahoo.com address at http://mail.yahoo.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
> >
>=20
>=20
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>=20
>=20
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev

As a complete newcomer to DynApi, I'm a little reluctant to speak up.  But
since I'm a professor considering whether or not "evangelize" DynApi to our
undergraduate class of over 300 interactive media designers, maybe a
different perspective is worth something to those of you who have worked so
hard to make DynApi.

PLEASE don't do a major object model overhaul.  The current model seems
sufficient.  If your goal is to get DynApi widely adopted then stabilizing
the core and working on cross-platform compatibility seem the top priority.
For instance, the new documentation in the latest release is a godsend.  Now
I can work my way through learning this thing in a logical manner.

I look forward to helping develop the project in some way in the future.
But first, I need to learn and understand it.

I've got a lot of hope about this project.  Thank you all for your efforts,
and thanks for listening.

Dave Gerding
Columbia College Chicago

p.s. has anyone contacted opera software directly about actively joining the
development effort?  It would seem to be in their interest to do so... just
another thought.

-----Original Message-----
From: dyn...@li...
[mailto:dyn...@li...]On Behalf Of Pascal
Bestebroer
Sent: Monday, January 29, 2001 1:14 PM
To: dyn...@li...
Subject: RE: [Dynapi-Dev] Next Generation

And to target the subject of this thread: Next Generation ? Huh?  why? what?
how?

The current DynAPI should just be made ready for NS6 (and mac systems where
possible)

Even my proposal for combining DynLayer and DynDocument into a DynObject
might be considered unneeded (although I think this structure would make it
possible to create "managers" like a layout-manager, etc. which are not
visual components but DO need the parent-child functionality as used in all
other DynAPI components and am very willing to receive the flames and rocks
on that one)

I'm not sure what the extra functionality of that "next generation" DynAPI
would be.. it would just be programmed in another style but that's it, at
least as far as I can tell from the posts in this thread.

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

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Jordi 'IlMaestro'
> Ministral
> Verzonden: maandag 29 januari 2001 19:07
> Aan: dyn...@li...
> Onderwerp: Re: [Dynapi-Dev] Next Generation
>
>
> In a perfect future, the target of this API would be the current
> dreamweaver user. You should not need any programming skills to
> build pages using DynAPI. Discussing if this or that programming
> model is better makes sense when you are in a computer science
> forum but in this case, if overloading this already-bloated API
> with additional complexities does not result in a better
> cross-browser support or a better end-user ( read desinger )
> interface, then I'm against it.
>
> Sometimes the code is the objective, the goal of a project, and
> then it makes sense to discuss how should code behave and be
> structured. In this case the code is nothing but a tool: it has
> to be properly programmed, but that's enough.
>
>
> Henrik Våglin wrote:
>
> > About the current discussion on OO, JS, OOJS and the confusion
> on what they are:
> >
> > OO is the model.
> > OOM is the method.
> > OOP is the technique.
> >
> > Therefor JS is a tool of the prottyping OO technique. It's
> unnecessary to create a more classbased structure of what is
> essentially a merge of prototyping and class-inheritance (ie
> DynAPI). It's merely a question of approach wheter to use
> prototyping - which is more towards experimental development - or
> class inheritance. the only real different is wheter to allow for
> more unconditional extensability that is the default of
> javascript and which DynAPI is mostly today VS a more conditional
> class inheriting technique.
> >
> > Personally I vote for the previous and I think most others who
> are more designers at heart prefer it to remain so. The only
> reason to make DynAPI more class inheriting would be to attract
> more OOP developers (who generally are more used to
> class-inheritencing tools), which of course would be great for
> development, but distracts more from those who need the API more
> - the designers. Consider the folloowing...
> >
> > Developers don't need a new language as much as designer does.
> There's enough class-inheriting OOP tools around for developers.
> I also think Microsoft is moving out of range for designers with
> their new .NET structure which the new ASP+ currently in beta is
> part of. Is DynAPI OO (or next gen) to compete with .NET? I vote
> for keeping DynAPI structure developing as it is and remain a
> real API, not a programming semi-language!
> >
> > My plead is to focusing on targetting DynAPI for designers. A
> OO DynAPI might instead be bringing design enhancement for
> programmers to comprehand. In other words: keep it separated and
> focus more on different users, but of course all kind of exchange
> of knowledge is a good thing - so also keep a symbiotic
> relationship between the two (and maybe designers and developers
> will come to understand eachothers expertise areas more).
> >
> > Henrik Våglin [ hv...@ya... ]
> >
> > _________________________________________________________
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.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

And to target the subject of this thread: Next Generation ? Huh?  why? what?
how?

The current DynAPI should just be made ready for NS6 (and mac systems where
possible)

Even my proposal for combining DynLayer and DynDocument into a DynObject
might be considered unneeded (although I think this structure would make it
possible to create "managers" like a layout-manager, etc. which are not
visual components but DO need the parent-child functionality as used in all
other DynAPI components and am very willing to receive the flames and rocks
on that one)

I'm not sure what the extra functionality of that "next generation" DynAPI
would be.. it would just be programmed in another style but that's it, at
least as far as I can tell from the posts in this thread.

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

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Jordi 'IlMaestro'
> Ministral
> Verzonden: maandag 29 januari 2001 19:07
> Aan: dyn...@li...
> Onderwerp: Re: [Dynapi-Dev] Next Generation
>
>
> In a perfect future, the target of this API would be the current
> dreamweaver user. You should not need any programming skills to
> build pages using DynAPI. Discussing if this or that programming
> model is better makes sense when you are in a computer science
> forum but in this case, if overloading this already-bloated API
> with additional complexities does not result in a better
> cross-browser support or a better end-user ( read desinger )
> interface, then I'm against it.
>
> Sometimes the code is the objective, the goal of a project, and
> then it makes sense to discuss how should code behave and be
> structured. In this case the code is nothing but a tool: it has
> to be properly programmed, but that's enough.
>
>
> Henrik Våglin wrote:
>
> > About the current discussion on OO, JS, OOJS and the confusion
> on what they are:
> >
> > OO is the model.
> > OOM is the method.
> > OOP is the technique.
> >
> > Therefor JS is a tool of the prottyping OO technique. It's
> unnecessary to create a more classbased structure of what is
> essentially a merge of prototyping and class-inheritance (ie
> DynAPI). It's merely a question of approach wheter to use
> prototyping - which is more towards experimental development - or
> class inheritance. the only real different is wheter to allow for
> more unconditional extensability that is the default of
> javascript and which DynAPI is mostly today VS a more conditional
> class inheriting technique.
> >
> > Personally I vote for the previous and I think most others who
> are more designers at heart prefer it to remain so. The only
> reason to make DynAPI more class inheriting would be to attract
> more OOP developers (who generally are more used to
> class-inheritencing tools), which of course would be great for
> development, but distracts more from those who need the API more
> - the designers. Consider the folloowing...
> >
> > Developers don't need a new language as much as designer does.
> There's enough class-inheriting OOP tools around for developers.
> I also think Microsoft is moving out of range for designers with
> their new .NET structure which the new ASP+ currently in beta is
> part of. Is DynAPI OO (or next gen) to compete with .NET? I vote
> for keeping DynAPI structure developing as it is and remain a
> real API, not a programming semi-language!
> >
> > My plead is to focusing on targetting DynAPI for designers. A
> OO DynAPI might instead be bringing design enhancement for
> programmers to comprehand. In other words: keep it separated and
> focus more on different users, but of course all kind of exchange
> of knowledge is a good thing - so also keep a symbiotic
> relationship between the two (and maybe designers and developers
> will come to understand eachothers expertise areas more).
> >
> > Henrik Våglin [ hv...@ya... ]
> >
> > _________________________________________________________
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.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
>

In a perfect future, the target of this API would be the current dreamweaver user. You should not need any programming skills to build pages using DynAPI. Discussing if this or that programming model is better makes sense when you are in a computer science forum but in this case, if overloading this already-bloated API with additional complexities does not result in a better cross-browser support or a better end-user ( read desinger ) interface, then I'm against it.

Sometimes the code is the objective, the goal of a project, and then it makes sense to discuss how should code behave and be structured. In this case the code is nothing but a tool: it has to be properly programmed, but that's enough.

Henrik Våglin wrote:

> About the current discussion on OO, JS, OOJS and the confusion on what they are:
>
> OO is the model.
> OOM is the method.
> OOP is the technique.
>
> Therefor JS is a tool of the prottyping OO technique. It's unnecessary to create a more classbased structure of what is essentially a merge of prototyping and class-inheritance (ie DynAPI). It's merely a question of approach wheter to use prototyping - which is more towards experimental development - or class inheritance. the only real different is wheter to allow for more unconditional extensability that is the default of javascript and which DynAPI is mostly today VS a more conditional class inheriting technique.
>
> Personally I vote for the previous and I think most others who are more designers at heart prefer it to remain so. The only reason to make DynAPI more class inheriting would be to attract more OOP developers (who generally are more used to class-inheritencing tools), which of course would be great for development, but distracts more from those who need the API more - the designers. Consider the folloowing...
>
> Developers don't need a new language as much as designer does. There's enough class-inheriting OOP tools around for developers. I also think Microsoft is moving out of range for designers with their new .NET structure which the new ASP+ currently in beta is part of. Is DynAPI OO (or next gen) to compete with .NET? I vote for keeping DynAPI structure developing as it is and remain a real API, not a programming semi-language!
>
> My plead is to focusing on targetting DynAPI for designers. A OO DynAPI might instead be bringing design enhancement for programmers to comprehand. In other words: keep it separated and focus more on different users, but of course all kind of exchange of knowledge is a good thing - so also keep a symbiotic relationship between the two (and maybe designers and developers will come to understand eachothers expertise areas more).
>
> Henrik Våglin [ hv...@ya... ]
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev

not to get involved inanother browser-war (After wards)

Netscape made Javascript to what it is now.. so if they say so, I believe
them :-)

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

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Doug Melvin
> Verzonden: maandag 29 januari 2001 20:26
> Aan: dyn...@li...
> Onderwerp: Re: [Dynapi-Dev] Next Generation
>
>
> An if Netscrape says it it has to be correct?

The following code is generated by Dream WEaver for roll-overs.

I am firmly of the belief that the solution for the LoadPanel image =
problem
is in this code somewhere..
I'll take a crack at it later (If I haven't cracked myself yet)

Code:

function MM_findObj(n, d) { //v3.0
  var p,i,x;  if(!d) d=3Ddocument; =
if((p=3Dn.indexOf("?"))>0&&parent.frames.length) {
    d=3Dparent.frames[n.substring(p+1)].document; n=3Dn.substring(0,p);}
  if(!(x=3Dd[n])&&d.all) x=3Dd.all[n]; for =
(i=3D0;!x&&i<d.forms.length;i++) x=3Dd.forms[i][n];
  for(i=3D0;!x&&d.layers&&i<d.layers.length;i++) =
x=3DMM_findObj(n,d.layers[i].document); return x;
}

function MM_swapImage() { //v3.0
  var i,j=3D0,x,a=3DMM_swapImage.arguments; document.MM_sr=3Dnew Array; =
for(i=3D0;i<(a.length-2);i+=3D3)
   if ((x=3DMM_findObj(a[i]))!=3Dnull){document.MM_sr[j++]=3Dx; =
if(!x.oSrc) x.oSrc=3Dx.src; x.src=3Da[i+2];}
}

About the current discussion on OO, JS, OOJS and the confusion on what =
they are:

OO is the model.
OOM is the method.
OOP is the technique.

Therefor JS is a tool of the prottyping OO technique. It's unnecessary =
to create a more classbased structure of what is essentially a merge of =
prototyping and class-inheritance (ie DynAPI). It's merely a question of =
approach wheter to use prototyping - which is more towards experimental =
development - or class inheritance. the only real different is wheter to =
allow for more unconditional extensability that is the default of =
javascript and which DynAPI is mostly today VS a more conditional class =
inheriting technique.=20

Personally I vote for the previous and I think most others who are more =
designers at heart prefer it to remain so. The only reason to make =
DynAPI more class inheriting would be to attract more OOP developers =
(who generally are more used to class-inheritencing tools), which of =
course would be great for development, but distracts more from those who =
need the API more - the designers. Consider the folloowing...=20

Developers don't need a new language as much as designer does. There's =
enough class-inheriting OOP tools around for developers. I also think =
Microsoft is moving out of range for designers with their new .NET =
structure which the new ASP+ currently in beta is part of. Is DynAPI OO =
(or next gen) to compete with .NET? I vote for keeping DynAPI structure =
developing as it is and remain a real API, not a programming =
semi-language!

My plead is to focusing on targetting DynAPI for designers. A OO DynAPI =
might instead be bringing design enhancement for programmers to =
comprehand. In other words: keep it separated and focus more on =
different users, but of course all kind of exchange of knowledge is a =
good thing - so also keep a symbiotic relationship between the two (and =
maybe designers and developers will come to understand eachothers =
expertise areas more).

Henrik V=E5glin [ hv...@ya... ]

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

No flames coming from me, I agree 100%.

M.

-----Original Message-----
From: dyn...@li...
[mailto:dyn...@li...]On Behalf Of .:: OCB ::.
Sent: Monday, January 29, 2001 9:15 AM
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

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.

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

An if Netscrape says it it has to be correct?
----- Original Message -----
From: "Cameron Hart" <ca...@bi...>
To: <dyn...@li...>
Sent: Monday, January 29, 2001 6:23 AM
Subject: RE: [Dynapi-Dev] Next Generation

> netscape themselves refer both javascript and java as object-based
> languages. javascript they say is prototype-based, and java is
class-based.
> both are object-based.
>
> straight from the horses mouth
> http://developer.netscape.com/docs/manuals/js/client/jsguide/obj2.htm
>
> > -----Original Message-----
> > From: dyn...@li...
> > [mailto:dyn...@li...]On Behalf Of Eytan
> > Heidingsfeld
> > Sent: 29 January 2001 13:14
> > To: dyn...@li...
> > Subject: RE: [Dynapi-Dev] Next Generation
> >
> >
> > Lets really get the terms straight.
> >
> > Class-Oriented: You develop classes. You do this be using the prototype
of
> > an object. Then this object becomes basically a prototype, a
> > class and then
> > for inheritance an object says use this objects prototype and add these
> > members.
> > Object-Oriented: You develop classes by defining an interface and then
> > implementing this interface. To use this object you create a new object
> > based on this class. Inheritance is dealt with by saying I want to
inherit
> > this and this class. Then your new object has the same members as those
> > classes with pointers to their implementation.
> >
> > There is no PO only CO and OO the difference is inheritance and memory
> > management but since there is no memory management in JS there is no
> > difference but inheritance.
> > 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

Object Oriented indeed, as Dann mentioned, embraces both Class and
Prototyping.

Your stating that prototyping doesn't exist, but then you should take a
better look at what where doing with the DynAPI.. correct: Prototyping.
There might not be much info on prototyping out there on the net, but
javascript is actually using prototyping, not class-based.

Both class and prototyping fall under Object Oriented development. I don't
know what the definition of OO is, but I think it's just a global definition
of developing things using reusable-object code, under which both
class-based and prototype-based fall.

Also your previous mail stated "OO in JS or ECMA script is documented. If
you read carefully you will notice
that JS was designed as a Class Oriented language".. I'm pretty sure the
original Netscape implementation of javascript was build on Prototype-based
(as stated in there documentation)

And coming back to that ever lasting quest of mine, redoing inheritence, or
creating functions for it is not needed.. the way we are currently doing
widgets is how Javascript handles inheriting (with prototyping).. the same
structure and idea can be implemented to the DynLayer and DynDocument
objects (see Dynacore on howto).

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

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Eytan
> Heidingsfeld
> Verzonden: maandag 29 januari 2001 14:14
> Aan: dyn...@li...
> Onderwerp: RE: [Dynapi-Dev] Next Generation
>
>
> Lets really get the terms straight.
>
> Class-Oriented: You develop classes. You do this be using the
> prototype of
> an object. Then this object becomes basically a prototype, a
> class and then
> for inheritance an object says use this objects prototype and
> add these
> members.
> Object-Oriented: You develop classes by defining an interface and then
> implementing this interface. To use this object you create a
> new object
> based on this class. Inheritance is dealt with by saying I
> want to inherit
> this and this class. Then your new object has the same
> members as those
> classes with pointers to their implementation.
>
> There is no PO only CO and OO the difference is inheritance and memory
> management but since there is no memory management in JS there is no
> difference but inheritance.
> 8an
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>

netscape themselves refer both javascript and java as object-based
languages. javascript they say is prototype-based, and java is class-based.
both are object-based.

straight from the horses mouth
http://developer.netscape.com/docs/manuals/js/client/jsguide/obj2.htm

> -----Original Message-----
> From: dyn...@li...
> [mailto:dyn...@li...]On Behalf Of Eytan
> Heidingsfeld
> Sent: 29 January 2001 13:14
> To: dyn...@li...
> Subject: RE: [Dynapi-Dev] Next Generation
>
>
> Lets really get the terms straight.
>
> Class-Oriented: You develop classes. You do this be using the prototype of
> an object. Then this object becomes basically a prototype, a
> class and then
> for inheritance an object says use this objects prototype and add these
> members.
> Object-Oriented: You develop classes by defining an interface and then
> implementing this interface. To use this object you create a new object
> based on this class. Inheritance is dealt with by saying I want to inherit
> this and this class. Then your new object has the same members as those
> classes with pointers to their implementation.
>
> There is no PO only CO and OO the difference is inheritance and memory
> management but since there is no memory management in JS there is no
> difference but inheritance.
> 8an
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev

2000	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (75)	Nov (252)	Dec (418)
2001	Jan (659)	Feb (1039)	Mar (870)	Apr (235)	May (329)	Jun (251)	Jul (123)	Aug (119)	Sep (67)	Oct (194)	Nov (535)	Dec (133)
2002	Jan (122)	Feb (24)	Mar (29)	Apr (28)	May (16)	Jun (20)	Jul (11)	Aug (12)	Sep (13)	Oct (14)	Nov (23)	Dec (19)
2003	Jan (28)	Feb (170)	Mar (288)	Apr (211)	May (126)	Jun (166)	Jul (131)	Aug (102)	Sep (211)	Oct (301)	Nov (22)	Dec (6)
2004	Jan (14)	Feb (16)	Mar (7)	Apr	May (8)	Jun (25)	Jul (21)	Aug (2)	Sep (7)	Oct	Nov (2)	Dec (1)
2005	Jan (4)	Feb (2)	Mar (14)	Apr (24)	May (3)	Jun (7)	Jul (30)	Aug (5)	Sep (1)	Oct (3)	Nov	Dec (1)
2006	Jan	Feb	Mar	Apr (1)	May	Jun	Jul	Aug	Sep (4)	Oct	Nov	Dec

dynapi-dev Mailing List for DynAPI (Page 246)

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