RE: [Dynapi-Dev] Next Generation

[David Gerding - Columbia College Chicago]

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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Pascal
Bestebroer
Sent: Monday, January 29, 2001 1:14 PM
To: [EMAIL PROTECTED]
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
[EMAIL PROTECTED]
http://www.dynamic-core.net

> -----Oorspronkelijk bericht-----
> Van: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]Namens Jordi 'IlMaestro'
> Ministral
> Verzonden: maandag 29 januari 2001 19:07
> Aan: [EMAIL PROTECTED]
> 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 [ [EMAIL PROTECTED] ]
> >
> > _________________________________________________________
> > Do You Yahoo!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>


_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev


_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev