Hi all,
I just noticed Eytan's widget spec proposal is on the site:
http://dynapi.sourceforge.net/doccenter/index.php?EytansWidgetSpec
I had hoped a widget-spec would clear up confusion around the different
existing models, and simplify existing code in use, by dropping things like
getSubClass() if we never actually used them.
This spec doesn't.
But I should add that I don't know enough about OO programming to judge if
the proposal could be beneficial, or add more confusion than benefit.
As I see it, we currently have:
1) DynObject.
2) this is inherited by DynDocument, and DynLayer.
3) When we make a widget, we inherit from Dynlayer.
4) Complex widgets could inherit from a widget, subclassed off DynLayer.
the proposal specs suggest putting a TWidget class between step 2 and 3. It
seems it would be a wrapper for non-graphical widgets...
So does TWidget actually replace step step 2?
Is the idea that we create a non-graphical canvas to build widgets like
glide.js, or pathanim.js??
And, for graphical widgets we would have TComponent, which *contains* a
dynlayer, without inheriting all it's properties, *but* inherits all
properties from TWidget, which are basically those of Dynlayer, with a
classname added.
I see Tcomponent looks quite useful, with it's added functionality, but it's
just a widget isn't it? what's the difference between ButtonImage inheriting
from Dynimage, that inherits from dynlayer.
Or
ButtonImage inheriting from Dynimage, that inherits from TComponent
inheriting from TWidget, that inherits from dynLayer (or not?), which
inherits from DynObject.
As you see I am more than a little confused about the logic behind this, I
hope it's for performance reasons, and not to build an object model that
closely resembles that of another language.
I see the same thing popping up in Dan's new code, where Java syntax is
being implemented, seemingly for the simple reason that the author feels
most at home with this syntax.
In my opinion, the only object model we should be closing in on, in our
structure and naming, is DOM2. (note I'm not saying DOM is a language or
anything)
But as I said at the start, I am not very well versed in other OO oriented
languages, so I might be missing the advantages.
Personally, what I thought a widget spec proposal might look like, would be
a collection of syntactical rules - like a naming convention.
For instance a few ideas:
* The constructor is always made using the function system:
function myWidget(){
}
Not using " myWidget= new Object() ", or " myWidget=[ ] ", or anything.
* To subclass, we use the name of what we're subclassing off, so:
this.dynlayer=Dynlayer
this.dynlmage=DynImage
Not, this.superclass=Dynlayer.
* eventlisteners are placed inside the constructor, not as seperate
functions (or not?)
* functions are prototyped onto the widget, not built inside the
constructor, and not using the " : " syntax.
Just some ideas...
Also one newbee question, is inheriting, and subclassing synonymous in this
context?
That should be enough to get the ball rolling :o)
Cheers,
Richard.
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://www.mail-archive.com/[email protected]/
