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 ([EMAIL PROTECTED])
Software ontwikkelaar
Oberon Informatiesystemen b.v.
http://www.oibv.com
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dynapi-dev
