hot Papaya

Mal wieder eine nette Aufmerksamkeit eines Kollegen erhalten: “Hot Papaya” Schokolade von Lindt (Schokolade mit Papaya und Chili, sehr interessanter Geschmack…)

“ez Systems verdient Geld mit Open Source”

Seitens der Kollegen von eZ Systems wurde eine sehr interessante Newsmeldung veröffentlicht, die mir doch sehr stark von der Abteilung “Investor Relations” geprägt zu sein scheint.

Im wesentlichen läßt sich die Aussage reduzieren auf “Wir verdienen Geld mit Open Source”. Das ist schön – und uns bei papaya auch nicht fremd. Vielleicht bin ich zu stark mittelständisch geprägt, aber ich halte profitables Geschäft ja auch immer noch für eine der Grundvoraussetzungen für eine nachhaltige Unternehmensentwicklung und somit für einen langfristigen Fortbestand der Company :-)

Anscheinend, so darf man der Meldung entnehmen, ist dies nun erreicht:

(…) eZ Systems has proven its Enterprise Open Source business model with two straight profitable quarters.

Interessant wird es beim Blick auf die Anstrengungen, welche für die Profitabilität notwendig waren:

eZ’s profitability comes after 8 years and more than 10 million USD of investments, all going towards building the scalable Open Source business model.

O.K., man hat also binnen 8 Jahren und unter Einsatz von mehr als 10.000.000 US-Dollar die Gewinnschwelle überschritten. Interessant wäre nun natürlich die Höhe des Gewinns, um das im rechten Licht betrachten zu können, diese Information konnte ich aber nicht finden.

Rein negativ bewerten mag ich das aber dennoch nicht so recht – denn das, was eZ Systems technisch macht, ist schon professionell, ausserdem tun sie viel für die Community, viel für die PHP Entwicklung etc.

Ob die 10 Mio. $ letztlich sinnvoll investiert waren, müssen im Zweifel die Geldgeber entscheiden – ich denke (bzw. weiss aus eigener Erfahrung), dass man auch ohne Investment und einfach durch gute Arbeit des ganzen Teams (d.h. finanziert aus dem Cash-flow) gute Software entwickeln und diese profitabel einsetzen kann – auch als Open Source Produkt unter der GPL.

papaya CMS macht frischen Atem :-)

Letzte Woche von einem Arbeitskollegen bekommen – sozusagen das neue “Corporate Chewing Gum” :-)

papaya Entwicklung: XSL Templates für Content Module

In einigen Fällen stellt sich dem Template-Programmierer die Frage, wie die Inhalte unter /page/content/topic ausgegeben werden sollen. Grundsätzlich stehen drei verschiedene Wege zur Verfügung:

  • <xsl:apply-templates> oder <xsl:call-template>
  • <xsl:value-of>
  • <xsl:copy-of>

Die erste Variante führt weitere Templates auf, die den Teilbaum in /page/content/topic weiterverarbeiten, wobei man mit call-template direkt ein bestimmtes Template aufrufen kann. Mit value-of gibt man lediglich alle Textknoten in die Ausgabe aus, die im referenzierten Teilbaum enthalten sind, während copy-of den gesamten Teilbaum in die Ausgabe kopiert.

Wann nimmt man was?

Welche Variante sollte man denn nun benutzen? Alle Methoden haben ihre Vor- und Nachteile.

1. value-of

Mit value-of erzeugt man sichere Ausgaben, da alle Formatierungen aus Texteingabefeldern entfernt werden. Besonders bei user-generiertem Content ist dies eine sehr einfache Methode, um Manipulationen zu verhindern. Auch Inhalte, die im Backend eingegeben werden, können auf diese Weise sauber gehalten werden.

Der Nachteil dieser Methode ist jedoch, dass man sie nicht überall einsetzen kann, wo man Formatierungen wie <h2>, <em>, <strong> usw. einsetzen will. Auch Hyperlinks gehen natürlich verloren. Für umfangreiche strukturierte Inhalte sollte man also diesen Weg nicht gehen.

2. copy-of

copy-of hat den Vorteil, dass alle Formatierungen und inhaltlichen Strukturierungen (<h1-6>) mit in die Ausgabe übernommen werden, genauso wie Hyperlinks, was durchaus erwünscht sein kann. Schließlich möchte man als Redakteur Artikel schreiben, die in Absätzen strukturiert sind, Zwischenüberschriften oder Links zu anderen Ressourcen enthalten.

Der Nachteil dieser Methode ist, dass man die Kontrolle über den Teilbaum aus den Händen gibt. Er wird ja einfach in die Ausgabe kopiert. Daher sollte man diese Anweisung auch nicht für user-generierten Content benutzen, der bösen Code enthalten könnte.

“Böser Code” kann zum Teil auch durch Sonderzeichenmaskierung (=Escaping) in der Methode getParsedData() in der Content-Modul-Klasse entschärft werden, indem man bspw. papaya_strings::escapeHTMLChars($myStringVar) benutzt (siehe auch $this->getXHTMLString()).

3. apply-templates oder call-template

Mit apply-templates kann man komplexe Strukturen innerhalb von /page/content/topic an zusätzliche XSLT-Templates zur Verarbeitung weiterdelegieren. Die Anweisung sucht dabei ein Template, dessen match-Muster am besten zum jeweiligen Element in der Knotenmenge des Kontextknotens passt. Für jeden Knoten im Kontextknoten wird also ein Template anzuwenden versucht. Falls es kein passendes Template gibt, wird einfach der entsprechende Textknoten ausgegeben. Wenn das select-Attribut benutzt wird, versucht XSLT, ein Template für jeden in select definierten Knotenmengenausdruck anzuwenden.

Diese Anweisung hat den Nachteil, dass sie nicht besonders performant ist, da der gesamte Teilbaum durchsucht wird. XSLT versucht dabei, für jeden Knoten das richtige Tempate zu finden.

Nach Möglichkeit sollte man also Templates direkt auswählen, indem man call-template benutzt und den gewünschten Teilbaum des Kontextknotens als Parameter übergibt. Auf diese Weise hat man auch die volle Kontrolle darüber, welches Template benutzt wird und welche Transformation angewendet werden soll.

Bei den aufzurufenden Templates steht man natürlich wieder vor der Wahl, ob man jetzt value-of oder copy-of benutzen soll. Wenn es sich um Inhalte handelt, die man im Backend in einzeilige Textfelder eingibt, wird man mit Sicherheit value-of benutzen, bei mehrzeiligen Textfeldern, die auch HTML-Eingabe erlauben, muss man auch copy-of benutzen, damit der HTML-Code auch in der Ausgabe landet. Um die Eingabe von HTML-Code oder sonstiges zu verhindern, sollte man die Content-Module so schreiben, dass entsprechende Validitätschecks bereits während der Eingabe im Backend den Inhalt überprüfen. Validitätschecks sollten also nicht die Aufgabe des Template-Programmierers sein.

(Credits: Text entstammt dem internen papaya-Blog und wurde von Max verfasst.)