Content-Präsentation in Web-Portalen
Wird in einem Projekt Content aus einem CMS in ein Portal integriert, gilt es die Unterschiede beider Systeme zu verstehen, um eine gute Portal-Architektur entwickeln zu können. Hier wird oft der Fehler gemacht, dass jede Content-Seite 1:1 als Portal-Seite abgebildet wird. Die hieraus entstehenden Probleme sollen mit diesem Blogeintrag beschrieben werden.
Unterschiede beider Systeme:
Seiten werden in einem CMS meistens statisch in Form von HTML-Seiten vorgehalten. In einem Portal sind alle Seiten jedoch Objekte, die im Speicher gehalten werden. Basiert das Portal auf Java-Technologien, so sind dies meistens JSPs. Werden nun alle Content-Seiten als JSPs abgelegt, führt dies unweigerlich zu Performance- und Memory-Problemen.
Schlechte Architektur:
In diesem Fall werden die Content-Seiten (inklusive der Content-Navigation) 1:1 innerhalb der Portal-Seiten abgebildet. Dies hat den großen Nachteil, dass jede Content-Seite (repräsentiert durch eine Portal-Seite) als Objekt Memory verbraucht. Neben dem Memory-Problem tritt auch noch ein Performance-Problem auf, falls zu viele Berechtigungen (Personalisierung) auf die einzelnen Content-Seiten vergeben werden.
Gute Architektur:
Hierbei wird darauf Wert gelegt, dass es nur ein (oder mehrere wenige) Content-Portlets gibt. Der Content wird basierend auf Abfragen integriert und nicht 1:1 abgebildet. Es ist auch vorstellbar, dass das Menü des Content-Portlets innerhalb der Hauptnavigation angezeigt wird.