Jörg Napp

CMS Interview : Unter welchem Namen bist Du bekannt?
Mein richtiger Name ist Jörg Napp. In den meisten Foren bin ich als jn angemeldet. Für das PostNuke-NOC ist das zu kurz, dort heiße ich jna.

Wo kommst Du her?
Ich wohne mit meiner Frau und meiner Tochter in Ravensburg (da, wo die Spiele mit der blauen Ecke herkommen).

Wie bist Du zu Postnuke gekommen?
Im Frühjahr 2002 habe ich für eine Internet-Präsenz ein CMS gesucht. Nach einigen Recherchen war die Wahl dann zwischen PHPNuke und PostNuke, wobei ich mich dann für PostNuke entschieden habe Ich hatte den Eindruck, es sei das durchdachtere Konzept. Zum einen die vorhandene API, zum anderen die große Community rund um PostNuke haben mich überzeugt.

Was ist Deine Aufgabe im pnCore-Team?
Ich arbeite an pnRender, der Smarty-Implementierung für PostNuke. Außerdem scheine ich der einzige zu sein, der Static_Docs weiterpflegt.

Wann hast Du angefangen für Postnuke zu programmieren?
Meine ersten selbstgeschriebenen Module sind (zum Glück) unveröffentlicht; sie werden nur "intern" genutzt... "Richtig" angefangen hat es dann mit selbstgeschriebenen Themes.

Wie läuft Deine Arbeit ab?
Wie ja Mark in der letzten Woche berichtet hat, wird "im Team diskutiert, alleine programmiert". Natürlich entwickelt man ein paar Routinen auch gemeinsam während einer IRC- bzw. ICQ-Sitzung, aber der meiste Code entsteht doch alleine. Das Team gibt dazu feedback, man kann korrigieren und am Ende steht dann (hoffentlich!) gut lesbarer, strukturierter und wiederverwendbarer Code. Nur so kann es in meinen Augen auch funktionieren...
Außerhalb der Core-Entwicklung schreibe ich viele Codezeilen eigentlich mehr als "proof of concept". So ist z.B. "Search Statistics" entstanden: Die Überlegung war, ob man ohne Veränderungen an der Struktur eine Statistik darüber bekommen kann, nach welchen Begriffen gesucht wird. Ein entsprechendes Modul war schnell geschrieben; was bis heute fehlt, ist ein "gescheites" Admin-Interface...

Wie geht Es Deiner Meinung nach mit Postnuke weiter?
PostNuke wird sich, wie schon an anderen Stellen und von anderen Leuten erwähnt, hin zu einem "Application Framework" entwickeln. Was sich zunächst nach einem tollen Buzzword anhört...
Dahinter steckt aber viel mehr. Momentan gibt es nahezu keine "Zusammenarbeit" zwischen den Modulen, wenn man mal von kleineren Ausnahmen wie der Photoshare-Integration in pagEd absieht. Die größte Herausforderung wird es sein, derartige Mechanismen auf abstrakter Ebene zur Verfügung zu stellen, sodass Modulentwickler diese leicht nutzen können. Ein erster Schritt dahin ist das Hook-Konzept.

Wo liegen die Stärken und Schwächen von Postnuke?
Der stärkste Punkt sind die Perspektiven dieses CMS. Die saubere Implementierung mittels einer API, die Weiterentwicklung in Richtung Framework wie oben beschrieben, die kommende Integration von Smarty sind großartige Möglichkeiten.
Ein Mangel ist, dass PostNuke zwar recht gut dokumentiert ist, diese Dokumentation aber (derzeit noch) schwer aufzufinden ist, da sie auf vielen Seiten verstreut ist. Dasselbe gilt für einige Module. Die Idee des NOC als zentrale Stelle für die Module ist zwar ein erster Schritt in diese Richtung, aber hier wird sich noch viel tun müssen.

Du beschäftigst Dich auch mit "Seiten-Projekten" oder?
Die Projekte, an denen ich arbeite, findet man auf ttp://lottasophie.sourceforge.net.
Das bekannteste Modul, ist sicherlich das universelle Kommentarmodul "EZComments". Mit der Arbeit an EZComments begann ich im Zusammenhang mit der Arbeit am PostNuke-Handbuch auf http://www.post-nuke.net Anfang 2003. Die Überlegung war, wie man das Handbuch so anlegt, dass Kommentare möglich sind. Für ContentExpress gab es keine Kommentarmöglichkeit, also musste eine geschaffen werden. Mit dem Hook-Konzept von PostNuke war es zum Glück ein leichtes, ein entsprechendes Modul "dranzuflanschen".
Der Title_Hack ist eine Möglichkeit, "vernünftige" Angaben in der Titelzeile des Browsers zu machen. Der Hack ist populärer geworden, als ich ursprünglich vermutet hatte. Mittlerweile gibt es für eine ganze Reihe an Modulen entsprechende Titel-Dateien.
Weiterhin bin ich mit der Pflege von My_eGallery beschäftigt. Dieses Modul habe ich auf meiner privaten Seite eingesetzt. Für die My_eGallery waren an vielen Stellen Patches und Fixes verfügbar, aber leider nicht zentral eingepflegt. Da Patrick (MarsIsHere) die Pflege eingestellt hat, habe ich das Modul mit unter meine Fittiche genommen und pflege es nun gemeinsam mit Chasm.

Gibt es dabei etwas zu Bedenken für die User?
Siehe oben -- das meiste ist "proof of concept". Wenn jemand einen Bug findet, dann sollte er ihn nicht behalten, sondern in den Foren davon berichten. Wenn jemand eines meiner Module verändert, dann freue ich mich darüber, wenn ich das bekomme! Leider passiert dieses Feedback zu selten.

Was kann denn der normale User tun?
Gebt Feedback! Bug-Reports, Fragen im Forum, Feature-Requests usw. sind wertvoll, um das Produkt besser zu machen.
Lest die Dokumentation! Wie erwähnt, ist es oft schwer, die Dokumentation zu finden. Versucht es trotzdem. Benutzt die Forensuche, Google und was immer Euch noch einfällt.

Helft mit! Ob als Programmierer, als Web-Designer, als Schreiber von Dokumentationen: Hilfe wird immer benötigt!

Danke für die Infos.

Anmerkung: Nächste Woche gibt's kein Interview, weil ich erstens im Streß bin und zweitens noch kein anderer Core-Dev auf meine Fragen geantwortet hat.