tinyJS-Toolkit beta

[Edgar Ehritt]

Re:

Nur so viel, als dass der Parameter den Namen der Callback-Funktion übergeben soll - im Moment ist das gleichermaßen Konvention wie Abkürzung. Wie schon gesagt, plane ich, die Fähigkeit zu integrieren, unbenannte Funktionen vorübergehend zufällig zu benahmen, um sie als Callback zu übergeben (ähnlich wie bei jQuery).

Manchmal nutze ein Serverscript, was anhand des query strings die Komponenten für das nachzuladenden Javascripte zusammensucht. Wenn Du also so willst, aus der Werkstatt die tatsächlich benötigten Werkzeuge herausrückt. Vielleicht ließe sich das Ganze mit einem wrapper ja kombinieren:

t.j =function(u,t){  
    var s=document.createElement('script');  
  
    s.type='text/javascript';  
    s.src=u+(c?'?c='+c:'');  
    document.body.appendChild(s);  
  
    if (t) { window.setTimeout(function() { document.body.removeChild(s); }, t); }  
}  
t.js=function(u, c, t) {  
    u=u+(c?'?c='+c:'');  
    t.j(u,t);  
};

Was t.a betrifft,… Als Zielgruppe für das Toolkit sind durchaus Entwickler gemeint, die wissen, was sie tun.
Und da denke ich, dass Du das Definieren eigener Methoden unnötig in den separaten code auslagerst, wo sich t.a doch so schön anbietet.

Man könnte natürlich alternativ auf das Belegen der Event-Methoden verzichten und stattdessen das XHR-Objekt zurückgeben. Ist es das, was Du meinst?

Dass Requestobjekt verfügbar zu machen, wäre eine Variante. Die Lösung die Du jetzt aber hast, eigene Methoden zu definieren, ist so schön, dass ich eben die Einschränkung nicht verstehe. Bei updates der vordefinierten Eigenschaften/Methoden wärst Du einerseits ohne weitere Anpassungen kompatibel. Nicht dass das hier als wirkliches Argument hinreicht, weil der Code wirklich schön einfach ist. Andererseits könnte man eben so eigenen Schnickschnack wirklich gelungen einfach integrieren.

Gruß aus Berlin!
eddi