Das Projekt PRISMA (Personalisierung von aggregierten Informationsströmen im Unternehmenskontext) ist ein gemeinsames Forschungsvorhaben der Communardo Software GmbH und der Technischen Universität Dresden (Professur für Rechnernetze), welches die bislang sehr zeitaufwendige Kommunikation und Zusammenarbeit zwischen Mitarbeitern mit technologieintensiven und kreativen Aufgaben verbessern soll.

Verschiedene  moderne Kommunikationskanäle wie E-Mail, Blogs, Twitter, Communote, RSS-Feeds und Instant Messaging sollen in PRISMA auf der Basis eines einheitlichen Transferformates von einem Web Service gebündelt und in unternehmensinternen Web-Portalen angezeigt und bearbeitet werden. Durch innovative Technologien aus dem Bereich Informationsextraktion und Personalisierung wird es möglich sein, Kommunikationsbeiträge automatisch thematisch und personenbezogen zu filtern bzw. zu aggregieren.

Im PRISMA-Projekt werden zu diesem Zweck die umfassenden Erfahrungen von Communardo im Bereich Enterprise Microblogging sowie der TU Dresden im Bereich semantischer Informationsextraktion und -integration gebündelt,  um ein innovatives System zu entwerfen, welches die Informationsflut im Unternehmen beherrschbarer macht.

Das Projektergebnis soll sich leicht in bestehende IT-Infrastrukturen von Unternehmen integrieren lassen und deren Wettbewerbsfähigkeit durch effizientere Kommunikation, bessere unternehmensinterne Zusammenarbeit und integriertes Wissensmanagement steigern.

Finanziell unterstützt wird das am 01.07.2010 gestartete zweijährige Projekt durch Mittel der Europäischen Union und des Freistaates Sachsen.

Die SharePoint-Technologie erobert derzeit große, kleine und mittlere Unternehmen im Sturm. Mit der 2010-Version wird Enterprise 2.0 zunehmend zur Realität. Die Möglichkeiten für Business Solutions, Management, Administration und Entwicklung sind deutlich erweitert worden. Dies sind sind die Themen der ShareConnect 2010, die vom 20. – 23. September 2010 in der Rheingoldhalle Mainz stattfindet.

Hier können Sie sich fit für SharePoint machen –  Experten geben Ihnen Einblick in ihre Erfahrungen und zeigen Ihnen, wie sich mit SharePoint optimale Ergebnisse erzielen lassen.

Um die gewaltigen Möglichkeiten des SharePoints auszuschöpfen, ist profundes Praxis-Know-how für Entwicklung und Management notwendig. Praxiswissen, dass Sie sich auf der ShareConnect aneignen können! Neben dem vielfältigen Programm der Hauptkonferenz beleuchten zwei Special Days wichtige Themen in einem umfassenden Sinn und bieten in zahlreichen Vorträgen kompaktes Fachwissen sowie einen idealen Rahmen für den Austausch von Erfahrungen. Alle Informationen und den Link zur Anmeldung finden Sie unter http://shareconnect.net/.

Communardo und die SharePoint Usergroup Dresden unterstützen die ShareConnect 2010 im Rahmen einer Medienpartnerschaft.

Am 27.07.2010 fand bei Communardo das 8. Treffen der SharePoint Usergroup Dresden statt, als Themen standen dieses Mal “Visio-Services: Potenzial und Alternativen” mit Kai-Uwe Gärtner sowie “Taxonomy Store und Social Tagging” mit Anne Rüger auf dem Programm.

In seiner Präsentation zeigte Kai uns, was man mit Visio Services alles machen kann, aber auch, wo deren Grenzen liegen.

Beeindruckend war die Demo insbesondere zur Anzeige der Visio-Diagramme im Browser incl. stufenlosem Zoom, Verschiebung und Drilldown durch verknüpfte Diagramme  - und das alles wirklich performant. Der komplette Funktionsumfang ist sogar ohne Silverlight möglich (das Diagramm wird dann als PNG gerendert), allerdings wirkt es dann mitunter etwas hakelig und “vermatscht”. Dies wird man aber hinzunehmen bereit sein, wenn man bedenkt, dass es dafür (nach Aussage von Kai) in wirklich jedem Browser läuft.

Auch die JavaScript Mash-Up-API, das Caching der Diagramme und die Workflow-Visualiserung (selbst für Workflows, die nicht in Visio designt wurden) sind nette Features.

Wo liegt nun der Haken? Es gibt einige (durchaus wichtige) Diagrammtypen, die durch Visio Services nicht unterstützt werden: Pivotdiagramm, Organisationsdigramm, Kalenderdiagramm, Gantdiagramm. Desweiteren werden versteckte Ebenen, Hintergrundseiten und Kommentare sowie weitere nützliche Visio Features nicht mit gerendert. Eine vollständige Liste findet sich unter http://blogs.msdn.com/b/chhopkin/archive/2010/05/03/supported-diagrams-and-entities-in-visio-services.aspx. Außerdem beschränken sich die Visio Services auf das Anzeigen der Diagramme im Browser – für deren Bearbeitung ist nach wie vor Visio erforderlich.

Ein Wermutstropfen und leider wohl nicht zu selten auch ein K.O.-Kriterium für den produktiven Einsatz der Visio Services dürfte die Tatsache sein, dass diese ausschließlich in der SharePoint Server 2010 Enterprise Edition verfügbar sind. Bei der zu diesem Punkt aufgeflammten Diskussion zu den einzelnen Editionen und den dort verfügbaren Features hatte Kai noch einen nützlichen Link in petto: http://sharepoint.microsoft.com/en-us/buy/Pages/Editions-Comparison.aspx.

Nach der mit Diskussionen und kulinarischer Stärkung verbrachten Pause lenkte Anne unsere Gedanken hin zum neuen Taxonomy Store von SharePoint 2010. Nachdem die Begrifflichkeiten geklärt waren, wurden Vor- und Nachteile von Taxonomie und Folksonomie beleuchtet. Den größten Raum nahm die Demo ein, in der Anne uns nicht nur die Verwendung von Terms und TermSets veranschaulichte, sondern auch die Konfiguration von ManagedMetadata Service sowie Content Type Hub vorführte. Als besonders coolen kleinen “Leckerbissen” empfinde ich die Metadata Navigation, die es dem User ermöglicht, die angezeigte Ergebnismenge in Listen und Bibliotheken mittels Drilldown zu verfeinern.

Auch wenn urlaubszeitbedingt das Treffen in eher kleinerer Runde stattfand, denke ich doch, dass es ein gelungener Abend mit spannenden Themen und Diskussionen war, aus dem jeder etwas für sich mitnehmen konnte. Vielen Dank an Anne und Kai als Vortragende sowie Martin als Organisator des Treffens!

Aus der Entwicklung mit ASP.NET und auch aus der Entwicklung mit WSS 3.0 und MOSS 2007 kennt man, dass man durch ändern der web.config (unter C:\inetpub\wwwroot\VirtualDirectories\Port_Number) erreichen kann, dass detaillierte Fehlermeldungen angezeigt werden. Dazu setzt man im Tag customErrors das Attribut “mode” auf den Wert “Off”. Diese Möglichkeit gibt es auch weiterhin in SharePoint 2010 und hat zur Folge, dass statt der relativ unaussagekräftigen aber dafür in einem frischen Design verfassten Fehlermeldung

der bekannte Yellow Screen of Death

erscheint.

Neu ist, dass es in Sharepoint 2010 nicht nur eine, sondern mehrere web.configs gibt, die relevant sind (s. http://msdn.microsoft.com/en-us/library/ms460914.aspx):

• \\Inetpub\wwwroot\VirtualDirectories\Port_Number
• \\Program Files\Common Files\Microsoft Shared\Web Server Extensions\wpresources
• %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\CONFIG
• %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\ISAPI
• %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\LAYOUTS

Ist ein WebPart also auf einer Inhaltsseite eingebunden, muss man die web.config unter C:\Inetpub\wwwroot\VirtualDirectories\Port_Number anpassen, um aussagekräftigere Fehlermeldungen zu erhalten, hat man das WebPart als Control auf einer Administrationsseite im _layouts-Ordner eingebunden, muss die web.config unter %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\LAYOUTS geändert werden.

Update:

Mittlerweile hat Atlassian einen Workaround entwickelt, der am Fehlerticket beschrieben ist.

Seit der Veröffentlichung der Version 3.6.7 des Mozilla Firefox am 20. Juli 2010 gibt es Probleme mit der Vorschaufunktion im Confluence. Dort werden die Inhalte der Vorschau abgeschnitten. Auch die inzwischen veröffentlichte Version 3.6.8 ist noch anfällig.

Für das Problem gibt es bereits ein Ticket im Atlassian Jira. Dort wird eine Lösung vorgestellt, die einen tiefen Eingriff ins System erfordert. Eine einfachere Lösung ist das Einfügen von folgendem HTML-Schnipsel als “Kundenspezifisches HTML”:

<style type="text/css">
#preview #previewArea iframe {

   overflow: visible;
}
</style>

Damit wird der für die Vorschau zuständige IFrame angewiesen, bei übergroßen Inhalten Scrollbars anzubieten. Im Ergebnis wird der Ansichtsbereich nicht auf die Höhe des Inhalts vergrößert, aber immerhin sind die Inhalte über die Scrollbars wieder  einsehbar:

Installationsanweisung

• Aufruf von Confluence Administration -> Gestaltung -> Kundenspezifische HTML
• Einfügen des obigen Codes in das Feld “Am Beginn des HAUPTTEXTES”

Mit SharePoint 2010 in Kombination mit Visio 2010 besteht nun die Möglichkeit, auch ohne SharePoint Designer Workflows zu definieren.

Im Bereich der Fluss-Diagramme findet man das Template Microsoft SharePoint Workflow. Auf Basis dieses Templates soll nun exemplarisch ein Workflow erstellt werden.

Hat man auf Basis des Templates eine neue Zeichnung erstellt, kann man direkt mit der Erstellung des Workflows beginnen. Wenn man schon mit Flussdiagrammen gearbeitet hat, ist die Handhabung recht einfach.

Der Anwendungsfall im Beispiel soll ein einfacher Urlaubsantrag sein. Mitarbeiter sollen in der Lage sein, Urlaubsanträge zu erfassen. Dieser soll zur Genehmigung einem Mitarbeiter der HR-Abteilung vorgelegt werden. Im Anschluss daran wird der beantragende Mitarbeiter über den Status seines Antrags informiert.

Um dies zu designen zieht man einfach die entsprechenden Shapes auf die Zeichnung und verbindet diese Shapes dann. Um die Lesbarkeit zu erhöhen und Aufgaben näher zu spezifizieren kann und sollte man die Standard-Texte anpassen.

Vor dem Export sollte man mit Hilfe des Menüpunktes “Diagramm überprüfen” einen Check auf Probleme durchführen. Ein Klick auf “Exportieren” erzeugt eine VWI-Datei, die als Austauschformat dient.

Schaut man sich diese Datei etwas näher an, wird man feststellen, dass sie den Workflow als VDX-Datei, als auch als XOML-Datei beinhaltet.

In meinem Beispiel gibt es 2 Listen: Die Benutzerdefinierte Liste Urlaubsanträge beinhaltet die Urlaubsanträge, die Kalenderliste Urlaubskalender beinhaltet die genehmigten Urlaube in der Übersicht.

Um aus der Visio-Zeichnung nun einen SharePoint-Workflow zu generieren, wird SharePoint Designer 2010 benötigt. Hier kann man die eben erstellte Austauschdatei importieren. In meinem Fall soll der Workflow als Listenworkflow an die eben genannte Liste Urlaubsanträge gebunden werden.

SharePoint Designer erzeugt nun einen Workflow, der schon der grundlegenden Struktur aus der Visio-Zeichnung entspricht, nun aber noch von einer technisch versierten Person mit Leben gefüllt werden muss.

Man sieht, dass als Hilfestellung die geänderten Beschriftungen aus Visio übernommen wurden.

Erster Schritt im Workflow ist die Prüfung auf einen genehmigungspflichtigen Urlaubsantrag. Hier könnte man den Inhaltstyp abfragen. In diesem Fall gibt es ein Feld Typ und wenn hier “Sonderurlaub” steht, soll eine Genehmigung erfolgen. Die Einrichtung ist recht selbsterklärend.

In den Workflow-Einstellungen kann man nun noch definieren, wann der Workflow starten soll (z.B. sobald ein Eintrag erstellt wurde) – das ist ja schon aus SharePoint bekannt.

Der Workflow kann nun auch wieder nach Visio exportiert werden. Es entsteht dabei wieder eine VWI-Datei, die in Visio importiert und weiter bearbeitet werden kann. Im Beispiel könnte man nun noch eine Eingangsbestätigung zu Beginn des Workflows versenden. Dazu wird der Workflow einfach im Visio geändert, exportiert und erneut in SharePoint Designer geöffnet.

Wie man sieht, sind alle Einstellungen noch enthalten, die neu hinzugefügten Schritte müssen nur noch bearbeitet werden.

Zusammenfassend kann man sagen, dass die Erstellung von Workflows per Visio in meinen Augen eine schöne Möglichkeit ist, von fachlicher Seite her zu definieren wie ein Prozess ablaufen soll. Die technische Umsetzung muss nach wie vor ein Entwickler oder Power-User durchführen.

Seit einiger Zeit bietet Communardo einen Migrationsservice an, mit dem Daten aus vorhandenen Altsystemen nach Confluence migriert werden können. Dabei kommt das Produkt Content Import Plugin (CIP) zum Einsatz. Dieses Plugin ist als Testversion frei verfügbar und kann über das Atlassian Plugin Exchange herunter geladen werden. Über einen Online Shop ist zudem der Erwerb einer Volllizenz möglich. Somit können Kunden, die den Migrationsservice nicht in Anspruch nehmen möchten, selbst Migrationen durchführen.

Dieser Artikel beschreibt einige unserer bisherigen Erfahrung bei der Durchführung solcher Migrationen. Er richtet sich sowohl an Kunden, die eine solche Migration selbst durchführen möchten, als auch an Kunden, die unseren Migrationsservice nutzen möchten.

Vorgehen bei einer Migration

Migrationen mit dem CIP werden grundsätzlich zweistufig durchgeführt: Zunächst werden die Daten des Quellsystems in ein XML-Transportformat exportiert. Dieses wird anschließend mit dem CIP in das Confluence Zielsystem importiert.

Das Transportformat bildet dabei sämtliche Inhaltstypen (Bereiche, Seiten, Blogposts, Dateianhänge) samt Metadaten (Autor, Erstell- und Änderungsdatum) ab. Auch die Seitenhierarchie und interne Verlinkungen werden unterstützt.

Erwartungshaltung des Kunden vs. Machbarkeit

Unsere bisherigen Erfahrungen zeigen, dass von der Kundenseite häufig sehr hohe Erwartungen an die Migration gestellt werden. Diese beziehen sich meist auf die Punkte

• inhaltliche Vollständigkeit
• gleiches Aussehen
• Funktionalität bleibt erhalten.

Die inhaltliche Vollständigkeit kann mithilfe des Transportformats sichergestellt werden. Sämtliche Seiten und deren Inhalte können davon abgebildet und folglich nach Confluence migriert werden.

Allerdings ist es nicht möglich, die Darstellung der Informationen und eventuelle Funktionalität (JavaScript) verlustfrei zu migrieren. Die folgende Grafik verdeutlicht das prinzipielle Problem dahinter:

Die Kreise stellen den Darstellungs- und Funktionsumfang verschiedener Auszeichnungsformate dar. HTML bietet dabei den größten Funktions- und Variationsumfang. Mit Confluence Wiki-Code lassen sich viele Artefakte von HTML formulieren, wobei es auch zusätzliche Funktionalitäten gibt (z.B. Makros), die mit HTML nicht direkt umsetzbar sind. Ähnlich verhält es sich auch mit MediaWiki-Code.

Anhand dieses Diagramms wird klar, dass man Inhalte, die in einem MediaWiki vorliegen nicht verlustfrei nach Confluence migrieren kann, da MediaWiki Konzepte kennt, die nicht auf Confluence abbildbar sind (z.B. zusammengefasste Tabellenzellen). Ebenso lassen sich nicht sämtliche in HTML formulierbaren Inhalte nach Confluence migrieren (z.B. Definitionslisten).

In manchen Fällen können bei der Migration alternative Auszeichnungen gefunden werden, die eine ähnliche Darstellung ermöglichen. Beispielsweise könnten Definitionslisten in verschachtelte Listen umgewandelt werden. Für verschachtelte Tabellen hingegen gibt es derzeit keine Möglichkeit einer Abbildung in Confluence.

Ein weiteres Problem ist die Darstellung bestimmter Elemente. So kann eine Überschrift, die aus MediaWiki heraus migriert wird im Confluence vollkommen anders aussehen. Der Inhalt wurde dabei vollständig migriert, allerdings unterscheidet sich die Darstellung in beiden Systemen. Formatierungsanweisungen, die beispielsweise mit CSS im Quellsystem hinterlegt sind, können nicht migriert werden. Nur über die Entwicklung eines Confluence Theme Plugins ist es möglich, die Darstellung der Inhalte anzupassen.

Beispiele für Migrationsprobleme

Im Folgenden werden einige Probleme aufgelistet, die in den bisherigen Migrationsprojekten eine Rolle gespielt haben. Daran lässt sich recht gut erkennen, was eine Migration leisten kann, und wo die Grenzen der technischen Machbarkeit liegen.

Layouttabellen

Vor einigen Jahren war die Benutzung von Layouttabellen als Gestaltungsmittel von Webseiten vollkommen normal. Dies sind Tabellen, die keine sichtbaren Ränder aufweisen. So war es dem Autor einer Webseite leicht möglich, Inhaltselemente nebeneinander oder in einem definierten Raster anzuordnen. Auf diese Weise konnte beispielsweise die Seitennavigation neben die Inhaltsspalte gesetzt werden.

Da Confluence das Konzept von randlosen Tabellen nicht kennt, ist es nicht möglich derartige Layouttabellen ohne Darstellungsunterschiede zu migrieren. Die fehlende Unterstützung für verschachtelte Tabellen verschärft dieses Problem weiter.

Tabellen mit verbundenen Zellen

Mithilfe von HTML ist es möglich, einzelne Zellen einer Tabelle in horizontaler (colspan) oder vertikaler (rowspan) Richtung zu verbinden. Auf diese Weise können beispielsweise Tabellenköpfe erstellt werden, die sich über mehrere Spalten erstrecken.

Auch für derartige Zellverbünde bietet Confluence keine Formulierungsmöglichkeit. Zusammengefasste Tabellenzellen könnten demnach nur mit darstellerischen und inhaltlichen Verlusten überführt werden.

Manuell geschriebenes HTML

Als besonders schwerwiegend hat sich per Hand geschriebenes HTML herausgestellt. Viele Content Management Systeme verwenden sogenannte WYSIWYG-Editoren, um die Inhalte zu bearbeiten. Diese Editoren zeigen nicht den HTML-Code des Seiteninhalts an, sondern zeigen den Inhalt so, wie er später auf der Seite zu sehen sein wird. Diese Editoren haben den Vorteil, dass immer gleichartiges HTML generiert wird.

Für derartig generierte Inhalte können recht gute Migrationsmuster erkannt und entsprechend im Confluence abgebildet werden. Wurde der Seiteninhalt jedoch manuell geschrieben, ist der HTML-Code nicht gleichförmig. Solches Markup ist extrem schwierig zu migrieren, da dort prinzipiell der vollständige Funktionsumfang von HTML genutzt werden kann. Bei Migrationen, die manuell geschriebene HTML-Seiten als Quelle haben ist demzufolge mit beträchtlichen Darstellungsverlusten zu rechnen.

Interne Verlinkungen

Das Erkennen und korrekte Umwandeln von internen Verlinkungen kann sich mitunter äußerst schwierig gestalten. Mitunter sind schon die Verlinkungen des Quellsystems fehlerhaft, sodass diese nicht direkt ins Confluence übertragen werden können. Manchmal ist es notwendig, Ähnlichkeitsberechnungen mit den vorliegenden Links durchzuführen, um das “am besten passende Linkziel” auszuwählen.

Strukturierung der Informationen

Confluence bietet von sich aus folgende Möglichkeiten zur Strukturierung:

• Bereiche mit Seiten und Blogposts
• Seiten können Unterseiten haben (Baumstruktur)
• Seiten und Blogposts können Dateianhänge haben

Gibt es im Quellsystem Inhaltsstrukturen, die über diese hinaus gehen (z.B. mehrsprachige Inhalte), können diese nicht direkt auf die korrespondierenden Confluence-Typen abgebildet werden. Nur über die Nutzung oder Entwicklung weiterer Plugins (z.B. Communardo SubSpace Plugin für hierarchische Bereiche) ist eine Migration möglich.

Häufig sollen die Quelldaten zudem umstrukturiert werden. Durch das Einfügen generierter Übersichtsseiten und die Verteilung auf mehrere Bereiche wird die Komplexität zum Auflösen interner Verlinkungen weiter erhöht.

Unvorhersehbares Verhalten des Confluence-internen Wiki-Code-Konverters

Die Umwandlung von gegebenen HTML in Confluence-spezifischen Wiki-Code geschieht mittels einer internen Confluence-Componente (WysiwygConverter). Dieser hat erhebliche Probleme bei der Umwandlung von beliebigem (nicht vom WYSIWYG-Editor erzeugtem) HTML in Confluence Wiki-Code.

Schon kleinste Unterschiede im Quell-HTML-Code (z.B. Zeilenumbrüche, Verschachtelung von Elementen) können zu vollkommen verschiedenem Resultat führen. Insbesondere bei manuell geschriebenen HTML sind Migrationsverluste dadurch nicht zu vermeiden.

Zusammenfassung

Die Migration von Inhalten nach Confluence ist mit dem Content Import Plugin nahezu ohne Verluste möglich. Die Darstellung der Informationen muss jedoch an Confluence angepasst werden und unterscheidet sich folglich fast zwingend vom Quellsystem. Weiterhin ist es nicht möglich, Konzepte oder Funktionen nach Confluence zu migrieren, die im Quellformat verfügbar sind, sich jedoch nicht auf existierende Confluence-Konzepte abbilden lassen (verschachtelte Tabellen, Definitionslisten, …)

Weiterführende Links

• Produktblatt Migrationsservice (PDF)
• Produktseite Content Import Plugin
• Beschreibung des XML Transportformats (PDF, englisch)
• SubSpace Plugin

Motivation

Umsetzung – Backend

Ein kleiner – aber wie ich finde vertretbarer – Wermutstropfen ist, dass es nicht ohne Anpassung des Confluence-Cores geht. Die abgeänderten Dateien, die nachfolgend erläutert werden, packt man am besten in eine jar und legt diese in das WEB-INF/lib Verzeichnis.

Erstellen einer ThreadLocale ShowI18NKeysThreadLocal

Die Aktivierung/Deaktivierung der Funktion wird über einen Schalter in der GUI realisiert. Damit der Zustand ins Backend übertragen werden kann, wird eine ThreadLocale verwendet. Diese ist wie folgt aufgebaut:

public class ShowI18NKeysThreadLocal {

  public static final ThreadLocal showI18nKeysLocal = new ThreadLocal () {
    protected synchronized Boolean initialValue() {
      return false;
    }
  };

}

Überschreiben der DefaultI18NBean Klasse

Die DefaultI18nBean besitzt u.a. eine Methode namens isShowKeyMode. Mit dieser Methode wird abgefragt, ob die Schlüssel-Wert Paare zurückgeliefert werden sollen. Nun vermutet man, dass die Methode aus einer Property, etc… den Zustand (aktiv, inaktiv) ausliest. Dies ist leider nicht der Fall, da sie immer den Wert false (hard-codiert) zurückliefert, sodass ohne dem Überschreiben der Methode ein Switch gar nicht möglich ist. Deshalb muss die Klasse wie folgt erweitert werden.

  public ExtendedDefaultI18NBean(Locale locale, PluginAccessor pluginManager) {
    super(locale, pluginManager);
  }

  @Override
  public boolean isShowKeyMode() {
    return ShowI18NKeysThreadLocal.showI18nKeysLocal.get();
  }

Überschreiben der DefaultI18NBeanFactory Klasse

Die Klasse DefaultI18NBean wird nicht wie die meisten Klassen per Spring Injection erzeugt, sondern über eine Factory-Klasse. Aus diesem Grund muss auch die DefaultI18NBeanFactory wie folgt überschrieben werden.

 public class ExtendedDefaultI18NBeanFactory implements I18NBeanFactory {

  private PluginAccessor pluginAccessor;

  public I18NBean getI18NBean(Locale locale) {
    return new ExtendedDefaultI18NBean(locale, pluginAccessor);
  }

  public I18NBean getI18NBean() {
    return getI18NBean(LocaleManager.DEFAULT_LOCALE);
  }

  public void setPluginAccessor(PluginAccessor pluginAccessor) {
    this.pluginAccessor = pluginAccessor;
  }

}

Anpassen der i18nContext.xml

Damit nun die von uns angepasste Factory-Klasse verwendet werden kann, muss in der i18nContext.xml der zugehörige Eintrag wie folgt angepasst werden:

<bean id="defaultI18NBeanFactory" class="de.communardo.customizations.i18n.ExtendedDefaultI18NBeanFactory" autowire="byName"/>

Anpassen der web.xml

Letztlich ist es noch notwendig, dass die web.xml auf die abgeänderte i18nContext.xml verweist. Dazu muss die entsprechende Zeile wie folgt angepasst werden.

    <context-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>
            ...,
            classpath:/customizedI18nContext.xml,
            ...,

Umsetzung – Frontend

Wie zuvor bereits erwähnt, zielt dieses Vorgehen auf eine Laufzeitlösung ab, sodass im Frontend ein entsprechender “Schalter” implementiert werden muss. In diesem Beispiel werden die Frontend-Anpassungen über ein Plugin durchgeführt.

Erstellen der ShowI18NKeyFilter Klasse

Der neue Filter hat einzig und allein die Aufgabe zu überprüfen, ob und auf welchen Wert der Request-Parameter showI18nKeys gesetzt ist. Sollte der Wert true sein, dann werden beim Reload der aktuellen Seiten nicht mehr nur die Texte, sondern auch die zugehörigen Schlüssel angezeigt. Außerdem wird der aktuelle Zustand in der Session vermerkt, sodass beim Seitenwechsel der gewünschte Zustand immernoch existiert. Natürlich wirkt sich die Zustandsänderung nur auf den aktuellen Nutzer aus und beeinflusst nicht die Sicht der anderer Nutzer!

public class ShowI18NKeyFilter implements Filter {

  private static final String I18N_KEYS = "showI18nKeys";

  private static final String CONFLUENCE_I18N_SHOWKEY = "confluence.i18n.showkey";

  public void destroy() {

  }

  public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException,
      ServletException {

    if (request instanceof PluginHttpRequestWrapper) {
      PluginHttpRequestWrapper httpRequest = (PluginHttpRequestWrapper) request;
      Boolean showI18nKeysSession = (Boolean) httpRequest.getSession().getAttribute(CONFLUENCE_I18N_SHOWKEY);
      if (httpRequest.getParameter(I18N_KEYS) != null) {
        Boolean showI18nKeysRequest = Boolean.valueOf(httpRequest.getParameter(I18N_KEYS));
        if (showI18nKeysRequest != showI18nKeysSession) {
          if (showI18nKeysRequest) {
            httpRequest.getSession().setAttribute(CONFLUENCE_I18N_SHOWKEY, true);
            ShowI18NKeysThreadLocal.showI18nKeysLocal.set(true);
          } else {
            httpRequest.getSession().removeAttribute(CONFLUENCE_I18N_SHOWKEY);
            ShowI18NKeysThreadLocal.showI18nKeysLocal.set(false);
          }
        }
      } else {
        ShowI18NKeysThreadLocal.showI18nKeysLocal.set(showI18nKeysSession != null ? showI18nKeysSession : false);
      }
    }
    chain.doFilter(request, response);
  }

  public void init(FilterConfig arg0) throws ServletException {

  }

}

Anpassung einer vm Datei

Letztlich fehlt nur noch ein Link (am besten im Header, da diese Stelle auf fast allen Seiten sichtbar ist), welcher den GET-Parameter showI18nKeys konträr zum aktuellen Zustand den Wert auf true bzw. auf false übermitteln soll.