Sitecore – Frontend Integration mit Terrific / Terrific Composer Teil 3

Die Logik der Handlers

Welche Handler und/oder Helpers werden benötigt? Für die Rückgabe des korrekten CSS wird ein CSS-Handler eingesetzt  – dieser erbt vom CssHandler aus unserem eigenen Framework:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
/// <summary>
/// CSS Handler for the Customer-Page Frontend. Returns the correct CSS.
/// </summary>

public class Css : CssHandler
{
///<summary>
/// Get all CSS files in the correct order. First all libraries, utils, elements
/// and plugin files. then the layouts css and at the end the sublayouts css.
/// </summary>

///Content of all files

protected override string GetContent()
{
var sb = new StringBuilder();
sb.Append(FrontendFileHandler.ReadDirectory("Frontend/Mandant/Assets/css/libraries"));
sb.Append(FrontendFileHandler.ReadDirectory("Frontend/Mandant/Assets/css/utils"));
sb.Append(FrontendFileHandler.ReadDirectory("Frontend/Mandant/Assets/css/elements"));
sb.Append(FrontendFileHandler.ReadDirectory("Frontend/Mandant/Assets/css/plugins"));
sb.Append(FrontendFileHandler.ReadDirectory("Frontend/Mandant/Layouts"));
sb.Append(FrontendFileHandler.ReadDirectory("Frontend/Mandant/SubLayouts"));
return sb.ToString();
}
}

In einem BaseHandler wird der FrontendFileHandler gesetzt. In einer nächsten Methode wird der Inhalt aller CSS Files inkludiert mit der Definition des Filenamen, Unterscheidung ob der Cache geleert werden soll oder nicht.

Im Header-Usercontrol werden die CSS-Includes gerendert. Hierfür wird die Methode GetCssInclude mit entsprechenden Parametern aufgerufen. Die Beschreibung zu den Parametern gleich nachher in der Beispielmethode. Hierzu ein Codebeispiel:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
/// <summary>
/// Renders the CSS includes.
/// </summary>

private void RenderCssIncludes()
{
try
{
StringBuilder sb = new StringBuilder();

sb.AppendLine(ConfigurationManager.GetCssInclude(null, true, Assembly.GetExecutingAssembly(), true));
sb.AppendFormat("<!--[if IE]>{0}<![endif]-->\n", ConfigurationManager.GetCssInclude("ie", true, Assembly.GetExecutingAssembly(), true));

this.litCssFiles.Text = sb.ToString();
}
catch (Exception)
{
Logger.Error("Error can't render CSS Includes in Head.ascx");
}
}

Die Methode „GetCssInclude“

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
/// <summary>
/// Returns the include for the Stylesheet Files.
/// </summary>
/// <param name="pTag">
/// Tag of the Stylesheet. IE, IE6, IE7, usw.
/// </param>
/// <param name="pUseLocalPathOnStaticCall">
/// Use Local Path On Static Call.
/// </param>
/// <param name="pAddAssemblyToVersionKey">
/// The p Add Assembly To Version Key.
/// </param>
/// <param name="pUseSitecoreVersionNumber">
/// The p Use Sitecore Version Number.
/// </param>
/// <returns>
/// Returns the Include Tag for a stylesheet
/// </returns>

public static string GetCssInclude(string pTag = null, bool pUseLocalPathOnStaticCall = false, Assembly pAddAssemblyToVersionKey = null, bool pUseSitecoreVersionNumber = false)
{
string url = GetFrontendFile("css", pTag, pUseLocalPathOnStaticCall, pAddAssemblyToVersionKey, pUseSitecoreVersionNumber);

return !string.IsNullOrEmpty(url)
? string.Format(" ", url)
: string.Empty;
}

Die Methode „GetFrontendFile“ gibt den Pfad für das CSS oder JS-File zurück. Ebenso wird anschliessend noch z.Bsp. eine Assembly-Version dem File angehängt um sicher immer das aktuellste File zu laden.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
/// <summary>
/// Returns the Path to the JS or CSS file thats requestetd. Depeding on the Config
/// Settings of the Frontend Settings Item in the Configuration Part. It checks if the
/// file exists and returns then the correct url to the handler or to the static file.
/// </summary>

////// The Extension of the file. Normally JS or CSS
/// ////// Tag of the File (IE, IE6, usw.)
/// ////// The p Use Local Path On Static Call.
/// ////// The p Add Assembly To Version Key.
/// ///Activate the Sitecore Version Number
/// Suffix
/// ///
/// Returns the URL of the Frontend File
///
public static string GetFrontendFile(string pExtension, string pTag = null, bool pUseLocalPathOnStaticCall = false, Assembly pAddAssemblyToVersionKey = null, bool pUseSitecoreVersionNumber = false)
{
// Get the Configuration Items
Item frontendSettingsItem = GetConfigItem("/Frontend Settings");
if (frontendSettingsItem == null)
{
Log.Warn("The config item for the Frontend Settings do not exist.", typeof(ConfigurationManager));
}
else
{
CheckboxField debugCheckboxField = frontendSettingsItem.Fields["Debug"];
CheckboxField staticCheckboxField = frontendSettingsItem.Fields["Static"];
TextField rootFolderPrefix = frontendSettingsItem.Fields["Root Folder Prefix"];
TextField additionalVersionKey = frontendSettingsItem.Fields["Version Key"];
string folderPrefix = rootFolderPrefix != null ? rootFolderPrefix.Value : string.Empty;
var version = VersionNumber(pAddAssemblyToVersionKey);
var versionPrefix = string.Empty;
var browserTag = string.Empty;

if (pUseSitecoreVersionNumber &amp;&amp; additionalVersionKey != null &amp;&amp; !string.IsNullOrEmpty(additionalVersionKey.Value))
{
version = string.Format("{0}_{1}", version, additionalVersionKey.Value);
}

if (debugCheckboxField == null || staticCheckboxField == null)
{
Log.Warn(
"The config item for the Frontend Settings does not have the static or debug checkboxfield.",
typeof(ConfigurationManager));
}
else
{
// returns the ashx-handler if the dynamic file content is needed
if (pUseLocalPathOnStaticCall &amp;&amp; staticCheckboxField.Checked.ToString(CultureInfo.InvariantCulture).ToLower().Equals("true"))
{
if (!string.IsNullOrEmpty(version))
{
versionPrefix = "?version=";
}

if (!string.IsNullOrEmpty(pTag))
{
browserTag = pTag + ".";
}

If (debugCheckboxField.Checked.ToString(CultureInfo.InvariantCulture).ToLower().Equals("true"))
{
var fileDebug = string.Format("{0}/assets/base/static/base.{2}debug.{1}", folderPrefix, pExtension, browserTag);
if (System.IO.File.Exists(string.Format("{0}{1}", MappedApplicationPath, fileDebug.Replace("/", "\"))))
{
fileDebug = string.Format("
{0}{1}{2}", fileDebug, versionPrefix, version);
return fileDebug;
}
}

var file = string.Format("
{0}/assets/base/static/base.{2}{1}", folderPrefix, pExtension, browserTag);
if (System.IO.File.Exists(string.Format("
{0}{1}", MappedApplicationPath, file.Replace("/", "\"))))
{
file = string.Format("
{0}{1}{2}", file, versionPrefix, version);
return file;
}
}

if (!string.IsNullOrEmpty(version))
{
versionPrefix = "
&amp;version=";
}

return string.Format(
"
{4}/assets/base/{0}.ashx?debug={1}&amp;static={2}{3}{5}{6}",
pExtension,
debugCheckboxField.Checked.ToString(CultureInfo.InvariantCulture).ToLower(),
staticCheckboxField.Checked.ToString(CultureInfo.InvariantCulture).ToLower(),
!string.IsNullOrEmpty(pTag) ? "
&amp;tag=" + pTag : ^ string.Empty,
folderPrefix,
versionPrefix,
version);
}
}

return string.Empty;
}

private static string VersionNumber(Assembly pAssembly)
{
try
{
if (pAssembly != null)
{
var assemblyName = pAssembly.GetName();
if (assemblyName.Version != null)
{
return assemblyName.Version.ToString().Replace("
.", "-");
}
}

}
catch (Exception)
{
return string.Empty;
}

return string.Empty;
}

Eine weitere wichtige Klasse ist das TerrificUserControl. Hier werden zum einen verschiedene Properties gesetzt wie: zusätzliche Attribute, Connector, Modulname, Skin oder auch ein Tagname. In der RenderControl-Methode wird das entsprechende Terrific User Control gerendert mit dem jeweiligen Modulnamen, Skin und allen benötigten Connectors. Z.bsp.:

1
pWriter.Write(string.Format("", ModName, SkinName, ConName, AdditionalAttributes, TagName));

Sitecore – Frontend Integration mit Terrific / Terrific Composer Teil 2

Frontend-Integration in VisualStudio Solution

Das Terrific wird nun wie folgt in unsere VisualStudio Solution integriert. Als Versionskontroll-Software setzen wir TortoiseSVN ein. Mittels SVN-Externals setzen wir die Verbindung zu den benötigten Elementen für das Layout, die Module sowie die benötigten Elemente aus dem Assets-Folder (css, js, images, etc.).

Was benötigen wir alles? Dies ist mal sicher der „layout“-Folder aus dem Terrific für unser Seitenlayout (Grid). Weiter brauchen wir alle Module aus dem Terrific (public/modules) für unsere Komponenten sowie den Assets-Folder für die allgemeinen Elemente wie JavaScripte, CSS, Bilder usw.

Wie richte ich nun meine SVN-Externals ein?

Einzelseite: die SVN-Externals werden immer auf dem übergeordneten Ordner erstellt, sprich für diesen Fall direkt auf dem Projekt für die WebApplication. Im Fileexplorer mittels rechter Maustaste auf Kundenname.WebApp-Folder –> TortoiseSVN –> Properties.

Im nächsten Dialog klicken wir auf „New…“. Nun kommen wir zur Erstellung des Externals.

Local path: hier definieren wir den Namen des Externals welcher in der Solution dargestellt wird.

URL: hier geben wir den Pfad auf unseren gewünschten Terrific-Folder an.

Wir benötigen nun für unser Einzelseiten-Projekt folgende 3 Externals:

Path URL
Assets https://svn-url/projektname/Terrific/public/Assets
Layouts https://svn-url/projektname/Terrific/public/layout
SubLayouts https://svn-url/projektname/Terrific/public/modules

Wichtig: als nächster Schritt muss auf der WebApp ein SVN Update gemacht werden. Hier werden nun diese 3 Folder in unserer Solution erstellt/hinzugefügt und anschliessend kann die Solution Commitet werden.

Mandanten:  bei einem Auftritt mit mehreren Mandanten wird in der VisualStudio Solution im WebApplication Projekt ein Folder „Frontend“ angelegt. Darin wird für jeden Mandanten ein Folder angelegt und auf diese Folder setzen wir dann unsere SVN Externals.

Im Fileexplorer mittels rechter Maustaste auf „Kundenname.WebApp\Frontend\01_Mandant“-Folder  –> TortoiseSVN –> Properties. Dann wie oben beschrieben „New…“ –> „Externals“. Die Pfade benennen wir genau gleich wie bei einer Einzelseite und geben die entsprechenden Urls’s zum Terrific an.

Path URL
Assets https://svn-url/projektname/Terrific/01_Mandant/
public/Frontend/Mandant/Assets
Layouts https://svn-url/projektname/Terrific/01_Mandant/public/layout
SubLayouts https://svn-url/projektname/Terrific/01_Mandant/public/modules

 

Path URL
Assets https://svn-url/projektname/Terrific/02_Mandant/
public/Frontend/Mandant/Assets
Layouts https://svn-url/projektname/Terrific/02_Mandant/public/layout
SubLayouts https://svn-url/projektname/Terrific/02_Mandant/public/modules

All diese Einstellungen müssen natürlich für die entsprechenden Mandanten erstellt werden.

Wichtig: als nächster Schritt muss auf der WebApp ein SVN Update gemacht werden. Hier werden nun diese Folder in unserer Solution erstellt/hinzugefügt und anschliessend kann die Solution Commitet werden.

Für den Frontend-Engineer ändert sich grundsätzlich nichts, er kann nach wie vor in seiner gewohnten Umgebung arbeiten, einzig beim Einrichten des Terrifics muss darauf geachtet werden, ob es mehrere Mandanten gibt oder nicht und entsprechend die Folderstruktur erstellt oder von einem bestehenden Projekt kopiert werden.

Sitecore – Frontend Integration mit Terrific / Terrific Composer Teil 1

Schon seit geraumer Zeit setzen wir für professionelle Frontendentwicklung Terrific oder seit letztem Jahr auch den Terrific Composer ein. Was ist Terrific in einem Satz?

Terrific basiert auf der Idee, das Frontend in wiederwendbare, modulare Lego-Bausteine aufzuteilen.

Eine detaillierte Beschreibung inkl. Downloads und Möglichkeit einen Teil der Features gleich auszuprobieren findet Ihr hier:  http://terrifically.org

History und Motivation

Beim Start von Terrific für die Frontendentwicklung gab es keine Integration in die entsprechende Sitecore VisualStudio Solution. Die Probleme sind da vorprogrammiert, denn die Frontend-Solution liegt nicht im selben Repository, eine mögliche Struktur sah wie folgt aus:

Die Schwierigkeit lag darin, dass nach Abschluss der Frontendentwicklung das generierte JS- sowie CSS-File aufgerufen, gespeichert und dann in der Sitecore-Solution integriert werden musste. Dies stellt kein Problem dar, wenn alles im ersten Schritt fertiggestellt wird, keine Fehler gemacht wurden, keine Änderungen/Change Requests kommen. Sobald die Backendentwicklung in Sitecore begonnen hat, besteht die Gefahr dass auf der Sitecore Seite Änderungen direkt im JavaScript oder CSS gemacht wird und Diese dann nicht in das Terrific zurückfliessen oder natürlich auch umgekehrt. Es liegen wenn man so will 2 Files im entsprechenden Projekt (Sitecore und Terrific) – wer ist nun der Master?

Ein weiterer Aspekt sind die ganzen Module sowie die Views (Pagelayouts) und das Layout selbst. Die Module und Views mussten im Terrific geöffnet und herauskopiert werden was doch ziemlich mühsam war und der Backendentwickler musste entweder dies auf einem Stagingserver tun oder selbst lokal Terrific am laufen haben.

Da stellt sich nun die Frage, wie können wir das ganze verbessern, vereinfachen sowie integrieren. Die Idee war, dass es doch möglich sein muss, die Zusammenarbeit zwischen Backendentwickler sowie Frontendentwickler zu vereinfachen:

–          JavaScript und CSS in VisualStudio Solution bringen

–          Module und Views in VisualStudio Solution bringen

–          Frontendentwickler kann unabhängig davon in seiner gewohnten Umgebung und Struktur weiterarbeiten

Terrific Struktur

Um nachher die Integration in die VisualStudio Solution duchführen zu können, bedarf es einiger Anpassungen. Gerne zeige ich gleich 2 Beispiele – Einzelwebsite sowie Mandanten-Websites. Hierfür schauen wir uns die Strukturen sowie den public-Folder der Terrific Installation etwas genauer an.

Terrific (Einzelseite) – public-Folder

Im „public“-Folder einer Terrific-Einzelseite finden wir wie schon in der Ausgangslage die Folder für das Layout sowie die Module. Was sich hier etwas geändert hat ist die Struktur im sogenannten „assets“-Folder. Darin platzieren wir einen Base-Folder für die beiden Handler (js/css). Weiter wird der „css“-Folder wie auch der „elements“-Folder aus der ursprünglichen Terrific-Installation mit den Files/Folder für „elements“, „libraries“, „pageEditor“, „plugins“, „utils“ usw. in den „assets“ Folder verschoben. Des Weiteren finden wir im „assets“-Folder ebenso die Files/Folder für die „fonts“,“ js“  und „img“.

Terrific (Mandanten)

Bei mehreren Mandanten wird im Root des Terrific für jeden Mandanten ein „eigenes“ Terrific erstellt mit der folgenden Struktur im „public“ Folder:

–          Configs, data, layout, modules und temp Folder identisch wie bei einer Einzelinstallation

Neu: Frontend-Folder
der „Frontend“-Folder bekommt folgende Struktur: Mandanten-Name > Assets > und darin dann wie gehabt die Struktur wie bei einer Einzelinstallation (base für die Handlergeschichten, css, fonts, img, js)

Wie könnt ihr das gleichzeitige Bearbeiten von Inhalten durch mehrere Autoren verhindern?

Im Ribbon Bar (Menü) des Page Editors steht euch unter dem Register „Home“ das Lock Icon zur Verfügung. Um die Inhalte für weitere Autoren zu sperren wählt ihr die entsprechende Komponente, den entsprechenden Inhalt aus und klickt anschliessend auf das „Lock Icon“.

Sitecore - gesicherte Inhalte wieder entsperren

Die gesperrten Inhalte werden unter „My Items (x)“ aufgelistet. Um die Inhalte nach dem Bearbeiten wieder für andere Autoren freizugeben klickt auf „My Items“, wählt den gesperrten Inhalt aus und klickt anschliessend auf „Unlock“. So steht der Inhalt wieder für weitere Autoren zur Bearbeitung zur Verfügung.

Sitecore My Items

Hinweis: Die Ansicht im Ribbon Bar (ob das Lock Icon sichtbar ist) ist abhängig von euren persönlichen Zugriffsrechten. Webadministratoren können grundsätzlich alle Inhalte bearbeiten. Sollte es passieren, dass ein Webadministrator und ein anderer Benutzer die Inhalte gleichzeitig bearbeiten, werden die Änderungen die als erstens gespeichert werden übernommen. Speichert der zweite Benutzer wird eine Meldung erscheinen, welche den Nutzer darauf hinweist dass soeben Änderungen vorgenommen wurden. Es besteht dabei die Möglichkeit diese Änderungen zu überschreiben.

Komponente im Page Editor gelöscht? Keine Panik!

Habt ihr versehentlich auf das rote X geklickt und die Komponente samt Inhalt auf der Seite gelöscht?
Komponente löschen

Keine Panik. Bei Betätigung des Löschen Icons verschwindet die Komponente zwar von der Bildschirmoberfläche bleibt jedoch im System bestehen. In nur drei / vier Schritten könnt ihr die Komponente inklusive Inhalt wieder zurückholen, sofern ihr diese im Vorhinein gespeichert habt. Und so geht’s:

1) Klickt auf „Komponente hinzufügen“ (das blaue „Puzzle“ Icon)  im Menü / Ribbon Bar. Wählt die gewünschte Position auf der Seite mittels Klick auf den „Hier hinzufügen“ Button.
Sitecore Komponente hinzufügen

2) Wählt das Rendering aus, welches der „verlorenen Komponente“ entspricht und bestätigt die Auswahl mit Klick auf den „Auswählen“ Button. (Achtung! Popup-Blocker muss deaktiviert sein damit das Auswahlfenster erscheint).
Rendering auswählen

3) Erscheint die Meldung „Dialog-Einstellungen bestätigen“ auf „Abbrechen“ klicken.
Meldung Dialog-Einstellungen

4) Den gewünschten Inhalt (Name der vorher für den Inhalt vergeben wurde) auswählen und fertig!
Bestehenden Inhalt auswählen

Bequem und sicher – die Inhaltspflege im Page Editor!

HTML-Seiten via Media Library bereitstellen

Meistens wird die Sitecore Media Library genutzt um Bilder und Dateien, wie PDFs, für den eigenen Webauftritt zu speichern und einzubinden, beziehungsweise zum Downloaden zu verlinken. Allerdings gehen die Möglichkeiten mit der Media Library noch viel weiter – hat man denn Bedarf daran.

In diesem Artikel wird erläutert, wie statische HTML-Seiten inklusive JavaScript und CSS über die Sitecore Media Library eingebunden und bereitgestellt werden können. Und das tolle daran: genau wie andere Items und Dateien lässt sich der Zugriff über die Sitecore Berechtigungen ganz genau festlegen – damit auch nur wirklich das von Ihnen gewünschte Zielpublikum darauf zugreifen kann!

Aus diesem Beispiel lassen sich natürlich auch weitere Use Cases ableiten, zum Beispiel wenn im Webauftritt ein Flashplayer integriert werden soll und die dazugehörigen Flashfilme (.flv Dateien) in der Media Library abgespeichert werden.

(mehr …)

Email Marketing trifft CMS

Habt ihr nicht auch schonmal gedacht wie schön es wär, nicht fünf verschiedene Tools im Online Marketing pflegen zu müssen?

Sitecore erleichtert hier euer Leben mit dem integrierten Digital Marketing System. Vor kurzem wurde jetzt auch der Email Campaign Manager (ECM) 2.0 angekündigt. Neben der kompletten Integration ins CMS bietet er unter anderem folgende Vorteile und Möglichkeiten:

  • Emails auf individuelle Benutzer personalisieren
  • Engagement Pläne einbinden
  • Klickverhalten der Benutzer verfolgen (vom Öffnen des Emails bis hin zum Kauf des Produktes)
  • Diverse Reportings von einzelnen Emails oder mehreren im Überblick einsehen
  • A/B Tests durchführen und dann die „Sieger-Mail“ an alle Empfänger senden
  • Emails vor dem Senden via Preview auf Fehler überprüfen

Und dies ist noch nicht das Ende der Funktionalitäten. In Zukunft soll gemäss Sitecore auch die Pflege der Emails in mehreren Sprachen erleichtert werden. So wird es nicht mehr nötig sein, jede in einer eigenen Nachricht pflegen zu müssen.

Was genau hinter den einzelnen Punkten des ECMs steckt, werde ich euch in den nächsten Tipps der Woche verraten.

Email Campaign Manager

Abbildung ECM 2.0

Ready to go live? Redirects nicht vergessen!?

Kurz vor GoLive…das Konzept steht, das Design ist spitze und die Umsetzung dessen perfekt. Die grosse Frage ist jedoch: Wurden auch die aktuellen URLs, die derzeit im Google Ranking glänzen, beachtet?

Denn für euer Ranking nach dem GoLive tragen auch diese ihren Anteil bei. Deshalb ist es von grosser Bedeutung die alten URLs auf die neuen URLs mit sogenannten Redirects weiterzuleiten. In unseren Projekten haben wir schon verschiedene Module für nachfolgende Redirects erfolgreich eingesetzt:

1) Redirects von bestehenden Seiten

Basierend auf der Installation des Redirect Manager Moduls, können alle bestehenden Seiten ganz einfach auf neue Sitecore Items verlinkt werden. Ist das Modul einmal installiert werden auch automatisch 301 Redirects erstellt, sobald ein Sitecore Item umbenannt oder verschoben wurde. Damit ihr den Überblick über die ganzen Weiterleitungen nicht verliert werden auf Item-Ebene alle erstellten Redirects angezeigt. Mittels Klick auf ein Link kann die Funktionalität des Redirects direkt getestet werden.

URL Redirect List on Item Level

2) Arbitrary Redirects

Mit dem von uns entwickelten Redirect Modul können z.B. auch externe URLs auf externe URLs weitergeleitet werden. Zwei Textfelder zur Eingabe der URLs ermöglichen die schnelle und einfache Pflege. Dies könnte z.B bei Landingpages mit fremder Domain von hohem Nutzen sein.

3) Redirects von Media Items

Ein weiteres Highlight des von uns programmierten Moduls ist die Weiterleitung von Links auf Meda Items wie Pdfs. So kann ganz einfach gewährleistet werden, dass auch diese im Google nicht in 404 (Fehlerseiten) enden. Hier kann mittels Redirect Modul die alte URL gepflegt und das neue Dokument komfortabel über die Sitecore Struktur ausgewählt werden.

Abbildung des Sitecore Trees für PDF Redirects

Und dies ist noch lange nicht das Ende der Möglichkeiten… Gerne entwickeln wir für Sie individuell auf Ihre Bedürfnisse angepasste Redirect Module und begleiten Sie bei der erfolgreichen Weiterleitung aller URLs.

So steht einem erfolgreichen GoLive nix mehr im Wege.

1, 2, 3 und Action … Workflows!

Wie im letzten Tipp der Woche („Inhaltsrevision mittels Workflows“) angekündigt, möchte ich euch heute die Standard Action Workflows vorstellen. Dazu zählen die Auto Submit Action, die Auto Publish Action, die Email Action und die Validation Action.

Auto Submit Action

Sobald die Auto Submit Aktion ausgelöst wird, wechselt das aktuelle Item zum nächsten Status. Die Voraussetzung dafür ist, dass der aktuelle User die vordefinierte Rolle besitzt. Welche Rolle der Benutzer haben muss und welcher Status als nächstes folgen soll kann vom Autor definiert werden (siehe Abbildung). Das Type Feld enthält die Klasse, welche die Funktionalität der Aktion bestimmt („namespace.classname, assembly_name“).

Achtung! Standardmässig kann nur eine Rolle definiert werden. Weiters sollten die Felder „Role Name“ und „Next Step“ nicht leer sein, da dies in einer Error Message enden würde.

Auto Submit Action

Auto Publish Action

Auto Publish

Diese Aktion erscheint unter dem Approved Status (siehe Abbildung oben). Die im Template zu pflegenden Daten umfassen die Klasse und die Parameter. Mittels Parameter kann bestimmt werden, ob alle hierarchisch tiefer gelegenen Items auch publiziert werden sollen oder nicht (deep = 1 => publish children; deep = 0 => don’t publish children)

Autopublish-Action

Email Action

Mit dieser Aktion kann der Versand von Emails ausgelöst werden. Das Template enthält Informationen über den Empfänger, den Sender und den Betreff des Emails. Weiters kann eine Nachricht und der SMTP Server zur Versendung der Emails gepflegt werden. Im Type Feld besteht die Möglichkeit die default Methode mit einer eigenen Methode zu überschreiben.

Email-Validation-Action

Validation Action

Diese Aktion kann verwendet werden um die Validierungsregeln auszulösen, welche auf Item Level gepflegt werden können (im Register „Validation Rules“ im Feld „Workflow Validation Rules – Runs in the Validation workflow action„).

Per Default enthält das Type Feld im Template „Sitecore.Workflows.Simple.ValidatorsAction, Sitecore.Kernel“. Max Result umfasst die unterschiedlichen Antworten des Validators – mögliche Werte sind „Unknown“, „Valid“, „Suggestion“, „Warning“, „Error“, „CriticalError“, „FatalError“. Weiters können für die unterschiedlichen Validierungsregeln Nachrichten gepflegt werden (für „Unkown„, „Warning„, „Error„, „Critical Error„, „Fatal Error„)

Validation-Action