CMS Projekte intelligent aufbauen

Ein CMS Projekt kann auf unterschiedliche Weise erstellt werden. Um ein Projekt jedoch langfristig wartbar zu gestalten, lohnt es sich bereits vor Beginn der Arbeit Gedanken über die spätere Struktur zu machen.Wichtig ist es, die eigene Sicht nicht auf die eigene Projektrolle zu beschränken, sondern auch die Sichten der Redakteure einnehmen, um so zielgerichtet Workflows und Content-Klassen zu erstellen, die der Arbeitweise der Benutzer entsprechen. Quasi-Standard ist der Einsatz des Navigationmanagers und Rendertags.

Grundlage eines Projekts
In allen Projekten gibt es eine Einstiegsseite für den Redakteur, dort werden, neben Shortcuts zu wichtigen Seiten und/oder Funktionalitäten, Links zu wichtigen, globalen Seiten dargestellt. Der Redakteur soll schließlich schnell und unkompliziert navigieren können, ohne sich durch eine lange Liste in der Ablage zu wühlen.

Der Aufbau
Diese Seiten sollten auf jeden Fall vorhanden sein:

  • CSS
  • Javascript
  • Translation Page
  • Settings
  • Startseite
CSS Über den besten Einsatz von CSS innerhalb von RedDot Projekten wurde bereits viel und ausgiebig diskutiert, es leider keinen endgültige Lösung. Während des Aufbaus eines Projektes ist es von Vorteil, das CSS von einer externen Quelle zu laden, um so unnötige Arbeit an den Content-Klassen zu ersparen. Ob es nach einer Abnahme durch den Kunden in das CMS integriert wird, hängt von der jeweiligen Präferenz ab. Javascript Hier kommen alle Bibliotheken rein, die das Projekt benötigt, dabei ist es wichtig, sich auf ein Framework zu beschränken und die Funktionalitäten an den SmartEdit Modus anzupassen. Translation Page Die Basis eines effektiven CMS Projekts bilden Rendertags. Diese sind in Version 7.5 in das RedDot CMS integriert worden und ermöglichen es, unkompliziert auf nahezu beliebige Inhalte zuzugreifen. Rendertags ermöglichen es, Elemente aus verschiedenen Content-Klassen an einem zentralen Punkt zu pflegen - der Translation Page. Dies sei am Beispiel einer Newsliste erklärt:
<div id="newslist">
	<ul>
		<!IoRangeList>
			<li>
				<a href="<%lst_news%>"><%hdl_headline%></a><br>
				<%!! Context:Pages.GetPage(Guid:TranlationPage).Elements.GetElement(stf_newslist_more).Value !!%>
			</li>
		<!/IoRangeList>
	</ul>
</div>
Auch wenn es nur ein kleines Beipiel für den Einsatz darstellt, ist der Sinn schnell ersichtlich. Der Entwickler/Redakteur muss nicht mehr in jeder Content-Klasse einzelne Elemente pflegen, sondern kann dies übersichtlich auf einer einzelnen Seite erledigen. Ich bin dazu übergegangen, den Namen des Zielelements zu benutzen - um es übersichtlicher zu gestalten und Namenskonflikte zu vermeiden besteht der Name aus drei Bestandteile: der Typ, der Einsatzbereich und der eigentliche Bezeichner. Diese Vorgehensweise benötigt mehr Disziplin als der Einsatz normaler Elemente, belohnt dies jedoch mit einer ungeahnten Flexibilität und Übersichtlichkeit. Settings Analog zu der Translation Page wird eine weitere Seite erstellt, um spezielle Einstellungen global vornehmen zu können. Dazu zählen Google-Maps-Api-Key, Analytics-Code, globale Vorbelegungen für Meta-Keys und Meta-Description sowie weitere Einstellungen, die nicht unbedingt jeder Redakteur vornehmen können muss. Startseite Dieser Link stellt dem Redakteur einen Shortcut zur Startseite bereit, ohne sich durch eine etwaige Hilfskontruktion klicken zu müssen.