Schaue mir Perch auf jeden Fall noch einmal an. Hatte als einfaches System ein paar mal frogCMS (ein RadiantCMS für PHP) im Test, was auch ganz gut funktionierte, auch von der Nutzerseite her.

Danke für den Artikel.

Klar gibt es da für viele gleich eine riesige Hürde, wenn sie Java hören, aber die Hürde am Anfang zu nehmen lohnt sich laut Berichten der Kollegen. Das CMS ist eher ein Rahmen, in den sich etliches reinhängen lässt, aber eben auch ganz reduziert zu nutzen.
Und im Vergleich zu Perch ist es OpenSource, die Lizenzgebühren entfallen…

Nur um die Werkzeugpalette zu ergänzen, damit nicht alle Probleme Nägel bleiben.. ;)

Und mehr noch: Perch ist ein spannener Wegweiser in eine neue, alte Richtung. Weniger Code. Weniger Features. Mehr Flexibilität, die aber auch mehr Kompetenz fordert. Back to the Roots of PHP, aber ohne die Fortschritte zu vergessen, die wir gemacht haben.

Auf jeden Fall ist “richtige” Anwendungsentwicklung aufwändiger. Egal ob OO oder anders (Drupal ist da ein schönes Beispiel für nicht-OO Engineering). Das ist ja v.a. so, weil “richtige” Anwendungen ganz andere Zielsetzungen und Anforderungen haben.

Was ich mit Heimweh vorhatte und was Oliver scheinbar in Perch gesucht hat, geht aber ja eher in die Richtung aus der PHP einst kam. Nämlich das das einfach ersetzen und zusammstöpseln von Inhalten in HTML-Dokumenten / Templates. Die ganzen frühen PHP Sachen sind alle vom Wesen her, zuallererst HTML-Dokumenten und erst danach etwas Programmierung. Das hielt die Codebasis extrem gering und die Flexibilität für denjenigen, der FTP/HTML und ein wenig PHP beherrscht sehr hoch.

Mit den Open Source Systemen haben wir zwar viel mehr Leute erreicht und das ist eine überwältigend großartige Leistung. Aber ich für meinen Teil sehne mich ein wenig zurück zu der Flexibilität von früher.

Perch ist sicher nicht perfekt, es ist nicht kostenlos, es erzeugt kein wohlgeformtes XML etc. Es gibt viele, viele andere Tools und Möglichkeiten, mit denen man arbeiten kann (inkl. natürlich der Option ein solches Tool selbst zu entwickeln), dennoch – und das war schon immer mein Punkt: Kann Perch in manchen Projekte die richtige, weil schlanke und unkomplizierte Wahl sein. Einverstanden?

<perch:content id=”desc” label=”Description” required=”true”
textile=”true” type=”textarea” />

Bei sowas dreht sich mir allerdings der Magen um. Das Template versucht ja nur so auszusehen, wie XML ist aber weder wohlgeformtes und daher nur Datenmüll, für den Perch vermutlich einen eigenen Parser geschrieben haben. Wenn man sowas, braucht man auch keine XML-esque Notation mehr, weil das ja doch von keiner XML-Bibliothek weiterverarbeitet werden kann. Da kann man besser entweder sowas wie Smarty mit eigener Notation machen, oder – wenn man denn unbedingt spitze Klammern haben will – sollte man besser gleich reines PHP verwenden.

Anders sieht es aus, wenn man PHP OOP mit Klassen programmiert. Da nehmen alleine die Programmierung der Klassen sicher ziemlich viel Zeit in Anspruch.

Ich weiss jetzt nicht, wie Perch programmiert wurde, aber ich bin mir auch mit meinem eher “Anfänger” Wissen über PHP sicher, dass der Aufwand ziemlich gering ist.

Hier die Dokumentation meiner Liebelei mit “Heimweh”
http://anmutunddemut.de/cat...

Hier der Code:
http://github.com/benthebea...

Über Sinn oder Unsinn ein 40 EUR Produkt selbst zu programmieren braucht man nicht zu diskutieren. Gerade für die kleinen Projekte, die entsprechend Kostensensibel daher kommen, ist jedes weitere Wort überflüssig.

Aber dies hier sind doch alles nur noch angedeutete Funktionen. Für einen Bruchteil eines Templatesystems mit einem Ansatz von Inhaltstypen und evtl. noch einem Hauch von Navigation in einem System fehlt mir einfach das Verständnis. Da ist doch sowas von vorprogrammiert, dass man sofort an Grenzen stößt …

Die Kunst liegt im Erkennen, der Mut im Weglassen….

Aber ja, das ist natürlich eine Frage des Prinzips, denn man bezahlt natürlich für eine Software, deren Funktionen es in vielen anderen Tools kostenlos gibt. Und viel mehr. Und das ist dann der entscheiden Punkt….

Allerdings kommt es eben immer auf Art, Umfang und die zu erwartenden Wünsche und Ansprüche des Kunden im Umgang mit der neuen Site an. Und ein Admin-Interface wie bspw. dieses hier möchte ich keinem Kunden zumuten, ohne dass es dafür eine Reihe extrem guter Gründe gibt.

Selber Programmieren so ne Sache, wenn wenig von PHP versteht, bzw. nicht die Zeit hat. Setze gerne auf Eigenlösungen, aber grade für besagten Kunden waren Zeit und Bezahlung dafür einfach zu knapp.

Und natürlich zahlen wir für weniger drauf, siehe Apple und Co.