6. Dez, 2007
Auf den Wunsch eines Blog-Lesers hin, habe ich heute das Kommentarsystem
das ich ursprünglich für mein
Code snippets Projekt entwickelt hatte, noch einmal
überarbeitet und als Paket zusammengefasst.
Ich denke dass, das die Library jetzt so flexibel ist das man
Sie auch für andere Projekte ohne größere Probleme benützen kann.
Das komplette Modul besteht jetzt aus nur einer Klasse die nur mit ein paar
Variablen gefüttert werden muss und dann einfach funktionieren sollte.
Das ist zwar wahrscheinlich nicht OOP konform - aber was soll’s
Download und ein paar zusätzliche englischsprachige Informationen gibt es
auf der eigens dafür eingerichteten
Projektseite.
Und danke Volker, für dein Interesse. Zwar habe ich es leider noch nicht hin bekommen ein
Admin-Interface dafür zu entwickeln (da ich selber keins brauche) aber ich
hoffe damit kannst du erst mal was anfangen
Hmm, ich hoffe nur das sich den Quelltext jetzt kein Spam-Bot Entwickler herrunterlädt. Naja ich bin ja
kreativ in der Spam-Bekämpfung, ich hab da schon einige Ideen
…
15. Nov, 2007
Letztens las ich einen
interessanten Kommentar zu
einem Blog Eintrag bei
Ajaxian bezüglich der starken Verbreitung von
Komponenten Bibliotheken bzw.
Web-Frameworks (wie z.B.
YUI,
TIBCO,
usw.):
Dion meinte dazu:
Manchmal fühle ich mich ein bisschen schlecht wenn sich die Leute hier und da
über eine neue Komponente freuen, wenn im Gegensatz dazu schon hunderte davon
in Frameworks wie TBCO, Backbase oder
Oracle ADF
stecken
Nun gut, hier sind 10 Gründe, warum Dion sich deshalb nicht so schlecht fühlen sollte
- HTML ist besser als ein eigene
Markup
Sprache. Das trifft vor allem dann zu wenn das eigene Markup sowieso auf
XML
basiert, was ja meistens der Fall ist. Einige unter uns bevorzugen
wahrscheinlich auch ein Markup das sich über eine eindeutig definierte
Schnittstelle (z.B. über
CSS) nur dann „einklinkt“ wenn man es auch wirklich benötigt.
- Meine handverlesenen
Komponenten sind schneller geladen und werden schneller ausgeführt. Wie Dion
bereits erwähnte umfassen manche der Frameworks hunderte von Komponenten.
Schön und gut, aber der Nachteil daran ist das man die nicht benötigten,
überflüssigen Komponenten nicht so einfach entfernen kann ohne gleich die ganze
Stabilität des Frameworks zu beeinflussen. Des Weiteren, unterscheidet sich die
Qualität der Umsetzung speziell im Bereich der Performance manchmal erheblich.
Sorry, aber meine Webseiten sollten auch bei einer etwas langsameren DSL Leitung
noch schnell laden.
-
Desktop ähnliche Oberflächen waren in den 90’er Jahren in. Wir sollten deshalb nicht weiter versuchen Web-Anwendungen wie Desktop-Anwendungen aussehen
zu lassen. Außerdem sind viele der neuen Richtlinien (Guidelines), die sich in letzter Zeit
für die Web-Entwicklung herausgebildet haben, denen der Desktop-Oberflächen weit
überlegen. Macht also einen Schritt vorwärts und nicht einen zurück.
-
Ich will nicht deine
Entwicklungsumgebung (IDE) benützen. Ich hab bereits meine eigene. Und
Eclipse ist zwar viel besser als eine
proprietäre IDE aber manche von uns
wollen Sie trotzdem nicht benützen. Zusammenfassend will ich damit sagen, wenn
dein Framework eine bestimmte IDE erwartet ist das ein Problem für mich.
-
Ich benötige keinen tollen Drag and Drop GUI Builder. Das ist zu viel des Guten. Ich arbeite nun
schon seit etlichen Jahren mit HTML, es ist simpel und das meiste erstelle ich
sowieso aus Vorlagen. Ich will meine Oberfläche selber definieren können und
deine Bibliothek nur dann einbinden wenn sie benötigt wird.
-
Das KISS-Prinzip (Halte
es einfach) gilt immer noch für Web-Anwendungen obwohl manche denken
unbedingt ein „super auto sorting filtering live editing grid“ haben zu müssen.
Aber die meisten brauchen so etwas nicht. Manchmal ist eine einfache Liste mit
ein paar übersichtlichen Optionen für das Bearbeiten einfach besser. Den Erfolg
dieser Herangehensweise kann man auch an bekannten Web-Anwendungen (z.B.
Flickr oder
YouTube, usw.) sehen.
-
Die Richtlinien für die Web-Entwicklung sind noch nicht ausgereift.
Manchmal denke ich wir sind erst am Anfang. Dabei haben einige Bibliotheken
bereits großartiges Design das den aktuellen „best practices“ (siehe
Prototype)
folgt, allerdings gibt es auch andere die schon veraltet sind bevor sie
überhaupt veröffentlicht werden.
Selectors sind hier ein gutes Beispiel, denn dank der relativ neuen und schnellen CSS3 Umsetzung haben sich diese zu einer
mächtigen Methode entwickelt um Objekte und Events an HTML zu binden. Das hat
die „best practices“ für den Umgang mit dem DOM dramatisch verändert.
-
„Sehr schön, aber wir haben bereits eine.“ Wie bereits erwähnt benötige ich nicht alle deine
Komponenten und ich will auch nicht deinen kompletten Framework-Kern dafür
einbinden müssen. Selectors sind da wieder ein gutes Beispiel. Mit der Umsetzung
der Selectors in Prototype bin ich sehr zufrieden, deshalb will ich keine zweite
laden müssen, aber ich kann deine Implementation nicht einfach entfernen ohne
dass dein Web-Framework „kaputt“ geht.
-
Sich an Standard halten
ist gut. Danke dass Ihr mich vor HTML, CSS und JavaScript „beschützen“ wollt
aber irgendwie kann ich mich mit der Tatsache das der Code, den ich schreibe,
von der weiteren Unterstützung der von der Community abhängt nicht anfreunden.
Du könntest zum Beispiel in ein oder zwei Jahren entscheiden dass dir
Web-Anwendungen nicht mehr so wichtig sind. Sicher — du hast deine Bibliothek
als Open Source veröffentlicht, aber wer treibt die Entwicklung voran wenn du
nicht mehr dabei bist?
- Dein Framework hat immer noch keinen WYSIWYG HTML Editor!? So ziemlich alles was du machen kannst, kann ich besser (mit der Hilfe von vielen
talentierten Open Source Entwicklern da draußen). Aber da sind immer noch ein
paar Dinge die du wahrscheinlich besser machen könntest, aber du tust es nicht.
Also warum sollte es mich kümmern?
Ich würde gerne wissen ob es da draußen irgendein Web-Framework gibt auf das nur
sieben von diesen zehn Punkten zutreffen? Allerdings muss ich auch zugeben dass
ich nicht jede Bibliothek genau getestet habe und nach einer Weile wird man
schon etwas zynisch. Zudem weiß man ja nie wann eine
Framework einen Quantensprung macht. Aber momentan halte ich meine Lösung für
einen guten Weg.
Mein Kommentar:
Also ich finde Dan’s Artikel toll, er beschreibt einige Probleme mit größeren
Web-Frameworks die bei der üblichen Euphorie unter den Tisch fallen. Ich will allerdings
keineswegs alles schlecht reden, denn ein gutes Framework kann einem allemal sehr viel Arbeit ersparen.
Am besten man beschäftigt sich erstmal mit der Materie bevor man überstürzt eine Entscheidung trifft. Und letztendlich muss dann jeder für sich selbst entscheiden wie er dazu steht

(Ha! da bin ich mal wieder fein raus *g*)
Jonas