From: Jordi 'I. M. <jmi...@or...> - 2000-12-05 15:50:10
|
I have given a look to the code. I haven't tried it yet, and I can't tell if it works or not, but I would suggest that the Superclass is included as a tool rather than become mandatory. I think the API should stay simple, and so should stay a widget interface. I'm running into several problems when trying to have complex object structures. Hopefully the Superclass will solve them. However, there are lots of things that can be achieved using simple prototyping. There has been some discussion lately about OOP, OO, being formal, being strict, etc, etc. I'd like to point out that we are talking Javascript here. Instead of trying to make it more Java-like I think the efforts should move towards designing our widgets in a prototype way. Thinking our object structures as if we were programming Java and then finding a way to make them work under Javascript is not the way to go, IMHO. I'll try to design my object structures as if I was using a prototype-inherited language, which is what I am using. I do recognise the value of the superclass and I congratulate Brandon, but again this is not Java and I don't want it to be. My 2 euros Brandon Myers wrote: > This is my implementation of a SuperClass (Top-level class) that takes > care of everything that you want. It does not require maintaining of > an array of inheritable methods, other than the methods which are > "static" to the constructor (Not part of the prototype chain) It also > maintains changes to the default object methods, such as .valueOf, and > .toString. It also maintains a list of instances for each class, and > has methods to delete/destroy objects which can be overriden to > perform special functions when destroying complex objects. Also, it > takes care of many other problems that I have found. I have used it in > developing a split API. My revision of the API is split for each > browser, and for each object type. The SuperClass is a generic > top-level that does not require that the next level object be a GUI > object, such as DynAPI. I have been able to seperate event based > objects with non event GUI objects. DynLayer no longer has any event > structure. This increased the total number of layers that can be > placed on a page, since there are some object that really don't need > events. There are GUI objects that are only for events and do not > inherit any Animation functions. Since animation functions can be > applied to another class, as an extention, which the SuperClass then > passes down the inheritance chain. Now, two lines will have to be > added to the DynAPI.loadHandler method: if (SuperClass) > SuperClass.extendClasses(); > Add this before creating any instances of any objects in the > loadHandler. (Such as before creating the DynDocument, and before > calling any events) Maybe even placed at the first line. Ok.. also > included is a sample usage with a borderFactory class.Add the > following line at the end of DynLayer: > SuperClass.inherit(DynLayer); Then, the borderFactory should > work. Assign a border to ANY subclass of > DynLayer: myBorder=BorderFactory.getBorder("SimpleBevel",2,"Black"); button=new > DynLayer("MyButton1",50,50,100,50);button.setBgColor("Silver");button.setBorder(myBorder); > // You could also do: > myBorder.assignTo(button)DynAPI.document.addChild(myBorder); Tada.. > it's done.This is a VERY effective border, and works with ANY subclass > of DynLayer. It's large only because of all the comments, and the > spacing. It could be crunched down to less than half it's current > size.It might take a little more work to get everything up to speed, > but with the stability I have achieved, and speed increase, I feel > this is a great asset to the community. > > ----- Original Message ----- > From: Eytan Heidingsfeld > To: dyn...@li... > Sent: Sunday, December 03, 2000 7:31 AM > Subject: [Dynapi-Dev] Multiple Inheritence > I wrote a function inherit that can do multipule > inheritence. The only problem is that any methods/properties > that you want to let other objects inherit must be included > in an array called oInterface. I know this is all vague. If > anyone want the code just email me offlist.8an > |