Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 15 von 22
  1. #1
    bis
    bis ist offline Routinier
    registriert
    09-09-2009
    Beiträge
    459

    Beispiel für objekt-orientiertes JavaScript mit Joose

    Aus einer längeren Diskussion hier (Image maps/areas - Unterschiede IE / FF) ergab sich das Interesse von ein schlauer an einem Beispiel aus meiner Arbeit, das ich hier anbei veröffentliche.

    Hier ist ein konkretes Beispiel bestehend aus drei Klassen:

    Der generischen Superklasse ECArea, sowie über den beiden konkreten Modell-Klassen ECAreaArt und ECAreaPage die beide, wie man sehr leicht erkennen kann, jeweils sehr klein sind, weil sie den größten Teil von der Super-Klasse erben.

    Ich denke, daß es für die hier lesenden Javascript-Entwickler angebracht wäre, wenn ich den Stil etwas kommentiere. Es handelt sich dabei überwiegend nicht um meinen persönlichen Stil (der ist allenfalls in der Dokumentation und in bestimmten Namens-Konventionen zu finden), sondern um einen generellen Stil, der unter Smalltalk-Entwicklern Standard ist. Wer diesen Standard nicht einhält, der ist ein sehr schlechter Smalltalk-Entwickler.

    Dazu gehört primär, daß der Code in relativ viele einzelne Klassen und in möglichst sehr viele kleine Methoden zerlegt wird. In Smalltalk gilt die Regel, daß eine Methode, die nicht vollständig im Editor-Fenster des Browsers zu sehen ist, in der Regel zu groß ist. Das bedeutet, daß eine Methode typischerweise unter fünf bis maximal 10 Zeilen umfaßt. Dies ist ein gänzlich anderer Programmie-Stil, als er den meisten anderen Sprachen üblich ist. Dieser hat jedoch ganz eindeutige Vorteile und ich bitte alle herzlich, mir eine Diskussion darüber zu ersparen. Es ist so! Basta!

    Bezüglich der Namenskonventionen habe ich einen eigenen Stil entwickelt, der bisher von den meisten meiner Programmierer nicht geliebt wurde, weil er zwar etwas schwerer zu lesen ist, dafür aber leichter zu finden. Dies hat mit den konkreten Bedingungen eines Klassen-Browsers zu tun und mit der Tatsache, daß ein guter objekt-orientierter Programmierer wesentlich mehr Zeit damit zubringt, vorhandenen Code zu suchen, um ihn wieder zu verwenden, als neuen Code zu schreiben.

    Dies ist natürlich in Javascript vorerst noch viel Theorie, weil die vorhandenen Werkzeuge diese Vorgehensweise nicht nur nicht unterstützen, sondern gerade zu boykottieren. Dies ist auch der Grund, weshalb ich File-Editoren schlecht weg Scheiße finde.

    Teil dieser starken Dezentralisierung von Code ist es auch, daß man logische Abfragen, die über den Code verstreut sind, an zentralen Stellen zusammenfaßt. Siehe als Beispiel die von mir häufig verwendete Funktionen isNilOrEmpty oder copyEnclosedInQuotes. Natürlich kann man darüber diskutieren, der Aufruf von Funktionen (die in Smalltalk technisch Pointer sind) kostet jedoch keinerlei Zeit und deswegen ist der modulare Aufbau wesentlich vorteilhafter als die üblichen Vorgehensweise, wo man solche logische abfragen an zahllosen Stellen verteilen würde. Das geht bei mir soweit, daß sämtliche bilden die statischen Werte (z. B. Datei-Änderungen) grundsätzlich sämtlich in einer zentralen Klasse, die nur einen einzige Instanz hat, zusammengefaßt ist.

    Ein praktisches Beispiel in dem folgenden Code ist:
    isAreaForPage: function(){
    return (this.clType = 'apage');},

    Die typische Javascript-Programmierer würde diese Abfrage wahrscheinlich überall dort einbauen, wo sie benötigt wird. Dies halte ich (und mit mir wohl alle Smalltalk-Programmierer) für einen Fehler. Solche Abfragen dürfen nur zentralisiert an einer einzigen Stelle erfolgen, die dann über einen Funktion-Aufruf genutzt wird.

    In dieser Art gibt es mehrere Klassen. Im Code ist z. B. cfg für die Konfiguration enthalten oder tr für das Übersetzungs-Modul.

    InstVar clKey macht Instanzen besser identifizierbar im Debugger, weil man damit sofort die Klasse erkennen kann. Das wird of auch polymorph abgefragt und konkret verwendet.

    Es nervt mich ungeheuer, daß ich z.B. bei Ext im Debugger oder DOM nicht immer klar sehen kann, von welcher Klasse eine Instanz ist. Das ist damit vom Tisch.

    Ferner habe ich mich entschlossen, Array oft ab 1 zu indizieren (nicht 0, das ist m.M.n. C-Schrott), was leider nicht konsequent durchgehalten ist. In vielen Fällen verwende ich jedoch eine eigene Klasse ECOrderedCollection, die die (meiner Meinung nach) negativen Besonderheiten des Arrays in Javascript kapselt und dies mehr kompatibel macht zu Smalltalk.

    Der Umfang der polymorphen Methoden ist derzeit leider noch relativ geringen, u. a. auch freilich erst vor ca. sechs Wochen damit begonnen habe, Joose einzusetzen und das pure Javascript davor war mir noch zu unbekannt, um damit Verordnungen zu realisieren (abgesehen von der mir dabei widerstrebenden Syntax).

    Es sei daran erinnert, daß dieses händisch erstellte Javascript für mich nur eine Übergangslösung darstellt, bis ich die Werkzeuge habe, um Javascript aus Smalltalk zu generieren.

    Anregung, Kritik und Kommentare willkommen, jedoch bitte nicht zum Stil der modularen Programmierung, denn darüber wäre jede Diskussion absolute Zeitverschwendung. Dies ist in der objekt-orientierten Welt außerhalb jeder Diskussion und seit rund 20 Jahren "state-of-the-art" und ich halte diese Welt für die konzeptionell und technologisch unbestreitbar immer noch mit großem Abstand beste aller mir bekannten "Welten" der Software-Entwicklung.


    Wie üblich diktiert per Spracherkennungs-Software, daher nicht ganz fehlerfrei. Ich bitte um Nachsicht.
    Angehängte Dateien Angehängte Dateien
    Geändert von bis (24-01-2010 um 19:25 Uhr)

  2. #2
    ein schlauer ist offline Lounge-Member
    registriert
    18-08-2004
    Beiträge
    14.671

    AW: Beispiel für objekt-orientiertes JavaScript mit Joose

    Ohne jetzt in die Details zu gehen, dafür fehlt mir gerade die Zeit, es fällt aber ein grosses Manko auf, du denkst in HTML Code, das ist aber in JS ein schwerer Fehler und führt zu den Problemen in dem anderen Thread. Du solltest auf jeden Fall in JS mit Knoten und Elementen arbeiten (wie kkapsner und ich dir es im anderen Thread schon gezeigt hatten) . Dadurch hast du elegant Zugriff auf alle Eigenschaften und kannst schnell das Objekt umhängen, kopieren und das Aussehen verändern.

    Das Zweite, was du auch ansprichst und was wir dir auch schon in einer vergangenen Diskussion gesagt hatten, isNilOrEmpty() ist eine weitestgehend überflüssige Funktion. Ein if(!variabel) entspricht if( isNilOrEmpty(variabel)) und ist lesbarer, wenn man das Ausrufezeichen als "not" liest.

    Aber was auch auffällt, die von mir erwähnten Nachteile von Joose. Neben dem sehr aufgeblähten Konstruktoren, musst ausschließlich mit öffentlichen Methoden und Attributen arbeiten. Dabei böte JS die Möglichkeit private Variabeln und priviligierte Methoden zu verwenden. Aber das ist Geschmackssache, wie OO man in JS programmiert möchte, zumal diese Methode den Vorteil hat, dass sie etwas schneller ist.

    Eine genaue Analyse folgt später - wenn bis dahin nicht unser echte Experte sich dazu ausgelassen hat

  3. #3
    bis
    bis ist offline Routinier
    registriert
    09-09-2009
    Beiträge
    459

    AW: Beispiel für objekt-orientiertes JavaScript mit Joose

    Zitat Zitat von ein schlauer Beitrag anzeigen
    es fällt aber ein grosses Manko auf, du denkst in HTML Code, das ist aber in JS ein schwerer Fehler und führt zu den Problemen in dem anderen Thread. Du solltest auf jeden Fall in JS mit Knoten und Elementen arbeiten (wie kkapsner und ich dir es im anderen Thread schon gezeigt hatten) . Dadurch hast du elegant Zugriff auf alle Eigenschaften und kannst schnell das Objekt umhängen, kopieren und das Aussehen verändern.
    Das ist richtig!

    Diese Sicht des DOM habe ich heute erst (aus dem anderen Faden) gelernt. Das widerspricht zwar nicht meiner bisherigen Implementierung, würde und wird aber dennoch einiges ändern. Eine erste neue Methode von heute ist im Beispiel schon drin. Wird von Page aufgerufen, wo dann das DOM manipuliert wird.

    Das sollte später wohl in gesonderte Klassen ausgelagert werden. Aber permanentes Refaktoring ist bei OO üblich. Niemand plant am Anfang die Endlösung.

  4. #4
    bis
    bis ist offline Routinier
    registriert
    09-09-2009
    Beiträge
    459

    AW: Beispiel für objekt-orientiertes JavaScript mit Joose

    Zitat Zitat von ein schlauer Beitrag anzeigen
    Das Zweite, was du auch ansprichst und was wir dir auch schon in einer vergangenen Diskussion gesagt hatten, isNilOrEmpty() ist eine weitestgehend überflüssige Funktion. Ein if(!variabel) entspricht if( isNilOrEmpty(variabel)) und ist lesbarer, wenn man das Ausrufezeichen als "not" liest.
    Mein Ziel war es, eine polymorphe Abfrage zu haben. Das ist Dein Beispiel nicht.

    Es ist einfach schlecht, wenn ich bei einer solchen Abfrage wissen muß, welche Bedingungen (Klassen) vorkommen könnten. Das ist auch anfällig bei Änderungen.

    Darin ist JS einfach schlecht konzipiert. In Smalltalk kann ich viele Messages an absolut alle Arten von Objekten (= InstVar Inhalten, denn dort is alles ein Objekt) senden. Die verstehen das alle.

    Das war mein Ziel. Und für lesbar halte ich das "!" sicher nicht. Einfach unlogisch. In Smalltalk ist das z.B.: ifTrue[block] oder ifFalse[block] und das versteht jeder (InstVar und Leser).

  5. #5
    tsseh ist offline Foren-Gott
    registriert
    19-05-2008
    Beiträge
    5.667

    AW: Beispiel für objekt-orientiertes JavaScript mit Joose

    Zitat Zitat von bis Beitrag anzeigen
    Der generischen Superklasse ECArea, sowie über den beiden konkreten Modell-Klassen ECAreaArt und ECAreaPage die beide, wie man sehr leicht erkennen kann, jeweils sehr klein sind, weil sie den größten Teil von der Super-Klasse erben.
    du tust so, als hättest du die oo erfunden. das ist normales vorgehen. nichts besonderes.

    Zitat Zitat von bis Beitrag anzeigen
    Dazu gehört primär, daß der Code in relativ viele einzelne Klassen und in möglichst sehr viele kleine Methoden zerlegt wird.
    das ist auch standard. nur das

    Code:
    tagStartWithName: function(){
    		return this.tagStart() + this.tagName() + this.tagEqu() + this.mapName + '>';
    	},
    //Various tags
    	tagName: function(){
    		return 'name';},
    	tagEqu: function(){
    		return '=';},
    	tagStart: function(){
    		return '<map ';},
    	tagEnd: function(){
    		return '</map>';}
    ist vollkommen übertrieben. (ausser das wären überschreibungen einer basisklassen die diese funktionen für mehrere ableitungen verwendet, danach sieht es aber nicht aus)
    wozu gibt es tagStartWithNameForYN und tagStartWithName? warum 2 funktionen für ein und das selbe von aussen gesteuert? warum ist das wissen über YN (was auch immer das ist) nicht in der klasse.
    viel mehr will ich mir jetzt eigentlich auch nicht ansehen.
    vielleicht noch
    Code:
            areaCoordsArr:			{is:   "rw"},	//coordinates data as array
            areaCoords:				{is:   "rw"},	//coordinates data inside quotes
            areaCoordsZoomed:		{is:   "rw"},	//coordinates data inside quotes in curr zoom
            areaCoordsNet:
    wenigstens die 1. beiden variablen hören sich für mich nach doppelter datenhaltung und damit möglicher inkonsistenz an.


    Zitat Zitat von bis Beitrag anzeigen
    der Aufruf von Funktionen (die in Smalltalk technisch Pointer sind) kostet jedoch keinerlei Zeit und deswegen ist der modulare Aufbau wesentlich vorteilhafter
    ? ein funktionsaufruf kostet immer zeit, es sei denn es gibt in ST so etwas wie inlining.

    Zitat Zitat von bis Beitrag anzeigen
    Ein praktisches Beispiel in dem folgenden Code ist:
    isAreaForPage: function(){
    return (this.clType = 'apage');},
    redest du über den zugriff von aussen? clType sollte ausserhalb der klasse gar nicht sichtbar sein.

    Zitat Zitat von bis Beitrag anzeigen
    Ferner habe ich mich entschlossen, Array oft ab 1 zu indizieren (nicht 0, das ist m.M.n. C-Schrott), was leider nicht konsequent durchgehalten ist. In vielen Fällen verwende ich jedoch eine eigene Klasse ECOrderedCollection, die die (meiner Meinung nach) negativen Besonderheiten des Arrays in Javascript kapselt und dies mehr kompatibel macht zu Smalltalk.
    ??? nicht nur unsinnig, sonder gefährlich.

  6. #6
    bis
    bis ist offline Routinier
    registriert
    09-09-2009
    Beiträge
    459

    AW: Beispiel für objekt-orientiertes JavaScript mit Joose

    Zitat Zitat von hesst Beitrag anzeigen
    du tust so, als hättest du die oo erfunden. das ist normales vorgehen. nichts besonderes.
    Dann hast Du meinen Text nicht richtig gelesen. Ich habe in fast allen Libs sehr viel anderes bisher gelesen. Wenn das für Dich "normal" ist, prima. Für die meisten anderen JSler scheint es das nicht zu sein.

    Zitat Zitat von hesst Beitrag anzeigen
    ist vollkommen übertrieben. (ausser das wären überschreibungen einer basisklassen die diese funktionen für mehrere ableitungen verwendet, danach sieht es aber nicht aus)
    Darüber könnte man sicher diskutieren.

    Zitat Zitat von hesst Beitrag anzeigen
    wenigstens die 1. beiden variablen hören sich für mich nach doppelter datenhaltung und damit möglicher inkonsistenz an.
    Mag sein. Das ist "work in progress". Keine Habilitation.

    Zitat Zitat von hesst Beitrag anzeigen
    ? ein funktionsaufruf kostet immer zeit, es sei denn es gibt in ST so etwas wie inlining.
    Keine relevante Zeit. VisualWorks hat eine Art von Precompiling. Frag mich nicht, wie das funzt. Extrem schnell reicht mir. es gibt reichlich Tests, die eindeutig nachweisen, daß Methoden-Aufrufe nicht merkbar langsamer sind als direkt verwendeter Code. Wie das in JS ist, weiß ich (noch) nicht.

  7. #7
    ein schlauer ist offline Lounge-Member
    registriert
    18-08-2004
    Beiträge
    14.671

    AW: Beispiel für objekt-orientiertes JavaScript mit Joose

    Zitat Zitat von bis Beitrag anzeigen
    Mein Ziel war es, eine polymorphe Abfrage zu haben. Das ist Dein Beispiel nicht.
    Natürlich ist es das, deine ist es nicht.

    Polymorphismus ist JS kein Problem und du musst bei if(variabel) oder eben if(!variabel) nicht Wissen, was für ein Typ variabel ist. Wenn es ein Objekt ist, musst du die Methode toString() überschreiben oder implementieren.

    Les' dir mal durch, wie JS funktioniert: http://bclary.com/2004/11/07/ecma-262.html

  8. #8
    bis
    bis ist offline Routinier
    registriert
    09-09-2009
    Beiträge
    459

    AW: Beispiel für objekt-orientiertes JavaScript mit Joose

    Zitat Zitat von ein schlauer Beitrag anzeigen
    Natürlich ist es das, deine ist es nicht.

    Polymorphismus ist JS kein Problem und du musst bei if(variabel) oder eben if(!variabel) nicht Wissen, was für ein Typ variabel ist. Wenn es ein Objekt ist, musst du die Methode toString() überschreiben oder implementieren.

    Les' dir mal durch, wie JS funktioniert: http://bclary.com/2004/11/07/ecma-262.html
    Das sehe ich anders:

    Das mag für isNil klappen, aber nicht für isEmpty.

    Beispiel:
    var a = []; oder var = [1]
    var b = false;
    if(a) {b = true;}
    console.info(b);

    Das ergibt für beide Fälle true. Was mir aber nichts nutzt, denn ich will i.d.R. auf vorhandenen Inhalt prüfen. Darum isNilOrEmpty. Dafür brauche ich in JS zwei Abfragen, wobei ich nicht weiß, ob es für die isEmpty eine polymorphe gibt.

    Wir hatten das ja früher schon mal für den Leerstring. Ein empty String gibt bei isNilOrEmpty bei mir ein true.

  9. #9
    ein schlauer ist offline Lounge-Member
    registriert
    18-08-2004
    Beiträge
    14.671

    AW: Beispiel für objekt-orientiertes JavaScript mit Joose

    Zitat Zitat von bis Beitrag anzeigen
    Wir hatten das ja früher schon mal für den Leerstring. Ein empty String gibt bei isNilOrEmpty bei mir ein true.
    ein if(string) ist auch true, wenn der string leer ist.

    Es kommt halt drauf an was du abfragen willst. In JS ist es definiert, dass ein Objekt entweder definiert oder null ist, wenn du ein array mit if() abfragst, kannst du tatsächlich nur diese zwei Zustände abfragen. Dein Beispiel würde funktionieren, wenn du konkret auf true testest:
    PHP-Code:
    alert(
    ([] == 
    true) + '/'+ ([1] == true)
    ); 
    Die genaue Reihenfolge und Umwandlung steht u.a. in diesem Kapitel: http://bclary.com/2004/11/07/ecma-262.html#a-11.9.1

    und für die Umwandlung im bool'schen Kontext: http://bclary.com/2004/11/07/ecma-262.html#a-9.2
    Geändert von ein schlauer (24-01-2010 um 23:00 Uhr)

  10. #10
    bis
    bis ist offline Routinier
    registriert
    09-09-2009
    Beiträge
    459

    AW: Beispiel für objekt-orientiertes JavaScript mit Joose

    Zitat Zitat von ein schlauer Beitrag anzeigen
    ein if(string) ist auch true, wenn der string leer ist.
    Meine Rede! Und darum isNilOrEmpty.

    Beim Array will ich i.d.R. jede Situation abfangen, in der es keine Inhalte hat. JS liefert mit dafür nichts.

    isNilOrEmpty vereinfacht die Protokolle und ist m.E. in der Wirkung polymorph (im Rahmen von JS), wobei das leider nicht wirklich polymorph implementiert ist.

    Leider habe ich gerade eben zwei Situationen gehabt, wo mir im Debugger zwar ein Array angezeigt wird, es aber keins zu sein scheint (lt. array instanceof Array, das ergab false).

    Dieses Pseudo-Array kam mit Werten zurück von: document.getElementsByTagName('map')

    Wieder ein Fall, wo der Debugger mir die Klase nicht anzeigt. Sehr schlecht implementiert in JS .

  11. #11
    ein schlauer ist offline Lounge-Member
    registriert
    18-08-2004
    Beiträge
    14.671

    AW: Beispiel für objekt-orientiertes JavaScript mit Joose

    Zitat Zitat von bis Beitrag anzeigen
    Beim Array will ich i.d.R. jede Situation abfangen, in der es keine Inhalte hat. JS liefert mit dafür nichts.
    if(array.length) .. true wenn > 0

    Zitat Zitat von bis Beitrag anzeigen
    Dieses Pseudo-Array kam mit Werten zurück von: document.getElementsByTagName('map')

    Wieder ein Fall, wo der Debugger mir die Klase nicht anzeigt. Sehr schlecht implementiert in JS .
    Das ist eine HTMLCollection kein Array. http://www.w3.org/TR/DOM-Level-2-HTM...ml#ID-75708506

  12. #12
    bis
    bis ist offline Routinier
    registriert
    09-09-2009
    Beiträge
    459

    AW: Beispiel für objekt-orientiertes JavaScript mit Joose

    Zitat Zitat von ein schlauer Beitrag anzeigen
    if(array.length) .. true wenn > 0[/url]
    Danke, nach ca. 15K Zeilen JS-Code hab ich das schon ein oder zwei Mal gesehen.

    Du bestätigst damit exakt meine o.a. Aussagen.

    Zitat Zitat von ein schlauer Beitrag anzeigen
    Das ist eine HTMLCollection kein Array. http://www.w3.org/TR/DOM-Level-2-HTM...ml#ID-75708506
    Wäre schön, wenn man das aus dem Debugger ersehen könnte - anstatt es wissen zu müssen. Das und solche "Kleinigkeiten" sind exakt, was ich von Anfang an an den JS-Tools gehaßt habe. Das ist "Flintbug", Flintstone Firebug.

  13. #13
    ein schlauer ist offline Lounge-Member
    registriert
    18-08-2004
    Beiträge
    14.671

    AW: Beispiel für objekt-orientiertes JavaScript mit Joose

    Naja, das ist das was auch schon mehrmals angesprochen wurde, es gibt mehrere Ebenen wo etwas herkommt. wenn du von JS sprichst, meinst du eigentlich ECMA Script, das hat aber hiermit nichts zu tun, das ist das DOM und das wird vom w3c spezifiziert. Aber die Umsetzung der Browser ist auch nach über 1o Jahren noch nicht in allen gleich. Daher musst du dich auch noch in den Specs von MS (msn) und Mozilla (MDC) auskennen (die anderen Browser spielen hier eher eine Randrolle).

    Ich weiß jetzt nicht was du mit Debugger meinst vermutlich irgendwas von M$, aber gerade der IE hat noch massive Schwierigkeiten mit dem DOM. Firefox sagt dir das das kein Array ist. Gib mal in die URL Leiste ein:
    javascript:alert(document.getElementsByTagName('*'))

    Du musst bei JS an jeder Ecke einen Stolperstein vermuten und wirst überall einen finden, daher ist dein Unmut berechtigt, wird aber nichts ändern. Es wurde aber im Laufe der Jahre bei jeder Browsergeneration besser. Allein sowas einzusetzen wie ExtJS wäre vor fünf Jahren undenkbar gewesen, höchstens in geschlossenen Firmennetzwerken wo alle den gleichen Browser einsetzen.

  14. #14
    Avatar von Dormilich
    Dormilich ist offline Kaiser
    registriert
    15-01-2010
    Beiträge
    1.297

    AW: Beispiel für objekt-orientiertes JavaScript mit Joose

    Zitat Zitat von bis Beitrag anzeigen
    Wäre schön, wenn man das aus dem Debugger ersehen könnte - anstatt es wissen zu müssen. Das und solche "Kleinigkeiten" sind exakt, was ich von Anfang an an den JS-Tools gehaßt habe. Das ist "Flintbug", Flintstone Firebug.
    wer öfters mit dem DOM arbeitet, weiß daß keine der getElementsBy*()-Methoden ein Array liefert, sondern eine NodeList (DOM) bzw. HTMLCollection (HTML), schließlich ist Array kein Datentyp der DOM API, sondern von JavaScript/ECMAScript. manche Properties (wie z.B. attributes) liefern eine NamedNodeMap (ist ähnlich wie NodeList).

  15. #15
    bis
    bis ist offline Routinier
    registriert
    09-09-2009
    Beiträge
    459

    AW: Beispiel für objekt-orientiertes JavaScript mit Joose

    Zitat Zitat von Dormilich Beitrag anzeigen
    wer öfters mit dem DOM arbeitet, weiß daß keine der getElementsBy*()-Methoden ein Array liefert, sondern eine NodeList (DOM) bzw. HTMLCollection (HTML), schließlich ist Array kein Datentyp der DOM API, sondern von JavaScript/ECMAScript. manche Properties (wie z.B. attributes) liefern eine NamedNodeMap (ist ähnlich wie NodeList).
    ...alles gute Argumente, warum das ein Debugger (z.B. Firebug) genau das anzeigen sollte, damit der Benutzer nicht erst alles schon alles wissen muß.

    Mit der gleichen Berechtigung könnte man den Wunsch nach einem Debugger per se in Frage stellen.

    Mich wundert immer wieder, daß (und warum) Leute mit mangelhaften Gegebenheiten zufrieden sind. Mit dieser Einstellung wird "die Welt" nie ein besserer Ort...

Seite 1 von 2 12 LetzteLetzte

Ähnliche Themen

  1. Was ist JavaScript?
    Von .holger im Forum JavaScript-FAQ
    Antworten: 4
    Letzter Beitrag: 27-11-2006, 10:00
  2. Antworten: 2
    Letzter Beitrag: 23-11-2005, 01:01
  3. Einführung OOP in Javascript (und Actionscript)
    Von Albu im Forum JavaScript-FAQ
    Antworten: 15
    Letzter Beitrag: 05-01-2004, 23:05
  4. window.popup aus flash
    Von antiheld2000 im Forum Flash
    Antworten: 6
    Letzter Beitrag: 18-07-2003, 14:26
  5. Objekt mit JavaScript löschen
    Von Engiwuk im Forum JavaScript
    Antworten: 4
    Letzter Beitrag: 12-10-2001, 22:42

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •