Stoppt die Vorratsdatenspeicherung! Jetzt klicken & handeln!Willst du auch bei der Aktion teilnehmen? Hier findest du alle relevanten Infos und Materialien:

Archiv für Web-Entwicklung

CommentLib PHP library - Version 1.2

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 ;-)

10 gute Gründe Web-Frameworks zu vermeiden

Dies ist eine freie Übersetzung des Blogartikels Top 10: Reasons To Avoid Component Libraries von Dan Yoder. Übersetzt mit freundlicher Genehmigung des Autors.

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 :-)
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. „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.
  9. 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?
  10. 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