Baukastenprinzip - Objekte

[Camping_RIDER]

Aloha ;)

Gerne möchte ich lesen, wie konsequent ihr das Baukastenprinzip anwendet.

Gar nicht. Aus gutem Grund.

Ich hingegen schon, und Angular 2 als ein nicht unbedeutendes komponentenbasiertes Framework macht es vor.

Objektorientierung ist ein Programmierparadigma und hat nichts, aber auch gar nichts mit der Auszeichnungssprache HTML zu tun.

Die Ideen hinter Objektorientierung und Komponenten scheinen mir nicht so weit auseinander zu liegen.

Nun, Angular ist ein JavaScript-Framework, und als solches baust du damit Webseiten eingebettet in eine Programmiersprache. Selbstverständlich ist Objektorientierung und die Verwendung von Komponenten dort vorgesehen. Weil beides Paradigmen sind, die zu einer Programmiersprache passen.

Ich bin mir im Übrigen auch sicher, dass Angular dann in der entstehenden Seite diese Komponenten wieder aufdröselt und in die Struktur bringt, die für HTML-Dokumente vorgesehen ist - mit zentralisierten Angaben zu Styles und Scripten. Ich kenne Angular nicht persönlich, aber wenn das nicht so wäre würde mich das sehr wundern. Klär mich auf, falls ich da falsch liege.

Es hat niemand bestritten, dass es Werkzeuge geben mag, bei denen am Ende Webseiten rauskommen, für die eine solche Arbeitsweise förderlich, empfehlenswert oder gar notwendig ist.

HTML funktioniert trotzdem anders. Der Weg dahin, den HTML-Code zu bekommen (vor allem bei automatisierter Zusammenstellung, wie durch PHP o.ä. - oder eben wie bei Angular mit Javascript) mag objektorientiert und komponentenbasiert sein - HTML kennt diese Strukturen aber nicht und erwartet das, was objektorientiert zusammengebaut wird, an seine eigene Anforderungen angepasst.

Für HTML als Auszeichnungssprache sind HTML-Elemente die Komponenten, aus denen sich eine Seite zusammensetzt. Jede dieser Komponenten hat ihren Platz in einem gut strukturierten HTML-Dokument. Eine weitere funktionale Gruppierung, über HTML-Elemente hinaus, ist in HTML nicht vorgesehen und läuft den HTML inhärenten Konzepten (separation of concerns, semantische Auszeichnung, ...) entgegen.

Sie gehören da nicht logisch hin. Sie gehören logisch da hin, wo man Metaangaben sucht - in den head, und in ein externes Stylesheet. Da kann man anderer Meinung sein. Sie gehören in die Metaangaben, weil die Syntax es so vorsieht. Logisch finde ich das nur mit einer bestimmten Betrachtungsweise.

Das logisch sollte hier vielleicht gestrichen werden. Aber es ist so, dass die Angaben zu script und styling eben durch die Spec als Metaangaben klassifiziert werden und damit da ins Dokument gehören, wo sie eben hingehören. Ich habe mich da nicht explizit festgelegt, aber „Where metadata content is expected.“ ist eher nicht deckungsgleich mit „bei einem Input-Feld“. Schon gar nicht dann, wenn sogar der Validator meckert.

Grüße,

RIDER