I've already split the DynObject into 3 separate objects:
DynObject -> EventObject -> DynElement
DynObject now has only a couple methods, setID, new add/removeMethod(), inherit(),
getClassName(), getClass().
EventObject inherits from DynObject and adds the eventlistener system. You can now
create an empty object that can invoke events and have event listeners attached,
example:
myevent = new EventObject();
myevent.onhello = function() {alert('Hello!')}; // this is a new syntax for quickly
adding event handlers
myevent.invokeEvent("hello");
The inherit() method of DynObject is really simple. In the constructor of a widget
you replace:
function MyObj() {
this.DynLayer = DynLayer;
this.DynLayer(args)
}
// with:
function MyObj() {
this.inherit("MyObj","DynLayer",args); // perhaps not final syntax, still
playing around with it
}
// you still need to manually assign the MyObj.prototype = new DynLayer;
This will add a common class reference. The getClass() method before only returned
the constructor which is totally useless because the constructor is always DynObject.
Now we have the method getClass() which will return the proper constructor, will have
references to each of the objects it inherited from.
None of these changes are manditory or necessary to inherit DynLayer. But it should
be used within the DynAPI - I'm running into cases where it's usefull (like we no
longer need the .isDynLayer and .isDynDocument variables anymore).
Non-GUI objects don't have to inherit from any object, why should they? The only
cases where it'd be useful is if you need a unique ID, or would like to make use of
the getClass() method, or if you need events then inherit from EventObject. It's all
up to the developer how he wants to handle his code.
Regards,
Dan Steinman
On Tue, Nov 20, 2001 at 10:00:17AM -0500, Laszlo Teglas wrote:
> I believe what 8an is trying to say is, there are classes that are not
> visual objects, but should be part of the inheritance hierarchy at some
> level. (i.e. Dan's layout manager should probably be a class that inherits
> certain properties from DynObject, but not from DynLayer, because
> DynLayerManager is not a visual object, but DynLayer is) There are a lot of
> other non-GUI classes that would be useful and should be part of the
> inheritance hierarchy as a widget but not necessarily as a GUI component.
> This is much the same way that Java is set up.
>
> I do agree this model is cleaner, however this would be a major overhaul of
> the entire DynAPI.
>
> NanoFace =;^)
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Michael
> Pemberton
> Sent: November 20, 2001 7:09 AM
> To: Dynapi-Dev
> Subject: Re: FW: [Dynapi-Dev] Fw: widgetspec
>
>
> But doesn't this simply result in abstraction which, in the very theory of
> the
> process, is just wrapping one function in another.
>
> One minute you were suggesting that we remove the dynlayer abstration and
> manipulate the layers directly, next you want to add extra levels of code.
> It
> is becoming confusing with the two theories coming from the same person.
>
> I think we need to focus on getting the existing objects / structures
> working in
> a fashion that allows for the project to grow. Instead of constantly going
> back
> to the drawing board. If you want to rebuild the structure, do so as a side
> project in your spare time and come back when you have a more substantial
> case.
>
> All this speculation is just clouding the issue. And before people start
> flaming me and accusing my off saying one thing and doing another, I have
> done
> exactly what I expect of others. I have in no way forced my version onto
> the
> developers / users of the DynAPI. Nore have I requested that they move away
> from the standard version.
>
> I have no problem with people developing a customised version. But it is a
> bit
> hard to expect other developers to make the jump to a new structure without
> seeing it in action. As someone who has done the whole restructure process
> and
> knows how long it takes, it is almost impossible to redesign the structure
> (either internal or external) and still keep the same functionality and ease
> of
> use.
>
> It all comes down to a balance. I had the time and was willing to put the
> hours
> in. However, it took almost 4 months of work to get the code back up to the
> same level as te official version. If anyone wants to reduce this time by
> using
> additional developers, by all means, go ahead. But you need to give more
> info /
> examples of what you want. The DynAPI is too developed and too established
> to
> start redesigning on a whim.
>
> --
> Michael Pemberton
> [EMAIL PROTECTED]
> ICQ: 12107010
>
>
>
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> [EMAIL PROTECTED]
> http://www.mail-archive.com/[email protected]/
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> [EMAIL PROTECTED]
> http://www.mail-archive.com/[email protected]/
_______________________________________________
Dynapi-Dev mailing list
[EMAIL PROTECTED]
http://www.mail-archive.com/[email protected]/
