XSL / XSLT als Templatesystem

Bekanntlich setzt das papaya CMS bereits seit Version 1 (um 2000) auf XSL / XSLT als Templatesystem. Auch wenn der Standard schon viele Jahre besteht und z.B. im professionellen Umfeld (große Softwareprojekte, insbesondere im Java Bereich) eine große Wertschätzung und Verbreitung genießt, so ist die Wahrnehmung bei vielen PHP Entwicklern leider noch anders. Und das obwohl XSL / XSLT ein offener Standard ist, der die vielbeschworene Trennung von Logik, Inhalt und Layout sauber implementiert und der nicht zuletzt beliebige Ausgabeformate (HTML, XML, PDF u.v.m.) ermöglicht.

Umso erfreulicher ist es immer, wenn die mannigfaltigen Vorteile gegenüber proprietären Script- und Templatesprachen die Runde machen – wie aktuell in einem lesenswerten Beitrag von phpmonkeys.de.

Fazit der Autoren:

Der Vorteil von XSL ist, dass man dieses Verfahren mit jeder Programmiersprache einsetzen kann, die einen XSLTProzessor mitbringt. Und dabei können Template- und Layout-Dateien ohne Aufwand migriert werden. Man benötigt nur eine ähnliche Implementierung wie der HTMLGenerator und Logik, die die XML-Daten generiert.

…das völlig korrekt – neben weiteren Vorteilen:

  • offener Standard des W3C, keine proprietäre Lösung
  • in die Einarbeitung investierte Zeit ist nicht auf ein Produkt begrenzt, sondern kann in verschiedenen Projekten angewandt werden
  • hervorragend dokumentierter Standard, viel Literatur verfügbar
  • hohe Verbreitung in der Java-Welt
  • mächtiges Werkzeug/Programmiersprache
  • gut nutzbar für Internationalisierung der Ausgabe
  • und viele, viele mehr… ;-)

Sinkende Lizenzeinnahmen trotz fortlaufender Portfolioerweiterung bei Open Text

Eins vorab: Natürlich ist das kein Indiz für das Verschwinden von kommerzieller Software – gleichwohl fand ich eine Meldung von CMSWire.com recht interessant.

Open Text hat wohl seine aktuellen Geschäftszahlen vorgelegt – und darin sind einige Zahlen beachtenswert:

Total revenue: US$ 217.4 million, up 3% compared to US$ 211.4 million for the same period in the prior fiscal year

Der Umsatz insgesamt hat sich also leicht verbessert.

License revenue: US$ 42.6 million, down 10% compared to US$ 47.3 million for the same period in the prior fiscal year

Die Lizenzeinnahmen sind also um gut 10% gesunken.

  • GAAP net income: US$ 21.7 million compared to US$ 1.7 million for the same period in the prior fiscal year
  • Operating cash flow: US$ 48.9 million compared to US$ 4.5 million for the same period in the prior fiscal year

Beim Erlös und beim Cash flow also erhebliches (fast nur noch mit Änderung des Berechnungsverfahrens zu erklärendes) Wachstum.

Die gesunkenen Lizenzeinnahmen hat CEO John Shackleton wohl wie folgt zu erklären versucht:

I am disappointed with our license revenue this quarter. Europe was especially impacted, with current economic challenges slowing the pace of our customers’ IT spending cycles…

Aber ist das wirklich so?

Wenn ich mir die o.g. Zahlen ansehe (und berücksichtige, wie viele Unternehmen Open Text so in den vergangenen Jahren übernommen hat), so drängt sich mir eine andere Schlußfolgerung auf:

  • das weiterhin ganz gute Ergebnis hängt vor allem mit Zukäufen zusammen
  • nur dank dieser Zukäufe konnten überhaupt die 90% der Vorjahres-Lizenzeinnahmen realisiert werden, ohne die Übernahmen sähe das Ergebnis noch deutlich schlechter aus
  • gerade im Kerngeschäft von Open Text (nämlich CMS bzw. ECMS) scheint es zunehmend schwieriger zu werden, Lizenzen abzusetzen – kein Wunder, gibt es doch mittlerweile viele Alternativen zu Open Text, Red Dot & Co.

papaya CMS / SVN Freigabe

Bei uns stand schon seit geraumer Zeit an, das SVN öffentlich zu machen – das haben wir soeben endlich nachgeholt.

Ab sofort stehen neben den “Nightlys” also auch ein SVN Repository und ein Web-SVN für das papaya CMS zur Verfügung.

Kurznotiz: XSL Cache leeren

Bei Projekten mit intensiver Nutzung von XSL bzw. XSLT macht die Verwendung des XSL Bytecode Caches sehr viel Sinn, siehe dazu auch diese sehr umfassende Erklärung meines Kollegen Max.

Wichtig ist aber auch, wie sich der Cache hier verhält – und das ist bei der NY Times, welche die Extension “XSLCache” entwickelt hat, nachzulesen:

Neulich hatten wir die Aufgabe, in einem Projekt den XSL Cache zu “refreshen” – ohne jedoch die Webserver neu starten zu wollen. Es gibt da eine sehr simple und schnelle Lösung (Doku hier bei der NY Times):

The XSL cache uses the modification time (mtime) attribute of stylesheets to figure out if a file is newer than the cached version and needs to be updated. There are several cases where a file might change but the modification time remains old that you should avoid if you want the XSL cache to reload changed stylesheets correctly:

tar and rsync/scp can sometimes preserve the modification time of the archived/copied file. You must be careful about the following:

  • tar, use the -m flag
  • rsync, avoid using the -t/–times flag
  • scp, avoid using the -p flag
  • Be careful about radically adjusting the system clock and modifying XSL files. Similarly, clock skew between web servers and NFS shares may create issues.
  • If all else fails, use touch to clear a stylesheet from the cache, by resetting its last modified timestamp.

In addition, this early release of XSL Cache does not use shared memory, so each PHP process/thread will have its own copy of the stylesheet. Although this is admittedly wasteful, the memory cost does not seem to be costly. However, if you use the cachesheet argument to clear a cached stylesheet from one web server process, it may still be cached in other processes.

(Quelle: http://code.nytimes.com/projects/xslcache/wiki/StaleCaches)

papaya CMS – Release 5.0 – Pressereaktionen

Wir haben ja vorgestern das neue Release 5.0 des papaya CMS veröffentlicht. Eine anstrengende Launchphase, umso mehr freut uns das bisher erhaltene Feedback der Presse ;-)

Hier ein kleiner Auszug: