elf

Guten Tag,

zur Zeit beschäftige ich mich mit Objekt-orientierter Programmierung in JavaScript. Doch erfasse ich das Prinzip nur bedingt, da es sich in meinen Augen stark von dem in PHP unterscheidet.

Nun zum Problem:
Wie kann ich einem DOM Element Methoden zuweisen?
Und zwar nicht individuell, sondern eher wie bei einer Instanzierung.

Beispiel:
Stimmt das so, wie ich es mache?
Oder missverstehe ich das Prinzip vielleicht grundsätzlich?

Vielen Dank für eure Zeit!

Mister Ad

ChrisB

Grundsätzlich so, wie anderen Objekten auch – über prototype.

(Allerdings machen das in Bezug auf HTML-Element-Objekte nicht alle Browser mit.)

__________________
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?

elf

Danke für die schnelle Antwort.

Wie sieht es allerdings mit meinem Beispiel aus?
Sollte ich die Methoden direkt dem HTML-Element-Objekt zuweisen oder dieses als Attribut speichern:
Welche Möglichkeit ist nun vorzuziehen?

ChrisB

Das lässt sich anhand eines solchen, eher sinnfreien Beispiels schlecht sagen.

Zuerst mal gilt, im Sinne der Trennung von Darstellung und Logik, dass du wann immer es sich vermeiden lässt keine Styles direkt setzen solltest. Du vergibst eine ID und Klassen - und diese werden im Stylesheet benutzt, um das/die Element(e) zu selektieren und darüber zu formatieren.

Und zum anderen halte ich es für wenig sinnvoll, an der Stelle auf Teufel komm raus OO „durchdrücken“ zu wollen.
Schau die die großen JS-Frameworks an: Die arbeiten im wesentlichen alle mit einer Selektor-Engine, die das Auswählen von Elementen im DOM nach beliebig einfachen bis komplizierten „Mustern“ ermöglichen – um sie dann anschließend an Funktionen/Methoden übergeben, die irgendwas damit anstellen.

So lange es browserübergreifend noch keine simple Möglichkeit gibt, HTML-Elementobjekte prototypisch zu erweitern, würde ich also diesen Weg bevorzugen.

Was anderes ist es, wenn du kompliziertere Objekte für deine Programmlogik brauchst, die weit mehr verkörpern, als „nur“ ein HTML-Element.
Wenn die lediglich ein HTML-Element „brauchen“, um sich selbst im Rahmen einer Webseite irgendwie „darstellen“ zu können – dann könnte man den zweiten Weg gehen, this.obj = htmlObject (Allerdings ohne solche Nonsense-Methoden wie “makeRed” …)
Wobei dann die Frage wäre, wie viel Flexibilität man an der Stelle braucht; ob man das Element als Parameter von außen übergibt oder im Objekt selber erzeugt. Und des weiteren auch noch, ob es überhaupt wirklich da „rein“ gehört – oder ob man die Darstellung nicht auch lieber gleich ganz von den Programmlogik-Objekten abkoppelt. Damit wird man dann letztendlich eher bei einer Art MVC in JavaScript landen. Fertige Ansätze dazu gibt’s sicher schon einige – einfach mal googlen.

__________________
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?

elf

Danke, da ist jetzt sehr viel enthalten, das mir weiterhilft.

Zu den Beispielen: Es ist schwierig simple, aussagekräftige Codebeispiele zu schreiben, vor allem wenn man auf einem Gebiet noch nicht sicher ist. In diesem Fall hätte ich konkreter sein können, Verzeihung.

Ich arbeite mit jQuery, von dessen Funktionen ich großteils jene benutze, die sich auf die View Ebene beschränken (Modifizieren des DOMs, Animationen, Effekte).
Es war für mich naheliegend, dass meine Klassen HTML-Objekte repräsentieren.

Vielleicht fahre ich auch besser, wenn ich weiterhin linearen Code mit jQuery produziere, wie gesagt, ich habe gerade erst mit Oo in JS begonnen und mir fehlt der Überblick.

ChrisB

Finde ich wie gesagt nicht so besonders naheliegend.

Nimm an, du hast ein Objekt, das irgendeine Liste von Dingen verwaltet.
Klar, dieses Objekt selber könnte jetzt ein UL-/OL-Element sein, bzw. eng mit einem solchen verknüpft sein. Die einzelnen Elemente in deiner Liste müssten dann aber jeweils ein LI sein, und ggf. endet es damit noch nicht mal, weil du auch innerhalb der LI noch diverse Elemente brauchst, um das ganze in HTML strukturiert darzustellen.

Will man da wirklich für „jeden Furz“ ein HTML-Elementobjekt mit rumschleppen?

Ich denke nicht. Das ganze an einen View-Mechanismus zu koppeln, der bei Bedarf eine HTML-Ansicht aus den reinen Daten erzeugt, erscheint mir doch sinnvoller.

__________________
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?

elf

Da stimme ich dir auch zu.
Nur sind mir bislang ausschließlich Fälle untergekommen, wo ich den direkten Zugriff auf ein HTML-Objekt benötigt habe, eben um Effekte und Events zu steuern. Alles andere hole ich mir per Ajax Request vom Server.

Hier ist ein Style für Formulare, an dem ich gerade arbeite.
Ich denke, eine Klasse 'FormElement', mit Methoden wie showInput(), hideDesc() und focusInput() als Alternative zu dem derzeitigen prozeduralen Code wäre viel einfacher zu handhaben. Und ein Objekt der Klasse FormElement repräsentiert in meinen Augen ein bestimmtes HTML-Elementobjekt.
Ich bilde nicht jedes Stück HTML als JS Objekt ab, nur solche, die ich eben irgendwie kontrollieren will.

Vielleicht verstehe ich dich auch nicht richtig.

ChrisB

Huch, wie benutzerunfreundlich …
Was soll der Sinn dahinter sein, so ein Versteckspiel zu betreiben?

Nun, die Alternative, dir dafür spezifische Objekte zu erstellen, in die du das HTML-Elementobjekt hinein „injizierst“, wie bereits angesprochen, besteht ja.

Aber welches denn …?
Das Anzeigen des jeweiligen Inputfeldes wird ja vom Label aus getriggert – das wären also schon zwei HTML-Elemente, die an der Aktion beteiligt sind.

__________________
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?

elf

Naja, das UI ist dadurch kompakter und reduziert. Für mich ist es einfach ein Designexperiment. Und ohne die restlichen Bugs (großteils im IE) ist es hoffentlich gut und intuitiv benutzbar. Wenn nicht, entferne ich den Effekt.
Danke für den Input!

Ein Formular-Element umfasst für mich Label, Inputfeld, Fehlermeldungen, etc. Ich nenn es immer so; das war wohl missverständlich.
Es reicht in diesem Fall wahrscheinlich eine einzige Klasse FormElement um das Verhalten all dieser Abschnitte zu steuern.


Danke für dein Engagement!

nikosch

Grundlegend finde ich Deinen Ansatz in Ordnung. Hier ein paar Anmerkungen

1) „makeRed“ macht eine AUssage über Wirkung, nicht Funktion. markInvalid() o.ä. wäre treffender. Ob nämlich letztlich dadurch die Box rot wird, mit einem Ausrufezeichen versehen oder fett umrandet, ist eigentlich erst Aufgabe des Stylesheets. Damit kämen wir zu 2)
2) Das Verhalten fest einzubauen halte ich für falsch. Die m.E. eleganteste Methode ist immer noch, class-Attribut zuweisen, (z.B. „invalid“) und mit CSS weiterstylen. Zugegeben, wenn zusätzliches HTML benötigt wird, ist das nur begrenzt möglich. Aber dann würde ich überlegen, diese Struktur gleich auszuliefern und bei Nicht-Bedarf auszublenden.
Dann benutze die doch auch zum Selektieren der Elemente, Zuweisen von Styles/Klassen usw. Ist doch sonst verschwendete Performance.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--