I usually try to stay out of the discussions about the DynAPI but this time
I could not...
Just like some people have mentioned, the addCodeToMethod is a really bad
idea. A better idea is ofcourse to redefine the method. The following line
could be replaced by a much safer way.
Methods.addCodeToMethod("DynDocument.prototype.addEventListener","if(this.ha
sEventListeners) this.captureKeyEvents()",true);
DynDocument.prototype._beforeKeyEvent_addEventListener =
DynDocument.prototype.addEventListener;
DynDocument.prototype.addEventListener = function (oListener) {
this._beforeKeyEvent_addEventListener(oListener);
if (this.hasEventListeners)
this.captureKeyEvents();
};
This code is much safer and smaller (if a general funtion is created to make
it easier to reuse).
Using string manipulation is not a good idea because not only can one not
guarantie that the toString() method returns something meaningful but it
also destroys the variable scope for the old function. I'll show a simple
example showing what I mean about the scope (not a typical case but simple):
function createFunction() {
var x = 5;
return function () {
return x;
};
}
foo.method = createFunction();
if you then later reevaluate the string for the function in the following
context you you changed the semantics for the function.
var x = "It even changes type";
Methods.addCodeToMethod("foo.method","alert(x);",false);
I hope this is enough for you to rethink your decission.
erik arvidsson
http://webfx.nu
----- Original Message -----
From: "Jordi - IlMaestro - Ministral" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, March 13, 2001 8:09 AM
Subject: Re: [Dynapi-Dev] DynAPI X
> Well yes if any of my computer engineering teachers could see that code,
they'd
> throw me through the window. If I had come up with a better idea, then I
would have
> chosen that one. The fact here was that we needed to add functionalities
to certain
> pieces of code depending on what was loaded. However, it is simply
intended to add
> lines of code ( typically function calls ) to an already defined method. I
don't
> provide this as a generic coding practice, nor expect people to start
modifying ifs
> statements on the fly depending on what browser you're using. Then it will
become a
> nightmare.
>
> This function, being as dangerous as it is, if used with common sense
allows to get
> rid of all those anoying additons that check for a module being loaded. It
is not
> intended to be used that often. So far only when mouse event capturing
must be
> inserted into layer creation and little more. Notice that the DynAPI
object
> provides methods for attaching code into the onload event, which is what
extensions
> such as inline will use. I could have had extensions modify the onload,
onunload
> and onresize via the addCode method(), but seeing that it would be a
common thing
> to do, I prefered to provide anot-so-dangerous method, while leaving the
dangerous
> code reserved for 'internal usage'.
>
> Lesson: try not to use Methods.addCodeToMethod() as a common practice.
>
> Daniel Aborg wrote:
>
> > Jordi - IlMaestro - Ministral wrote:
> > > Fift: i have included a generic method that allows to add lines of
code to
> > > already defined methods. So if you look at dynlayer.js and you can't
see any
> > > eventcapturing code, don't be puzzled. If you open mouse.js ( where
the
> > > mouseevents are now ) you will see a call to
> > > addCode("createLayer","this.captureMouseEvents()"). This way of
working makes
> > > it possible for optional files ( mousevents ) to add stuff to already
defined
> > > methods, without having to have ugly if(mouseEvent)
this.captureMouseEvents()
> > > lines and such. Besides, this way we have eradicated crossreferences
between
> > > files.
> >
> > Having given this a few minutes of thought, this is something which
> > scares me. Having the possibility of your function being modified by any
> > other package or extension is a horrible thought, because it means you
> > have no way of telling in what ways your function might change
> > dynamically during loadup. It seems like a typical opening for
> > maintainance nightmare, introducing the possibility for bugs caused by
> > other packages which aren't synchronised with your function. Imagine
> > having a function which is possibly modified by 17 other packages in
> > unpredictable ways during loadup depending on what packages you load,
> > without having any knowledge of /whether/ your function will be modified
> > by anyone in the future, /how/ it will be modified, /when/ it will be
> > modified, and so on. You could break any code anywhere just by doing a
> > simple change/bugfix to your function without ever having any idea of
> > what you could break, simply cause you can't know who will modify your
> > function in the future, how it will be modified, and so on. It totally
> > removes encapsulation borders around function implementations. Shiver!
> >
> > I might be overly cynical, although it seems to me that this would call
> > for a system for how you can modify existing functions so the functions
> > know how they might be modified and can take that into account, and
> > perhaps additionally for some way of saying that a function can't be
> > modified. Basically, some kind of control framework to let the modified
> > functions control how and where it's modified. I assume you're doing
> > this with string manipulation, so it shouldn't be hard to handle that.
> >
> > Anyway, just my thoughts on the matter. I might have gotten a bit
> > carried away. :)
> >
> > Cheers,
> >
> > Daniel
> >
> > --
> > Daniel Aborg <[EMAIL PROTECTED]>
> > T: 0207 445 447 M: 07720 29 44 40
> >
> > _______________________________________________
> > 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
