https://wiki.sitepark.com/api.php?action=feedcontributions&feedformat=atom&user=Liebold 2026-05-25T18:52:06Z Benutzerbeiträge MediaWiki 1.35.1 https://wiki.sitepark.com/index.php?title=Infosite_6_Enterprise_Edition&diff=8474 2017-07-13T11:40:57Z

<p>Liebold: /* Systemarchitektur (vereinfacht) */</p> <hr /> <div>=Motivation=<br /> <br /> Bevor die Technik für die 'Infosite 6 Enterprise Edition' zur Verfügung stand, sind Projekte mit 'alten' Methoden aufgebaut worden. Hier sollen die alten Methoden kurz beschrieben werden um den Bedarf dieser Neukonzeption nachvollziehen zu können.<br /> <br /> Templates für den Aufbau einer Webseite werden in der Datenbank eines IES-Mandanten gespeichert.<br /> Sie werden verwenden um Eingabe-Masken für das CMS zu erzeugen und Ausgaben für die Webseite. Die durch die Ausgabe-Templates generierten Dateien enthalten in der Regel PHP-, HTML-, JavaScript- und CSS-Code, der auf die Anforderungen der Webseite angepasst ist.<br /> <br /> Bearbeitet wurden die Templates im Browser über ein Textarea-Feld im Template-Editor. Dieser Template-Editor ist Teil von Infosite.<br /> <br /> Zusätzlich zu den Templates werden bei diesem Vorgen noch JavaScripte, CSS, PHP-Klassen und ggf. Bilder benötigt die als Artikel und Medien-Artikel im Mandanten gespeichert sind.<br /> <br /> Für neuen Projekte hat Sitepark ein Master-System das als Vorlage dient. Das Master-System wird einmalig in das Kunden-System kopiert.<br /> <br /> <br /> Dieses Vorgehen hatte einige Probleme zur Folge. Diese waren z.B.<br /> <br /> ;Template-Bearbeitung im Textarea-Feld: Die Bearbeitung der Templates muss Systembedingt in einem Textarea-Feld erfolgen. Durch den Template-Editor steht zwar z.B. ein Syntax-Highlighting zur Verfügung, es fehlt aber der Funktionsumfang eines Text-Editors. Um den Funktions-Umfang eines Editors nutzen zu können, muss das Template in einen Text-Editor kopiert werden. Nach der Bearbeitung muss es wieder in das Textarea-Feld kopiert werden.<br /> <br /> ;Kollaboratives Arbeiten im Projekt: Es ist nicht möglich parallel an einem Template zu arbeiten. Besonders problematisch bei zentralen Templates wie z.b. 'PHP-Head'<br /> <br /> ;Übertragung des Entwicklungsstandes vom Aufbau- zum Live-System: Auf dem Aufbau-System werden Templates entwickelt, so wie JavaScripte und CSS erzeugt. Diese müssen in regelmäßigen Abständen auf des Live-System gespielt werden. Hier nutzen wir XIP um die notwendigen Daten zu exportieren und auf dem Live-System wieder zu importieren. Bei diesem Verfahren muss bekannt sein welche Templates und Ressourcen übertragen werden dürfen und welche noch in der Entwicklung sind. Dies zu verwalten ist sehr aufwendig und Fehler-trächtig.<br /> <br /> ;Änderungen an Templates hat oft das Generieren der gesamten Site zur Folge: Änderungen am Ausgabeteil eines Templates wirken sich erst aus, wenn die Artikel, die dieses Template verwenden neu generiert werden. Häufig ist es der Fall, dass dann die gesamte Website neu generiert werden muss. Da dies bei großen Websites mehrere Stunden in Anspruch nehmen kann, blockiert das den Entwicklungs-Prozess.<br /> <br /> ;Produkt-Features werden im Kunden-System implementiert: Da die Entwicklung immer im Kunden-System und nicht im Master-System erfolgt, werden hier auch Funktionen implementiert, die in das Master-System zurück fließen müssen. Da die Templates sich durch kundenspezifische Anpassungen von dem Templates im Master-System unterscheiden kann nicht das gesamte Template übernommen werden. Es müssen im Prinzip Zeilenweise die Code-Stellen in das Master-System übertragen werden. Bei parallel laufenden Projekten, die die Funktionalität ebenfalls nutzen möchten, müssen diese Code-Stellen auch noch in das andere Kunden-Projekt übertragen werden.<br /> <br /> ;Template-Code wird schnell unübersichtlich: Bei Templates die eine Ausgabe erzeugen, möchte man möglichst unnötige Zeilenumbrüche vermeiden, die durch die Verwendung von SP-Tags entstehen. Daher werden oft Zeilenumbrüche in Kommentare gefasst oder ganz auf Zeilenumbrüche bei SP-Tags verzichtet. Weiter ist SPML-Logik mit PHP-Logik vermischt. Dadurch können Templates schnell unübersichtlich werden.<br /> <br /> ;Templates sind nicht updatefähig: Das Master-System dient nur als Kopiervorlage für Projekte. Die Templates werden nach den kundenspezifischen Anforderungen angepasst. Dadurch sind sie nicht mehr updatefähig. Neue Funktionalitäten können nur mit Aufwand in Bestands-Systeme integriert werden, da hier auch die einzelnen Code-Stellen einzeln in die Templates übertragen werden muss.<br /> <br /> ;Keine einheitliche Basis für Module: Module wie Veranstaltungskalender, Verzeichnis-Modul, Voting-Modul, Shop-Module, ... werden für einen bestimmten Stand des Master-System entwickelt. Das Master-System entwickelt sich mit jedem Projekt weiter, ohne aber eine einheitliche Basis sicherzustellen. Dies hat zur Folge das Module auf jedes System angepasst werden müssen, und nicht einfach installierbar sind.<br /> <br /> =Sitekit-Framework=<br /> <br /> Um die oben genannte Probleme zu lösen, wurden neue Konzepte entwickelt, dessen technische Implementierung eine neue Plattform bildet, die Sitekit-Framework genannt wird.<br /> <br /> Ein grundsätzliches Problem war, das Templates über Textarea-Felder in der Datenbank gespeichert werden. Templates sollen Dateien sein. Templates eines Projektes sollen in einem kundenspezifischen Modul zusammengefasst werden. Auch JavaScript, CSS, Fonts, Bilder und PHP-Dateien liegen in diesem Modul. Diese Module werden über ein GIT-Repository versioniert. Das Modul kann mit einer IDE bearbeitet werden. Auf jedem Arbeitsplatz existiert eine IES-Installation und die Arbeit an Templates kann lokal auf dem eigenen Entwicklungs-Rechner erfolgen. <br /> <br /> Damit können folgende Probleme gelöst werden:<br /> <br /> ;Template-Bearbeitung im Textarea-Feld: wird nicht mehr benötigt. Bearbeitung erfolgt über eine IDE.<br /> ;Kollaboratives Arbeiten im Projekt: Jeder entwickelt auf seinem eigenen System und über GIT werden alle Änderungen zusammengeführt.<br /> ;Übertragung des Entwicklungsstandes vom Aufbau- zum Live-System: Die Entwicklungsarbeiten werden in einem Kunden-Modul zusammengefasst und können als eine Module-Datei (war-Datei, ZIP-Format) auf das Aufbau- und Live-System gespielt werden.<br /> <br /> <br /> Wenn es keine Templates in der Datenbank mehr gibt, dann gibt es auch keine Template-Pools mehr. Template-Pools sind aber notwendig, um Artikel-Pools zu konfigurieren, damit bestimmt werden kann, mit welchen Templates Artikel angelegt werden können. Weiter wurde über Template-Pools bestimmt, welche Abschnitte für einen bestimmten Artikel-Typ ausgewählt werden dürfen. Daher wurde hier eine Alternative geschaffen.<br /> <br /> Es gibt nun Group-Types (Artikel-Pool-Typen), Objects-Types (Artikel-Typen), Steps und Sections (Abschnitte)<br /> <br /> [[Datei:Sitekit-Types-Steps-Sections.png|Sitekit Typen, Steps und Abschnitte|center|frame|800px]]<br /> <br /> Ein Objekt-Type ist ein Seiten-Typ. Dieser kann z.B. eine Homepage, eine Rubrik-Seite, eine Inhalts-Seite oder irgend eine spezialisierte Seite sein. Je nach Object-Type existieren unterschiedliche Ein- und Ausgaben. Ein Group-Type definiert eine bestimmte Art von Artikel-Pool. Über den Group-Typ wird fest gelegt, welche Objekt-Typen in Artikel-Pools eines bestimmen Group-Typs angelegt werden können. Die Bearbeitung eines Artikels ist in einzelne Schritte (Steps) unterteilt. In jedem Step gibt es verschiedene Abschnitte, in der die Teile der Eingabe-Masken strukturiert sind. Objekt-Typen definieren welche Steps verwendet werden. Steps definieren welche Abschnitte verwendet werden.<br /> <br /> <br /> Ein weiteres, grundsätzliches Problem ist die Vermischung von Daten, Logik und Darstellung. Die PHP-Seiten, die mit bisherigen Templates generiert wurden, enthielten Daten, Logik und HTML-Code an den Stellen, wo sie gerade benötigt wurden. Alles sehr vermischt in einer PHP-Datei.<br /> <br /> ;Daten (Raw-Content):<br /> Templates des Sitekit-Frameworks generieren nur noch die Daten in die PHP-Datei. Daher bezeichnen wir die Ausgabe-Templates des Sitekit-Frameworks als Aggregatoren. Zur Generierungszeit werden über die Aggregatoren die Daten so aufbereitet und angereichert, dass sie für die Darstellung gut geeignet sind. Diese Aufbereitung erfolg Ausgabe-Neutral, so dass aus den Daten nicht nur HTML, sondern auch andere Formate wie XML oder JSON erzeugt werden können. Mit diesem Ansatz wird aus Infosite ein Headless CMS. Durch dieses Vorgehen profitiert z.B auch die Suche. Bisher konnten in einem Suchergebnis nur die Daten dargestellt werden die im Suchindex enthalten waren. Jetzt ist es möglich ggf. die gesamten Daten eines Artikels für die Darstellung eines Suchergebnisses nachzuladen.<br /> <br /> ;Logik:<br /> Die Logik wird in Komponenten abgelegt. Komponenten sind Teilbereiche einer Webseite. Die gesamte Webseite wird in einzelne Komponenten zerlegt, die auch ineinander verschachtelt sein können. Viele Komponenten habe keine Logik, dann dienen sie nur als Platzhalter für die Darstellung. Komponenten wie z.B. die Suche enthalten aber auch Logik. Das Sitekit-Frameworks sorgt dafür das zunächst die Logik der Komponenten ausgeführt wird. Ist die gesamte Logik ausgeführt, kann die Webseite dargestellt werden.<br /> <br /> ;Ausgabe:<br /> Für jede Komponente existiert ein Renderer. Dieser erzeugt das HTML (oder ein anderes Ausgabeformat) für die Komponenten.<br /> <br /> ;Styling<br /> Auf Basis des HTML, das die Renderer erzeugen können Styles definiert werden um die gewünschte Darstellung zu erreichen. <br /> <br /> So sind Daten, Logik und Darstellung in Aggregatoren, Komponenten und Renderer aufgeteilt.<br /> <br /> <br /> Auf Basis dieser Technik werden von Sitepark Komponenten entwickelt, die in den Kunden-Projekten eingesetzt werden können. Ziel ist es die Komponenten konfigurativ so anpassen zu können das sie den individuellen Anforderungen der Projekte genügen. Sollte das nicht ausreichen, können kundenspezifische Komponenten erzeugt werden.<br /> <br /> <br /> Mit den oben beschriebenen Mitteln sollen folgende Probleme gelöst werden.<br /> <br /> ;Änderungen an Templates hat oft das Generieren der gesamten Site zur Folge: Die Seiten müssen nur noch generiert werden, wenn sich die Aggregatoren ändern. Bei Änderungen an der Logik oder an der Darstellung ist kein neu-generieren mehr notwendig.<br /> <br /> ;Produkt-Features werden im Kunden-System implementiert: Es gibt keinen Master-System mehr. Produkterweiterungen, die sich aus dem Projekt ergeben werden während des Projektes in das Produkt-Modul integriert und auch direkt verwendet.<br /> <br /> ;Template-Code wird schnell unübersichtlich: Auf Zeilenumbrüche muss keine Rücksicht mehr genommen werden, da Aggregatoren nur Maps und Collections füllen und keine Ausgabe erzeugen. Durch die Trennung von Daten, Logik und Ausgabe sind auch die verschiedenen Technologien SMPL, PHP, JavaScript und CSS getrennt und nicht mehr in einer Datei enthalten. <br /> <br /> ;Templates sind nicht updatefähig: Produkt- und Kunden-Anpassungen werden strickt getrennt. Produkte werden abwärts-kompatibel gehalten und sind damit updatefähig.<br /> <br /> ;Keine einheitliche Basis für Module: Das Sitekit-Framework liefert eine stabile Basis für Module.<br /> <br /> ==Enthaltene Funktionen und Komponenten==<br /> Im Sitekit-Framework enthalten sind Funktionen und Komponenten die Sitepark als &quot;Standard&quot; definiert hat, da sie in den meisten Projekten Verwendung finden.<br /> <br /> Alle von Sitekit-Framework bereit gestellten Komponenten sind barrierefrei und verhalten sich responsive.<br /> <br /> ===Generelle Funktionen===<br /> <br /> ;Navigation: Komplettes Navigations-Konzept mit verschiedenen Features wie Vererbbarkeit von Eigenschaften durch die Navigations-Struktur (z.B. Rubrik-Farbe), Mehrfachverknüpfung von Artikeln in der Navigation, geeignet für große Sites (100.000 Seiten und mehr), beliebige Navigations-Tiefe, JavaScript-basierte Mobile-fähige Navigation mit Offline-Caching.<br /> <br /> ;Suche: Voll integrierte Volltext Suche auf Basis von Solr mit Suggest, erweiterten Suchoptionen, Facettierung, unterstützt geschützte Seiten, bietet Ad-Hoc-Indizierung getriggert durch das Speichern eines Artikels, liefert Werkzeuge zur Analyse des Volltext-Index z.B. zum debuggen.<br /> <br /> ;Fehlerseiten: Redaktionell pflegbare Fehlerseiten für HTTP-Fehler (404 - Datei oder Verzeichnis nicht gefunden, ...)<br /> <br /> ;Favicons: Verwaltung der Favicons<br /> <br /> ;Geolocation: Definition von GEO-Koordinaten an Artikel. Volle Integration in die Suche für z.B. Umkreissuchen.<br /> <br /> ;Kategorisierung: Kategorie-System zur Kategorisierung von Artikeln mit voller Integration in die Suche für z.B. Facetierung.<br /> <br /> ;Teaser: Teaser-System zur Verwendung von Teasern in verschiedenen Kontexten wie: Navigation, Teaser-Listen, Slider, Karten-Marker-Info-Boxen, Suchergebnisse, Kachelsystem, Zeitsteuerung.<br /> <br /> ;Kurzadressen: Definition von Kurz-Urls<br /> <br /> ;Microsites: Microsite-System zur Erstellung von untergeordneten Sites unter eigener Domain mit geteiltem, aber Theming-fähigem Design.<br /> <br /> ;Mehrsprachigkeit (Website): Alle nicht-redaktionellen Inhalte, die auf der Webseite dargestellt werden, können über Sprachpakete in andere Sprachen übersetzt werden. Für die deutsche Sprache wird ein Sprachpaket mitgeliefert das auch nach Kundenwunsch angepasst werden kann.<br /> <br /> =Whitelabel=<br /> <br /> Damit neue Projekte nicht von Null begonnen werden müssen, wurden das Whitelabel-Modul erstellt. In diesem Modul sind immer die aktuellen Techniken zur Umsetzung von neuen Projekten enthalten. Dieses Modul dient als Kopiervorlage. Es wird immer auf die aktuellen Anforderungen von neuen Projekten angepasst. Hier wird keine Rücksicht auf Updatefähigkeit genommen.<br /> <br /> Das Sitekit-Framework soll die Technik enthalten, die Projekt-übergreifend verwendet wird. Sitepark sorgt dafür, dass das Sitekit-Framework updatefähig ist und somit als langfristige Plattform für Projekt- und Produkt-Module verwendet werden kann.<br /> <br /> Besonders im Front-End-Bereich (CSS, JavaScript) werden etablierte Techniken schneller von neueren Techniken überholt. In diesem Bereich wäre eine langfristige updatefähigkeit eine große Innovations-Bremse. Daher ist ein großer Teil der Front-End-Technik nicht im Sitekit-Framework, sondern im Whitelabel-Modul enthalten.<br /> <br /> Das Whitelabel-Modul besteht aus zwei Unter-Modulen<br /> <br /> ;IES-Modul:<br /> Das IES Modul enthält Eingabe-Templates, Aggregatoren, Komponenten, Renderer und Basis-Konfigurationen<br /> ;Styleguide:<br /> In diesem Modul ist ein Styleguide enthalten in dem das HTML hinterlegt ist, dass auch die Renderer erzeugen. Alle Komponenten sind nach dem Atomic-Design-Prinzip in Atome, Moleküle, Organismen und Templates erlegt und können so gestylt werden.<br /> <br /> =Kundenmodul=<br /> <br /> Ein Kundenmodul wird als Kopie von Whitelabel erzeugt. In diesem Modul werden alle kundenspezifischen Anforderungen implementiert.<br /> <br /> =Systemarchitektur (vereinfacht)=<br /> <br /> Das Sitekit-Framework und Infosite 6 zusammen bilden die &quot;Infosite 6 Enterprise Edition&quot; (Infosite 6 EE)<br /> <br /> <br /> [[Datei:InfoSite6-EE-Systemarchitektur-vereinfacht.png|800px]]<br /> <br /> Die '''CMS-Oberfläche''' stellt die Eingabemasken dar, die sich aus einzelnen Abschnitten zusammensetzen. Das Sitekit-Framework stellt diese Abschnitte bereit. Das Kunden-Modul enthält kundenspezifische Konfigurationen der Sitekit-Abschnitte und kundenspezifische Abschnitte.<br /> <br /> Das '''IES Repository''' hält die Artikel-Daten, die über die CMS-Oberfläche dargestellt und bearbeitet werden können.<br /> <br /> Der '''Raw Content''' wird pro Artikel als PHP-Datei vom CMS auf dem Webserver publiziert. Die Daten werden über Sitekit- und kundenspezifische-Aggregatoren aus dem IES Repository geladen und in einer für die Darstellung optimierten Form zusammengestellt.<br /> <br /> Die '''Renderer''' erzeugen beim Aufruf einer Seite aus dem Raw Content das gewünschte Ausgabeformat. Das Sitekit-Framework stellt Renderer zur Verfügung die kundenspezifisch angepasst werden können. Kunden-Module stellen auch eigene Renderer bereit.<br /> <br /> Mit Hilfe eines Styleguide werden für das Styling der Webseite '''CSS''' und '''JavaScript''' implementiert.</div>

Liebold https://wiki.sitepark.com/index.php?title=Infosite_6_Enterprise_Edition&diff=8473 2017-07-13T11:36:38Z

<p>Liebold: /* Systemarchitektur (vereinfacht) */</p> <hr /> <div>=Motivation=<br /> <br /> Bevor die Technik für die 'Infosite 6 Enterprise Edition' zur Verfügung stand, sind Projekte mit 'alten' Methoden aufgebaut worden. Hier sollen die alten Methoden kurz beschrieben werden um den Bedarf dieser Neukonzeption nachvollziehen zu können.<br /> <br /> Templates für den Aufbau einer Webseite werden in der Datenbank eines IES-Mandanten gespeichert.<br /> Sie werden verwenden um Eingabe-Masken für das CMS zu erzeugen und Ausgaben für die Webseite. Die durch die Ausgabe-Templates generierten Dateien enthalten in der Regel PHP-, HTML-, JavaScript- und CSS-Code, der auf die Anforderungen der Webseite angepasst ist.<br /> <br /> Bearbeitet wurden die Templates im Browser über ein Textarea-Feld im Template-Editor. Dieser Template-Editor ist Teil von Infosite.<br /> <br /> Zusätzlich zu den Templates werden bei diesem Vorgen noch JavaScripte, CSS, PHP-Klassen und ggf. Bilder benötigt die als Artikel und Medien-Artikel im Mandanten gespeichert sind.<br /> <br /> Für neuen Projekte hat Sitepark ein Master-System das als Vorlage dient. Das Master-System wird einmalig in das Kunden-System kopiert.<br /> <br /> <br /> Dieses Vorgehen hatte einige Probleme zur Folge. Diese waren z.B.<br /> <br /> ;Template-Bearbeitung im Textarea-Feld: Die Bearbeitung der Templates muss Systembedingt in einem Textarea-Feld erfolgen. Durch den Template-Editor steht zwar z.B. ein Syntax-Highlighting zur Verfügung, es fehlt aber der Funktionsumfang eines Text-Editors. Um den Funktions-Umfang eines Editors nutzen zu können, muss das Template in einen Text-Editor kopiert werden. Nach der Bearbeitung muss es wieder in das Textarea-Feld kopiert werden.<br /> <br /> ;Kollaboratives Arbeiten im Projekt: Es ist nicht möglich parallel an einem Template zu arbeiten. Besonders problematisch bei zentralen Templates wie z.b. 'PHP-Head'<br /> <br /> ;Übertragung des Entwicklungsstandes vom Aufbau- zum Live-System: Auf dem Aufbau-System werden Templates entwickelt, so wie JavaScripte und CSS erzeugt. Diese müssen in regelmäßigen Abständen auf des Live-System gespielt werden. Hier nutzen wir XIP um die notwendigen Daten zu exportieren und auf dem Live-System wieder zu importieren. Bei diesem Verfahren muss bekannt sein welche Templates und Ressourcen übertragen werden dürfen und welche noch in der Entwicklung sind. Dies zu verwalten ist sehr aufwendig und Fehler-trächtig.<br /> <br /> ;Änderungen an Templates hat oft das Generieren der gesamten Site zur Folge: Änderungen am Ausgabeteil eines Templates wirken sich erst aus, wenn die Artikel, die dieses Template verwenden neu generiert werden. Häufig ist es der Fall, dass dann die gesamte Website neu generiert werden muss. Da dies bei großen Websites mehrere Stunden in Anspruch nehmen kann, blockiert das den Entwicklungs-Prozess.<br /> <br /> ;Produkt-Features werden im Kunden-System implementiert: Da die Entwicklung immer im Kunden-System und nicht im Master-System erfolgt, werden hier auch Funktionen implementiert, die in das Master-System zurück fließen müssen. Da die Templates sich durch kundenspezifische Anpassungen von dem Templates im Master-System unterscheiden kann nicht das gesamte Template übernommen werden. Es müssen im Prinzip Zeilenweise die Code-Stellen in das Master-System übertragen werden. Bei parallel laufenden Projekten, die die Funktionalität ebenfalls nutzen möchten, müssen diese Code-Stellen auch noch in das andere Kunden-Projekt übertragen werden.<br /> <br /> ;Template-Code wird schnell unübersichtlich: Bei Templates die eine Ausgabe erzeugen, möchte man möglichst unnötige Zeilenumbrüche vermeiden, die durch die Verwendung von SP-Tags entstehen. Daher werden oft Zeilenumbrüche in Kommentare gefasst oder ganz auf Zeilenumbrüche bei SP-Tags verzichtet. Weiter ist SPML-Logik mit PHP-Logik vermischt. Dadurch können Templates schnell unübersichtlich werden.<br /> <br /> ;Templates sind nicht updatefähig: Das Master-System dient nur als Kopiervorlage für Projekte. Die Templates werden nach den kundenspezifischen Anforderungen angepasst. Dadurch sind sie nicht mehr updatefähig. Neue Funktionalitäten können nur mit Aufwand in Bestands-Systeme integriert werden, da hier auch die einzelnen Code-Stellen einzeln in die Templates übertragen werden muss.<br /> <br /> ;Keine einheitliche Basis für Module: Module wie Veranstaltungskalender, Verzeichnis-Modul, Voting-Modul, Shop-Module, ... werden für einen bestimmten Stand des Master-System entwickelt. Das Master-System entwickelt sich mit jedem Projekt weiter, ohne aber eine einheitliche Basis sicherzustellen. Dies hat zur Folge das Module auf jedes System angepasst werden müssen, und nicht einfach installierbar sind.<br /> <br /> =Sitekit-Framework=<br /> <br /> Um die oben genannte Probleme zu lösen, wurden neue Konzepte entwickelt, dessen technische Implementierung eine neue Plattform bildet, die Sitekit-Framework genannt wird.<br /> <br /> Ein grundsätzliches Problem war, das Templates über Textarea-Felder in der Datenbank gespeichert werden. Templates sollen Dateien sein. Templates eines Projektes sollen in einem kundenspezifischen Modul zusammengefasst werden. Auch JavaScript, CSS, Fonts, Bilder und PHP-Dateien liegen in diesem Modul. Diese Module werden über ein GIT-Repository versioniert. Das Modul kann mit einer IDE bearbeitet werden. Auf jedem Arbeitsplatz existiert eine IES-Installation und die Arbeit an Templates kann lokal auf dem eigenen Entwicklungs-Rechner erfolgen. <br /> <br /> Damit können folgende Probleme gelöst werden:<br /> <br /> ;Template-Bearbeitung im Textarea-Feld: wird nicht mehr benötigt. Bearbeitung erfolgt über eine IDE.<br /> ;Kollaboratives Arbeiten im Projekt: Jeder entwickelt auf seinem eigenen System und über GIT werden alle Änderungen zusammengeführt.<br /> ;Übertragung des Entwicklungsstandes vom Aufbau- zum Live-System: Die Entwicklungsarbeiten werden in einem Kunden-Modul zusammengefasst und können als eine Module-Datei (war-Datei, ZIP-Format) auf das Aufbau- und Live-System gespielt werden.<br /> <br /> <br /> Wenn es keine Templates in der Datenbank mehr gibt, dann gibt es auch keine Template-Pools mehr. Template-Pools sind aber notwendig, um Artikel-Pools zu konfigurieren, damit bestimmt werden kann, mit welchen Templates Artikel angelegt werden können. Weiter wurde über Template-Pools bestimmt, welche Abschnitte für einen bestimmten Artikel-Typ ausgewählt werden dürfen. Daher wurde hier eine Alternative geschaffen.<br /> <br /> Es gibt nun Group-Types (Artikel-Pool-Typen), Objects-Types (Artikel-Typen), Steps und Sections (Abschnitte)<br /> <br /> [[Datei:Sitekit-Types-Steps-Sections.png|Sitekit Typen, Steps und Abschnitte|center|frame|800px]]<br /> <br /> Ein Objekt-Type ist ein Seiten-Typ. Dieser kann z.B. eine Homepage, eine Rubrik-Seite, eine Inhalts-Seite oder irgend eine spezialisierte Seite sein. Je nach Object-Type existieren unterschiedliche Ein- und Ausgaben. Ein Group-Type definiert eine bestimmte Art von Artikel-Pool. Über den Group-Typ wird fest gelegt, welche Objekt-Typen in Artikel-Pools eines bestimmen Group-Typs angelegt werden können. Die Bearbeitung eines Artikels ist in einzelne Schritte (Steps) unterteilt. In jedem Step gibt es verschiedene Abschnitte, in der die Teile der Eingabe-Masken strukturiert sind. Objekt-Typen definieren welche Steps verwendet werden. Steps definieren welche Abschnitte verwendet werden.<br /> <br /> <br /> Ein weiteres, grundsätzliches Problem ist die Vermischung von Daten, Logik und Darstellung. Die PHP-Seiten, die mit bisherigen Templates generiert wurden, enthielten Daten, Logik und HTML-Code an den Stellen, wo sie gerade benötigt wurden. Alles sehr vermischt in einer PHP-Datei.<br /> <br /> ;Daten (Raw-Content):<br /> Templates des Sitekit-Frameworks generieren nur noch die Daten in die PHP-Datei. Daher bezeichnen wir die Ausgabe-Templates des Sitekit-Frameworks als Aggregatoren. Zur Generierungszeit werden über die Aggregatoren die Daten so aufbereitet und angereichert, dass sie für die Darstellung gut geeignet sind. Diese Aufbereitung erfolg Ausgabe-Neutral, so dass aus den Daten nicht nur HTML, sondern auch andere Formate wie XML oder JSON erzeugt werden können. Mit diesem Ansatz wird aus Infosite ein Headless CMS. Durch dieses Vorgehen profitiert z.B auch die Suche. Bisher konnten in einem Suchergebnis nur die Daten dargestellt werden die im Suchindex enthalten waren. Jetzt ist es möglich ggf. die gesamten Daten eines Artikels für die Darstellung eines Suchergebnisses nachzuladen.<br /> <br /> ;Logik:<br /> Die Logik wird in Komponenten abgelegt. Komponenten sind Teilbereiche einer Webseite. Die gesamte Webseite wird in einzelne Komponenten zerlegt, die auch ineinander verschachtelt sein können. Viele Komponenten habe keine Logik, dann dienen sie nur als Platzhalter für die Darstellung. Komponenten wie z.B. die Suche enthalten aber auch Logik. Das Sitekit-Frameworks sorgt dafür das zunächst die Logik der Komponenten ausgeführt wird. Ist die gesamte Logik ausgeführt, kann die Webseite dargestellt werden.<br /> <br /> ;Ausgabe:<br /> Für jede Komponente existiert ein Renderer. Dieser erzeugt das HTML (oder ein anderes Ausgabeformat) für die Komponenten.<br /> <br /> ;Styling<br /> Auf Basis des HTML, das die Renderer erzeugen können Styles definiert werden um die gewünschte Darstellung zu erreichen. <br /> <br /> So sind Daten, Logik und Darstellung in Aggregatoren, Komponenten und Renderer aufgeteilt.<br /> <br /> <br /> Auf Basis dieser Technik werden von Sitepark Komponenten entwickelt, die in den Kunden-Projekten eingesetzt werden können. Ziel ist es die Komponenten konfigurativ so anpassen zu können das sie den individuellen Anforderungen der Projekte genügen. Sollte das nicht ausreichen, können kundenspezifische Komponenten erzeugt werden.<br /> <br /> <br /> Mit den oben beschriebenen Mitteln sollen folgende Probleme gelöst werden.<br /> <br /> ;Änderungen an Templates hat oft das Generieren der gesamten Site zur Folge: Die Seiten müssen nur noch generiert werden, wenn sich die Aggregatoren ändern. Bei Änderungen an der Logik oder an der Darstellung ist kein neu-generieren mehr notwendig.<br /> <br /> ;Produkt-Features werden im Kunden-System implementiert: Es gibt keinen Master-System mehr. Produkterweiterungen, die sich aus dem Projekt ergeben werden während des Projektes in das Produkt-Modul integriert und auch direkt verwendet.<br /> <br /> ;Template-Code wird schnell unübersichtlich: Auf Zeilenumbrüche muss keine Rücksicht mehr genommen werden, da Aggregatoren nur Maps und Collections füllen und keine Ausgabe erzeugen. Durch die Trennung von Daten, Logik und Ausgabe sind auch die verschiedenen Technologien SMPL, PHP, JavaScript und CSS getrennt und nicht mehr in einer Datei enthalten. <br /> <br /> ;Templates sind nicht updatefähig: Produkt- und Kunden-Anpassungen werden strickt getrennt. Produkte werden abwärts-kompatibel gehalten und sind damit updatefähig.<br /> <br /> ;Keine einheitliche Basis für Module: Das Sitekit-Framework liefert eine stabile Basis für Module.<br /> <br /> ==Enthaltene Funktionen und Komponenten==<br /> Im Sitekit-Framework enthalten sind Funktionen und Komponenten die Sitepark als &quot;Standard&quot; definiert hat, da sie in den meisten Projekten Verwendung finden.<br /> <br /> Alle von Sitekit-Framework bereit gestellten Komponenten sind barrierefrei und verhalten sich responsive.<br /> <br /> ===Generelle Funktionen===<br /> <br /> ;Navigation: Komplettes Navigations-Konzept mit verschiedenen Features wie Vererbbarkeit von Eigenschaften durch die Navigations-Struktur (z.B. Rubrik-Farbe), Mehrfachverknüpfung von Artikeln in der Navigation, geeignet für große Sites (100.000 Seiten und mehr), beliebige Navigations-Tiefe, JavaScript-basierte Mobile-fähige Navigation mit Offline-Caching.<br /> <br /> ;Suche: Voll integrierte Volltext Suche auf Basis von Solr mit Suggest, erweiterten Suchoptionen, Facettierung, unterstützt geschützte Seiten, bietet Ad-Hoc-Indizierung getriggert durch das Speichern eines Artikels, liefert Werkzeuge zur Analyse des Volltext-Index z.B. zum debuggen.<br /> <br /> ;Fehlerseiten: Redaktionell pflegbare Fehlerseiten für HTTP-Fehler (404 - Datei oder Verzeichnis nicht gefunden, ...)<br /> <br /> ;Favicons: Verwaltung der Favicons<br /> <br /> ;Geolocation: Definition von GEO-Koordinaten an Artikel. Volle Integration in die Suche für z.B. Umkreissuchen.<br /> <br /> ;Kategorisierung: Kategorie-System zur Kategorisierung von Artikeln mit voller Integration in die Suche für z.B. Facetierung.<br /> <br /> ;Teaser: Teaser-System zur Verwendung von Teasern in verschiedenen Kontexten wie: Navigation, Teaser-Listen, Slider, Karten-Marker-Info-Boxen, Suchergebnisse, Kachelsystem, Zeitsteuerung.<br /> <br /> ;Kurzadressen: Definition von Kurz-Urls<br /> <br /> ;Microsites: Microsite-System zur Erstellung von untergeordneten Sites unter eigener Domain mit geteiltem, aber Theming-fähigem Design.<br /> <br /> ;Mehrsprachigkeit (Website): Alle nicht-redaktionellen Inhalte, die auf der Webseite dargestellt werden, können über Sprachpakete in andere Sprachen übersetzt werden. Für die deutsche Sprache wird ein Sprachpaket mitgeliefert das auch nach Kundenwunsch angepasst werden kann.<br /> <br /> =Whitelabel=<br /> <br /> Damit neue Projekte nicht von Null begonnen werden müssen, wurden das Whitelabel-Modul erstellt. In diesem Modul sind immer die aktuellen Techniken zur Umsetzung von neuen Projekten enthalten. Dieses Modul dient als Kopiervorlage. Es wird immer auf die aktuellen Anforderungen von neuen Projekten angepasst. Hier wird keine Rücksicht auf Updatefähigkeit genommen.<br /> <br /> Das Sitekit-Framework soll die Technik enthalten, die Projekt-übergreifend verwendet wird. Sitepark sorgt dafür, dass das Sitekit-Framework updatefähig ist und somit als langfristige Plattform für Projekt- und Produkt-Module verwendet werden kann.<br /> <br /> Besonders im Front-End-Bereich (CSS, JavaScript) werden etablierte Techniken schneller von neueren Techniken überholt. In diesem Bereich wäre eine langfristige updatefähigkeit eine große Innovations-Bremse. Daher ist ein großer Teil der Front-End-Technik nicht im Sitekit-Framework, sondern im Whitelabel-Modul enthalten.<br /> <br /> Das Whitelabel-Modul besteht aus zwei Unter-Modulen<br /> <br /> ;IES-Modul:<br /> Das IES Modul enthält Eingabe-Templates, Aggregatoren, Komponenten, Renderer und Basis-Konfigurationen<br /> ;Styleguide:<br /> In diesem Modul ist ein Styleguide enthalten in dem das HTML hinterlegt ist, dass auch die Renderer erzeugen. Alle Komponenten sind nach dem Atomic-Design-Prinzip in Atome, Moleküle, Organismen und Templates erlegt und können so gestylt werden.<br /> <br /> =Kundenmodul=<br /> <br /> Ein Kundenmodul wird als Kopie von Whitelabel erzeugt. In diesem Modul werden alle kundenspezifischen Anforderungen implementiert.<br /> <br /> =Systemarchitektur (vereinfacht)=<br /> <br /> Das Sitekit-Framework und Infosite 6 zusammen bilden die &quot;Infosite 6 Enterprise Edition&quot; (Infosite 6 EE)<br /> <br /> <br /> [[Datei:InfoSite6-EE-Systemarchitektur-vereinfacht.png|800px]]<br /> <br /> Die '''CMS-Oberfläche''' stellt die Eingabemasken dar, die sich aus einzelnen Abschnitten zusammensetzen. Das Sitekit-Framework stellt diese Abschnitte bereit. Das Kunden-Modul enthält kundenspezifische Konfigurationen der Sitekit-Abschnitte und kundenspezifische Abschnitte.<br /> <br /> Das '''IES Repository''' hält die Artikel-Daten, die über die CMS-Oberfläche dargestellt und bearbeitet werden können.<br /> <br /> Der '''Raw Content''' wird pro Artikel als PHP-Datei vom CMS auf dem Webserver publiziert. Die Daten werden über Sitekit- und Kundenspezifischen-Aggregatoren aus dem IES Repository geladen und in einer für die Darstellung optimierten Form zusammengestellt.<br /> <br /> Die '''Renderer''' erzeugen beim Aufruf einer Seite aus dem Raw Content das gewünschte Ausgabeformat. Das SiteKit stellt Renderer zur Verfügung die kundenspezifisch angepasst werden können. Kunden-Module stellen auch eigene Renderer bereit.<br /> <br /> Mit Hilfe eines Styleguide werden für das Styling der Webseite '''CSS''' und '''JavaScript''' implementiert.</div>

Liebold https://wiki.sitepark.com/index.php?title=Infosite_6_Enterprise_Edition&diff=8472 2017-07-13T11:35:22Z

<p>Liebold: /* Kundenmodul */</p> <hr /> <div>=Motivation=<br /> <br /> Bevor die Technik für die 'Infosite 6 Enterprise Edition' zur Verfügung stand, sind Projekte mit 'alten' Methoden aufgebaut worden. Hier sollen die alten Methoden kurz beschrieben werden um den Bedarf dieser Neukonzeption nachvollziehen zu können.<br /> <br /> Templates für den Aufbau einer Webseite werden in der Datenbank eines IES-Mandanten gespeichert.<br /> Sie werden verwenden um Eingabe-Masken für das CMS zu erzeugen und Ausgaben für die Webseite. Die durch die Ausgabe-Templates generierten Dateien enthalten in der Regel PHP-, HTML-, JavaScript- und CSS-Code, der auf die Anforderungen der Webseite angepasst ist.<br /> <br /> Bearbeitet wurden die Templates im Browser über ein Textarea-Feld im Template-Editor. Dieser Template-Editor ist Teil von Infosite.<br /> <br /> Zusätzlich zu den Templates werden bei diesem Vorgen noch JavaScripte, CSS, PHP-Klassen und ggf. Bilder benötigt die als Artikel und Medien-Artikel im Mandanten gespeichert sind.<br /> <br /> Für neuen Projekte hat Sitepark ein Master-System das als Vorlage dient. Das Master-System wird einmalig in das Kunden-System kopiert.<br /> <br /> <br /> Dieses Vorgehen hatte einige Probleme zur Folge. Diese waren z.B.<br /> <br /> ;Template-Bearbeitung im Textarea-Feld: Die Bearbeitung der Templates muss Systembedingt in einem Textarea-Feld erfolgen. Durch den Template-Editor steht zwar z.B. ein Syntax-Highlighting zur Verfügung, es fehlt aber der Funktionsumfang eines Text-Editors. Um den Funktions-Umfang eines Editors nutzen zu können, muss das Template in einen Text-Editor kopiert werden. Nach der Bearbeitung muss es wieder in das Textarea-Feld kopiert werden.<br /> <br /> ;Kollaboratives Arbeiten im Projekt: Es ist nicht möglich parallel an einem Template zu arbeiten. Besonders problematisch bei zentralen Templates wie z.b. 'PHP-Head'<br /> <br /> ;Übertragung des Entwicklungsstandes vom Aufbau- zum Live-System: Auf dem Aufbau-System werden Templates entwickelt, so wie JavaScripte und CSS erzeugt. Diese müssen in regelmäßigen Abständen auf des Live-System gespielt werden. Hier nutzen wir XIP um die notwendigen Daten zu exportieren und auf dem Live-System wieder zu importieren. Bei diesem Verfahren muss bekannt sein welche Templates und Ressourcen übertragen werden dürfen und welche noch in der Entwicklung sind. Dies zu verwalten ist sehr aufwendig und Fehler-trächtig.<br /> <br /> ;Änderungen an Templates hat oft das Generieren der gesamten Site zur Folge: Änderungen am Ausgabeteil eines Templates wirken sich erst aus, wenn die Artikel, die dieses Template verwenden neu generiert werden. Häufig ist es der Fall, dass dann die gesamte Website neu generiert werden muss. Da dies bei großen Websites mehrere Stunden in Anspruch nehmen kann, blockiert das den Entwicklungs-Prozess.<br /> <br /> ;Produkt-Features werden im Kunden-System implementiert: Da die Entwicklung immer im Kunden-System und nicht im Master-System erfolgt, werden hier auch Funktionen implementiert, die in das Master-System zurück fließen müssen. Da die Templates sich durch kundenspezifische Anpassungen von dem Templates im Master-System unterscheiden kann nicht das gesamte Template übernommen werden. Es müssen im Prinzip Zeilenweise die Code-Stellen in das Master-System übertragen werden. Bei parallel laufenden Projekten, die die Funktionalität ebenfalls nutzen möchten, müssen diese Code-Stellen auch noch in das andere Kunden-Projekt übertragen werden.<br /> <br /> ;Template-Code wird schnell unübersichtlich: Bei Templates die eine Ausgabe erzeugen, möchte man möglichst unnötige Zeilenumbrüche vermeiden, die durch die Verwendung von SP-Tags entstehen. Daher werden oft Zeilenumbrüche in Kommentare gefasst oder ganz auf Zeilenumbrüche bei SP-Tags verzichtet. Weiter ist SPML-Logik mit PHP-Logik vermischt. Dadurch können Templates schnell unübersichtlich werden.<br /> <br /> ;Templates sind nicht updatefähig: Das Master-System dient nur als Kopiervorlage für Projekte. Die Templates werden nach den kundenspezifischen Anforderungen angepasst. Dadurch sind sie nicht mehr updatefähig. Neue Funktionalitäten können nur mit Aufwand in Bestands-Systeme integriert werden, da hier auch die einzelnen Code-Stellen einzeln in die Templates übertragen werden muss.<br /> <br /> ;Keine einheitliche Basis für Module: Module wie Veranstaltungskalender, Verzeichnis-Modul, Voting-Modul, Shop-Module, ... werden für einen bestimmten Stand des Master-System entwickelt. Das Master-System entwickelt sich mit jedem Projekt weiter, ohne aber eine einheitliche Basis sicherzustellen. Dies hat zur Folge das Module auf jedes System angepasst werden müssen, und nicht einfach installierbar sind.<br /> <br /> =Sitekit-Framework=<br /> <br /> Um die oben genannte Probleme zu lösen, wurden neue Konzepte entwickelt, dessen technische Implementierung eine neue Plattform bildet, die Sitekit-Framework genannt wird.<br /> <br /> Ein grundsätzliches Problem war, das Templates über Textarea-Felder in der Datenbank gespeichert werden. Templates sollen Dateien sein. Templates eines Projektes sollen in einem kundenspezifischen Modul zusammengefasst werden. Auch JavaScript, CSS, Fonts, Bilder und PHP-Dateien liegen in diesem Modul. Diese Module werden über ein GIT-Repository versioniert. Das Modul kann mit einer IDE bearbeitet werden. Auf jedem Arbeitsplatz existiert eine IES-Installation und die Arbeit an Templates kann lokal auf dem eigenen Entwicklungs-Rechner erfolgen. <br /> <br /> Damit können folgende Probleme gelöst werden:<br /> <br /> ;Template-Bearbeitung im Textarea-Feld: wird nicht mehr benötigt. Bearbeitung erfolgt über eine IDE.<br /> ;Kollaboratives Arbeiten im Projekt: Jeder entwickelt auf seinem eigenen System und über GIT werden alle Änderungen zusammengeführt.<br /> ;Übertragung des Entwicklungsstandes vom Aufbau- zum Live-System: Die Entwicklungsarbeiten werden in einem Kunden-Modul zusammengefasst und können als eine Module-Datei (war-Datei, ZIP-Format) auf das Aufbau- und Live-System gespielt werden.<br /> <br /> <br /> Wenn es keine Templates in der Datenbank mehr gibt, dann gibt es auch keine Template-Pools mehr. Template-Pools sind aber notwendig, um Artikel-Pools zu konfigurieren, damit bestimmt werden kann, mit welchen Templates Artikel angelegt werden können. Weiter wurde über Template-Pools bestimmt, welche Abschnitte für einen bestimmten Artikel-Typ ausgewählt werden dürfen. Daher wurde hier eine Alternative geschaffen.<br /> <br /> Es gibt nun Group-Types (Artikel-Pool-Typen), Objects-Types (Artikel-Typen), Steps und Sections (Abschnitte)<br /> <br /> [[Datei:Sitekit-Types-Steps-Sections.png|Sitekit Typen, Steps und Abschnitte|center|frame|800px]]<br /> <br /> Ein Objekt-Type ist ein Seiten-Typ. Dieser kann z.B. eine Homepage, eine Rubrik-Seite, eine Inhalts-Seite oder irgend eine spezialisierte Seite sein. Je nach Object-Type existieren unterschiedliche Ein- und Ausgaben. Ein Group-Type definiert eine bestimmte Art von Artikel-Pool. Über den Group-Typ wird fest gelegt, welche Objekt-Typen in Artikel-Pools eines bestimmen Group-Typs angelegt werden können. Die Bearbeitung eines Artikels ist in einzelne Schritte (Steps) unterteilt. In jedem Step gibt es verschiedene Abschnitte, in der die Teile der Eingabe-Masken strukturiert sind. Objekt-Typen definieren welche Steps verwendet werden. Steps definieren welche Abschnitte verwendet werden.<br /> <br /> <br /> Ein weiteres, grundsätzliches Problem ist die Vermischung von Daten, Logik und Darstellung. Die PHP-Seiten, die mit bisherigen Templates generiert wurden, enthielten Daten, Logik und HTML-Code an den Stellen, wo sie gerade benötigt wurden. Alles sehr vermischt in einer PHP-Datei.<br /> <br /> ;Daten (Raw-Content):<br /> Templates des Sitekit-Frameworks generieren nur noch die Daten in die PHP-Datei. Daher bezeichnen wir die Ausgabe-Templates des Sitekit-Frameworks als Aggregatoren. Zur Generierungszeit werden über die Aggregatoren die Daten so aufbereitet und angereichert, dass sie für die Darstellung gut geeignet sind. Diese Aufbereitung erfolg Ausgabe-Neutral, so dass aus den Daten nicht nur HTML, sondern auch andere Formate wie XML oder JSON erzeugt werden können. Mit diesem Ansatz wird aus Infosite ein Headless CMS. Durch dieses Vorgehen profitiert z.B auch die Suche. Bisher konnten in einem Suchergebnis nur die Daten dargestellt werden die im Suchindex enthalten waren. Jetzt ist es möglich ggf. die gesamten Daten eines Artikels für die Darstellung eines Suchergebnisses nachzuladen.<br /> <br /> ;Logik:<br /> Die Logik wird in Komponenten abgelegt. Komponenten sind Teilbereiche einer Webseite. Die gesamte Webseite wird in einzelne Komponenten zerlegt, die auch ineinander verschachtelt sein können. Viele Komponenten habe keine Logik, dann dienen sie nur als Platzhalter für die Darstellung. Komponenten wie z.B. die Suche enthalten aber auch Logik. Das Sitekit-Frameworks sorgt dafür das zunächst die Logik der Komponenten ausgeführt wird. Ist die gesamte Logik ausgeführt, kann die Webseite dargestellt werden.<br /> <br /> ;Ausgabe:<br /> Für jede Komponente existiert ein Renderer. Dieser erzeugt das HTML (oder ein anderes Ausgabeformat) für die Komponenten.<br /> <br /> ;Styling<br /> Auf Basis des HTML, das die Renderer erzeugen können Styles definiert werden um die gewünschte Darstellung zu erreichen. <br /> <br /> So sind Daten, Logik und Darstellung in Aggregatoren, Komponenten und Renderer aufgeteilt.<br /> <br /> <br /> Auf Basis dieser Technik werden von Sitepark Komponenten entwickelt, die in den Kunden-Projekten eingesetzt werden können. Ziel ist es die Komponenten konfigurativ so anpassen zu können das sie den individuellen Anforderungen der Projekte genügen. Sollte das nicht ausreichen, können kundenspezifische Komponenten erzeugt werden.<br /> <br /> <br /> Mit den oben beschriebenen Mitteln sollen folgende Probleme gelöst werden.<br /> <br /> ;Änderungen an Templates hat oft das Generieren der gesamten Site zur Folge: Die Seiten müssen nur noch generiert werden, wenn sich die Aggregatoren ändern. Bei Änderungen an der Logik oder an der Darstellung ist kein neu-generieren mehr notwendig.<br /> <br /> ;Produkt-Features werden im Kunden-System implementiert: Es gibt keinen Master-System mehr. Produkterweiterungen, die sich aus dem Projekt ergeben werden während des Projektes in das Produkt-Modul integriert und auch direkt verwendet.<br /> <br /> ;Template-Code wird schnell unübersichtlich: Auf Zeilenumbrüche muss keine Rücksicht mehr genommen werden, da Aggregatoren nur Maps und Collections füllen und keine Ausgabe erzeugen. Durch die Trennung von Daten, Logik und Ausgabe sind auch die verschiedenen Technologien SMPL, PHP, JavaScript und CSS getrennt und nicht mehr in einer Datei enthalten. <br /> <br /> ;Templates sind nicht updatefähig: Produkt- und Kunden-Anpassungen werden strickt getrennt. Produkte werden abwärts-kompatibel gehalten und sind damit updatefähig.<br /> <br /> ;Keine einheitliche Basis für Module: Das Sitekit-Framework liefert eine stabile Basis für Module.<br /> <br /> ==Enthaltene Funktionen und Komponenten==<br /> Im Sitekit-Framework enthalten sind Funktionen und Komponenten die Sitepark als &quot;Standard&quot; definiert hat, da sie in den meisten Projekten Verwendung finden.<br /> <br /> Alle von Sitekit-Framework bereit gestellten Komponenten sind barrierefrei und verhalten sich responsive.<br /> <br /> ===Generelle Funktionen===<br /> <br /> ;Navigation: Komplettes Navigations-Konzept mit verschiedenen Features wie Vererbbarkeit von Eigenschaften durch die Navigations-Struktur (z.B. Rubrik-Farbe), Mehrfachverknüpfung von Artikeln in der Navigation, geeignet für große Sites (100.000 Seiten und mehr), beliebige Navigations-Tiefe, JavaScript-basierte Mobile-fähige Navigation mit Offline-Caching.<br /> <br /> ;Suche: Voll integrierte Volltext Suche auf Basis von Solr mit Suggest, erweiterten Suchoptionen, Facettierung, unterstützt geschützte Seiten, bietet Ad-Hoc-Indizierung getriggert durch das Speichern eines Artikels, liefert Werkzeuge zur Analyse des Volltext-Index z.B. zum debuggen.<br /> <br /> ;Fehlerseiten: Redaktionell pflegbare Fehlerseiten für HTTP-Fehler (404 - Datei oder Verzeichnis nicht gefunden, ...)<br /> <br /> ;Favicons: Verwaltung der Favicons<br /> <br /> ;Geolocation: Definition von GEO-Koordinaten an Artikel. Volle Integration in die Suche für z.B. Umkreissuchen.<br /> <br /> ;Kategorisierung: Kategorie-System zur Kategorisierung von Artikeln mit voller Integration in die Suche für z.B. Facetierung.<br /> <br /> ;Teaser: Teaser-System zur Verwendung von Teasern in verschiedenen Kontexten wie: Navigation, Teaser-Listen, Slider, Karten-Marker-Info-Boxen, Suchergebnisse, Kachelsystem, Zeitsteuerung.<br /> <br /> ;Kurzadressen: Definition von Kurz-Urls<br /> <br /> ;Microsites: Microsite-System zur Erstellung von untergeordneten Sites unter eigener Domain mit geteiltem, aber Theming-fähigem Design.<br /> <br /> ;Mehrsprachigkeit (Website): Alle nicht-redaktionellen Inhalte, die auf der Webseite dargestellt werden, können über Sprachpakete in andere Sprachen übersetzt werden. Für die deutsche Sprache wird ein Sprachpaket mitgeliefert das auch nach Kundenwunsch angepasst werden kann.<br /> <br /> =Whitelabel=<br /> <br /> Damit neue Projekte nicht von Null begonnen werden müssen, wurden das Whitelabel-Modul erstellt. In diesem Modul sind immer die aktuellen Techniken zur Umsetzung von neuen Projekten enthalten. Dieses Modul dient als Kopiervorlage. Es wird immer auf die aktuellen Anforderungen von neuen Projekten angepasst. Hier wird keine Rücksicht auf Updatefähigkeit genommen.<br /> <br /> Das Sitekit-Framework soll die Technik enthalten, die Projekt-übergreifend verwendet wird. Sitepark sorgt dafür, dass das Sitekit-Framework updatefähig ist und somit als langfristige Plattform für Projekt- und Produkt-Module verwendet werden kann.<br /> <br /> Besonders im Front-End-Bereich (CSS, JavaScript) werden etablierte Techniken schneller von neueren Techniken überholt. In diesem Bereich wäre eine langfristige updatefähigkeit eine große Innovations-Bremse. Daher ist ein großer Teil der Front-End-Technik nicht im Sitekit-Framework, sondern im Whitelabel-Modul enthalten.<br /> <br /> Das Whitelabel-Modul besteht aus zwei Unter-Modulen<br /> <br /> ;IES-Modul:<br /> Das IES Modul enthält Eingabe-Templates, Aggregatoren, Komponenten, Renderer und Basis-Konfigurationen<br /> ;Styleguide:<br /> In diesem Modul ist ein Styleguide enthalten in dem das HTML hinterlegt ist, dass auch die Renderer erzeugen. Alle Komponenten sind nach dem Atomic-Design-Prinzip in Atome, Moleküle, Organismen und Templates erlegt und können so gestylt werden.<br /> <br /> =Kundenmodul=<br /> <br /> Ein Kundenmodul wird als Kopie von Whitelabel erzeugt. In diesem Modul werden alle kundenspezifischen Anforderungen implementiert.<br /> <br /> =Systemarchitektur (vereinfacht)=<br /> <br /> SiteKit und Infosite6 zusammen bilden &quot;Infosite 6 Enterprise-Edition&quot; (Infosite 6 EE)<br /> <br /> <br /> [[Datei:InfoSite6-EE-Systemarchitektur-vereinfacht.png|800px]]<br /> <br /> Die '''CMS-Oberfläche''' stellt die Eingabemaken dar, die sich aus einzelnen Abschnitten zusammensetzen. Das SiteKit stellt diese Abschnitte bereit. Das Kunden-Modul enthält kundenspezifische Konfigurationen der SiteKit-Abschnitte und kundenspezifische Abschnitte.<br /> <br /> Das '''IES Repository''' hält die Artikel-Daten, die über die CMS-Oberfläche dargestellt und bearbeitet werden können.<br /> <br /> Der '''Raw Content''' wird pro Artikel als PHP-Datei vom CMS auf dem Webserver publiziert. Die Daten werden über Sitekit- und Kundenspezifischen-Aggregatoren aus dem IES Repository geladen und in einer für die Darstellung optimierten Form zusammengestellt.<br /> <br /> Die '''Renderer''' erzeugen beim Aufruf einer Seite aus dem Raw Content das gewünschte Ausgabeformat. Das SiteKit stellt Renderer zur Verfügung die kundenspezifisch angepasst werden können. Kunden-Module stellen auch eigene Renderer bereit.<br /> <br /> Mit Hilfe eines Styleguide werden für das Styling der Webseite '''CSS''' und '''JavaScript''' implementiert.</div>

Liebold https://wiki.sitepark.com/index.php?title=Infosite_6_Enterprise_Edition&diff=8471 2017-07-13T11:35:04Z

<p>Liebold: /* Whitelabel */</p> <hr /> <div>=Motivation=<br /> <br /> Bevor die Technik für die 'Infosite 6 Enterprise Edition' zur Verfügung stand, sind Projekte mit 'alten' Methoden aufgebaut worden. Hier sollen die alten Methoden kurz beschrieben werden um den Bedarf dieser Neukonzeption nachvollziehen zu können.<br /> <br /> Templates für den Aufbau einer Webseite werden in der Datenbank eines IES-Mandanten gespeichert.<br /> Sie werden verwenden um Eingabe-Masken für das CMS zu erzeugen und Ausgaben für die Webseite. Die durch die Ausgabe-Templates generierten Dateien enthalten in der Regel PHP-, HTML-, JavaScript- und CSS-Code, der auf die Anforderungen der Webseite angepasst ist.<br /> <br /> Bearbeitet wurden die Templates im Browser über ein Textarea-Feld im Template-Editor. Dieser Template-Editor ist Teil von Infosite.<br /> <br /> Zusätzlich zu den Templates werden bei diesem Vorgen noch JavaScripte, CSS, PHP-Klassen und ggf. Bilder benötigt die als Artikel und Medien-Artikel im Mandanten gespeichert sind.<br /> <br /> Für neuen Projekte hat Sitepark ein Master-System das als Vorlage dient. Das Master-System wird einmalig in das Kunden-System kopiert.<br /> <br /> <br /> Dieses Vorgehen hatte einige Probleme zur Folge. Diese waren z.B.<br /> <br /> ;Template-Bearbeitung im Textarea-Feld: Die Bearbeitung der Templates muss Systembedingt in einem Textarea-Feld erfolgen. Durch den Template-Editor steht zwar z.B. ein Syntax-Highlighting zur Verfügung, es fehlt aber der Funktionsumfang eines Text-Editors. Um den Funktions-Umfang eines Editors nutzen zu können, muss das Template in einen Text-Editor kopiert werden. Nach der Bearbeitung muss es wieder in das Textarea-Feld kopiert werden.<br /> <br /> ;Kollaboratives Arbeiten im Projekt: Es ist nicht möglich parallel an einem Template zu arbeiten. Besonders problematisch bei zentralen Templates wie z.b. 'PHP-Head'<br /> <br /> ;Übertragung des Entwicklungsstandes vom Aufbau- zum Live-System: Auf dem Aufbau-System werden Templates entwickelt, so wie JavaScripte und CSS erzeugt. Diese müssen in regelmäßigen Abständen auf des Live-System gespielt werden. Hier nutzen wir XIP um die notwendigen Daten zu exportieren und auf dem Live-System wieder zu importieren. Bei diesem Verfahren muss bekannt sein welche Templates und Ressourcen übertragen werden dürfen und welche noch in der Entwicklung sind. Dies zu verwalten ist sehr aufwendig und Fehler-trächtig.<br /> <br /> ;Änderungen an Templates hat oft das Generieren der gesamten Site zur Folge: Änderungen am Ausgabeteil eines Templates wirken sich erst aus, wenn die Artikel, die dieses Template verwenden neu generiert werden. Häufig ist es der Fall, dass dann die gesamte Website neu generiert werden muss. Da dies bei großen Websites mehrere Stunden in Anspruch nehmen kann, blockiert das den Entwicklungs-Prozess.<br /> <br /> ;Produkt-Features werden im Kunden-System implementiert: Da die Entwicklung immer im Kunden-System und nicht im Master-System erfolgt, werden hier auch Funktionen implementiert, die in das Master-System zurück fließen müssen. Da die Templates sich durch kundenspezifische Anpassungen von dem Templates im Master-System unterscheiden kann nicht das gesamte Template übernommen werden. Es müssen im Prinzip Zeilenweise die Code-Stellen in das Master-System übertragen werden. Bei parallel laufenden Projekten, die die Funktionalität ebenfalls nutzen möchten, müssen diese Code-Stellen auch noch in das andere Kunden-Projekt übertragen werden.<br /> <br /> ;Template-Code wird schnell unübersichtlich: Bei Templates die eine Ausgabe erzeugen, möchte man möglichst unnötige Zeilenumbrüche vermeiden, die durch die Verwendung von SP-Tags entstehen. Daher werden oft Zeilenumbrüche in Kommentare gefasst oder ganz auf Zeilenumbrüche bei SP-Tags verzichtet. Weiter ist SPML-Logik mit PHP-Logik vermischt. Dadurch können Templates schnell unübersichtlich werden.<br /> <br /> ;Templates sind nicht updatefähig: Das Master-System dient nur als Kopiervorlage für Projekte. Die Templates werden nach den kundenspezifischen Anforderungen angepasst. Dadurch sind sie nicht mehr updatefähig. Neue Funktionalitäten können nur mit Aufwand in Bestands-Systeme integriert werden, da hier auch die einzelnen Code-Stellen einzeln in die Templates übertragen werden muss.<br /> <br /> ;Keine einheitliche Basis für Module: Module wie Veranstaltungskalender, Verzeichnis-Modul, Voting-Modul, Shop-Module, ... werden für einen bestimmten Stand des Master-System entwickelt. Das Master-System entwickelt sich mit jedem Projekt weiter, ohne aber eine einheitliche Basis sicherzustellen. Dies hat zur Folge das Module auf jedes System angepasst werden müssen, und nicht einfach installierbar sind.<br /> <br /> =Sitekit-Framework=<br /> <br /> Um die oben genannte Probleme zu lösen, wurden neue Konzepte entwickelt, dessen technische Implementierung eine neue Plattform bildet, die Sitekit-Framework genannt wird.<br /> <br /> Ein grundsätzliches Problem war, das Templates über Textarea-Felder in der Datenbank gespeichert werden. Templates sollen Dateien sein. Templates eines Projektes sollen in einem kundenspezifischen Modul zusammengefasst werden. Auch JavaScript, CSS, Fonts, Bilder und PHP-Dateien liegen in diesem Modul. Diese Module werden über ein GIT-Repository versioniert. Das Modul kann mit einer IDE bearbeitet werden. Auf jedem Arbeitsplatz existiert eine IES-Installation und die Arbeit an Templates kann lokal auf dem eigenen Entwicklungs-Rechner erfolgen. <br /> <br /> Damit können folgende Probleme gelöst werden:<br /> <br /> ;Template-Bearbeitung im Textarea-Feld: wird nicht mehr benötigt. Bearbeitung erfolgt über eine IDE.<br /> ;Kollaboratives Arbeiten im Projekt: Jeder entwickelt auf seinem eigenen System und über GIT werden alle Änderungen zusammengeführt.<br /> ;Übertragung des Entwicklungsstandes vom Aufbau- zum Live-System: Die Entwicklungsarbeiten werden in einem Kunden-Modul zusammengefasst und können als eine Module-Datei (war-Datei, ZIP-Format) auf das Aufbau- und Live-System gespielt werden.<br /> <br /> <br /> Wenn es keine Templates in der Datenbank mehr gibt, dann gibt es auch keine Template-Pools mehr. Template-Pools sind aber notwendig, um Artikel-Pools zu konfigurieren, damit bestimmt werden kann, mit welchen Templates Artikel angelegt werden können. Weiter wurde über Template-Pools bestimmt, welche Abschnitte für einen bestimmten Artikel-Typ ausgewählt werden dürfen. Daher wurde hier eine Alternative geschaffen.<br /> <br /> Es gibt nun Group-Types (Artikel-Pool-Typen), Objects-Types (Artikel-Typen), Steps und Sections (Abschnitte)<br /> <br /> [[Datei:Sitekit-Types-Steps-Sections.png|Sitekit Typen, Steps und Abschnitte|center|frame|800px]]<br /> <br /> Ein Objekt-Type ist ein Seiten-Typ. Dieser kann z.B. eine Homepage, eine Rubrik-Seite, eine Inhalts-Seite oder irgend eine spezialisierte Seite sein. Je nach Object-Type existieren unterschiedliche Ein- und Ausgaben. Ein Group-Type definiert eine bestimmte Art von Artikel-Pool. Über den Group-Typ wird fest gelegt, welche Objekt-Typen in Artikel-Pools eines bestimmen Group-Typs angelegt werden können. Die Bearbeitung eines Artikels ist in einzelne Schritte (Steps) unterteilt. In jedem Step gibt es verschiedene Abschnitte, in der die Teile der Eingabe-Masken strukturiert sind. Objekt-Typen definieren welche Steps verwendet werden. Steps definieren welche Abschnitte verwendet werden.<br /> <br /> <br /> Ein weiteres, grundsätzliches Problem ist die Vermischung von Daten, Logik und Darstellung. Die PHP-Seiten, die mit bisherigen Templates generiert wurden, enthielten Daten, Logik und HTML-Code an den Stellen, wo sie gerade benötigt wurden. Alles sehr vermischt in einer PHP-Datei.<br /> <br /> ;Daten (Raw-Content):<br /> Templates des Sitekit-Frameworks generieren nur noch die Daten in die PHP-Datei. Daher bezeichnen wir die Ausgabe-Templates des Sitekit-Frameworks als Aggregatoren. Zur Generierungszeit werden über die Aggregatoren die Daten so aufbereitet und angereichert, dass sie für die Darstellung gut geeignet sind. Diese Aufbereitung erfolg Ausgabe-Neutral, so dass aus den Daten nicht nur HTML, sondern auch andere Formate wie XML oder JSON erzeugt werden können. Mit diesem Ansatz wird aus Infosite ein Headless CMS. Durch dieses Vorgehen profitiert z.B auch die Suche. Bisher konnten in einem Suchergebnis nur die Daten dargestellt werden die im Suchindex enthalten waren. Jetzt ist es möglich ggf. die gesamten Daten eines Artikels für die Darstellung eines Suchergebnisses nachzuladen.<br /> <br /> ;Logik:<br /> Die Logik wird in Komponenten abgelegt. Komponenten sind Teilbereiche einer Webseite. Die gesamte Webseite wird in einzelne Komponenten zerlegt, die auch ineinander verschachtelt sein können. Viele Komponenten habe keine Logik, dann dienen sie nur als Platzhalter für die Darstellung. Komponenten wie z.B. die Suche enthalten aber auch Logik. Das Sitekit-Frameworks sorgt dafür das zunächst die Logik der Komponenten ausgeführt wird. Ist die gesamte Logik ausgeführt, kann die Webseite dargestellt werden.<br /> <br /> ;Ausgabe:<br /> Für jede Komponente existiert ein Renderer. Dieser erzeugt das HTML (oder ein anderes Ausgabeformat) für die Komponenten.<br /> <br /> ;Styling<br /> Auf Basis des HTML, das die Renderer erzeugen können Styles definiert werden um die gewünschte Darstellung zu erreichen. <br /> <br /> So sind Daten, Logik und Darstellung in Aggregatoren, Komponenten und Renderer aufgeteilt.<br /> <br /> <br /> Auf Basis dieser Technik werden von Sitepark Komponenten entwickelt, die in den Kunden-Projekten eingesetzt werden können. Ziel ist es die Komponenten konfigurativ so anpassen zu können das sie den individuellen Anforderungen der Projekte genügen. Sollte das nicht ausreichen, können kundenspezifische Komponenten erzeugt werden.<br /> <br /> <br /> Mit den oben beschriebenen Mitteln sollen folgende Probleme gelöst werden.<br /> <br /> ;Änderungen an Templates hat oft das Generieren der gesamten Site zur Folge: Die Seiten müssen nur noch generiert werden, wenn sich die Aggregatoren ändern. Bei Änderungen an der Logik oder an der Darstellung ist kein neu-generieren mehr notwendig.<br /> <br /> ;Produkt-Features werden im Kunden-System implementiert: Es gibt keinen Master-System mehr. Produkterweiterungen, die sich aus dem Projekt ergeben werden während des Projektes in das Produkt-Modul integriert und auch direkt verwendet.<br /> <br /> ;Template-Code wird schnell unübersichtlich: Auf Zeilenumbrüche muss keine Rücksicht mehr genommen werden, da Aggregatoren nur Maps und Collections füllen und keine Ausgabe erzeugen. Durch die Trennung von Daten, Logik und Ausgabe sind auch die verschiedenen Technologien SMPL, PHP, JavaScript und CSS getrennt und nicht mehr in einer Datei enthalten. <br /> <br /> ;Templates sind nicht updatefähig: Produkt- und Kunden-Anpassungen werden strickt getrennt. Produkte werden abwärts-kompatibel gehalten und sind damit updatefähig.<br /> <br /> ;Keine einheitliche Basis für Module: Das Sitekit-Framework liefert eine stabile Basis für Module.<br /> <br /> ==Enthaltene Funktionen und Komponenten==<br /> Im Sitekit-Framework enthalten sind Funktionen und Komponenten die Sitepark als &quot;Standard&quot; definiert hat, da sie in den meisten Projekten Verwendung finden.<br /> <br /> Alle von Sitekit-Framework bereit gestellten Komponenten sind barrierefrei und verhalten sich responsive.<br /> <br /> ===Generelle Funktionen===<br /> <br /> ;Navigation: Komplettes Navigations-Konzept mit verschiedenen Features wie Vererbbarkeit von Eigenschaften durch die Navigations-Struktur (z.B. Rubrik-Farbe), Mehrfachverknüpfung von Artikeln in der Navigation, geeignet für große Sites (100.000 Seiten und mehr), beliebige Navigations-Tiefe, JavaScript-basierte Mobile-fähige Navigation mit Offline-Caching.<br /> <br /> ;Suche: Voll integrierte Volltext Suche auf Basis von Solr mit Suggest, erweiterten Suchoptionen, Facettierung, unterstützt geschützte Seiten, bietet Ad-Hoc-Indizierung getriggert durch das Speichern eines Artikels, liefert Werkzeuge zur Analyse des Volltext-Index z.B. zum debuggen.<br /> <br /> ;Fehlerseiten: Redaktionell pflegbare Fehlerseiten für HTTP-Fehler (404 - Datei oder Verzeichnis nicht gefunden, ...)<br /> <br /> ;Favicons: Verwaltung der Favicons<br /> <br /> ;Geolocation: Definition von GEO-Koordinaten an Artikel. Volle Integration in die Suche für z.B. Umkreissuchen.<br /> <br /> ;Kategorisierung: Kategorie-System zur Kategorisierung von Artikeln mit voller Integration in die Suche für z.B. Facetierung.<br /> <br /> ;Teaser: Teaser-System zur Verwendung von Teasern in verschiedenen Kontexten wie: Navigation, Teaser-Listen, Slider, Karten-Marker-Info-Boxen, Suchergebnisse, Kachelsystem, Zeitsteuerung.<br /> <br /> ;Kurzadressen: Definition von Kurz-Urls<br /> <br /> ;Microsites: Microsite-System zur Erstellung von untergeordneten Sites unter eigener Domain mit geteiltem, aber Theming-fähigem Design.<br /> <br /> ;Mehrsprachigkeit (Website): Alle nicht-redaktionellen Inhalte, die auf der Webseite dargestellt werden, können über Sprachpakete in andere Sprachen übersetzt werden. Für die deutsche Sprache wird ein Sprachpaket mitgeliefert das auch nach Kundenwunsch angepasst werden kann.<br /> <br /> =Whitelabel=<br /> <br /> Damit neue Projekte nicht von Null begonnen werden müssen, wurden das Whitelabel-Modul erstellt. In diesem Modul sind immer die aktuellen Techniken zur Umsetzung von neuen Projekten enthalten. Dieses Modul dient als Kopiervorlage. Es wird immer auf die aktuellen Anforderungen von neuen Projekten angepasst. Hier wird keine Rücksicht auf Updatefähigkeit genommen.<br /> <br /> Das Sitekit-Framework soll die Technik enthalten, die Projekt-übergreifend verwendet wird. Sitepark sorgt dafür, dass das Sitekit-Framework updatefähig ist und somit als langfristige Plattform für Projekt- und Produkt-Module verwendet werden kann.<br /> <br /> Besonders im Front-End-Bereich (CSS, JavaScript) werden etablierte Techniken schneller von neueren Techniken überholt. In diesem Bereich wäre eine langfristige updatefähigkeit eine große Innovations-Bremse. Daher ist ein großer Teil der Front-End-Technik nicht im Sitekit-Framework, sondern im Whitelabel-Modul enthalten.<br /> <br /> Das Whitelabel-Modul besteht aus zwei Unter-Modulen<br /> <br /> ;IES-Modul:<br /> Das IES Modul enthält Eingabe-Templates, Aggregatoren, Komponenten, Renderer und Basis-Konfigurationen<br /> ;Styleguide:<br /> In diesem Modul ist ein Styleguide enthalten in dem das HTML hinterlegt ist, dass auch die Renderer erzeugen. Alle Komponenten sind nach dem Atomic-Design-Prinzip in Atome, Moleküle, Organismen und Templates erlegt und können so gestylt werden.<br /> <br /> =Kundenmodul=<br /> <br /> Ein Kundenmodul wird als Kopie von Whitelabel erzeugt. In diesem Modul werden alle Kundenspezifischen Anforderungen implementiert.<br /> <br /> =Systemarchitektur (vereinfacht)=<br /> <br /> SiteKit und Infosite6 zusammen bilden &quot;Infosite 6 Enterprise-Edition&quot; (Infosite 6 EE)<br /> <br /> <br /> [[Datei:InfoSite6-EE-Systemarchitektur-vereinfacht.png|800px]]<br /> <br /> Die '''CMS-Oberfläche''' stellt die Eingabemaken dar, die sich aus einzelnen Abschnitten zusammensetzen. Das SiteKit stellt diese Abschnitte bereit. Das Kunden-Modul enthält kundenspezifische Konfigurationen der SiteKit-Abschnitte und kundenspezifische Abschnitte.<br /> <br /> Das '''IES Repository''' hält die Artikel-Daten, die über die CMS-Oberfläche dargestellt und bearbeitet werden können.<br /> <br /> Der '''Raw Content''' wird pro Artikel als PHP-Datei vom CMS auf dem Webserver publiziert. Die Daten werden über Sitekit- und Kundenspezifischen-Aggregatoren aus dem IES Repository geladen und in einer für die Darstellung optimierten Form zusammengestellt.<br /> <br /> Die '''Renderer''' erzeugen beim Aufruf einer Seite aus dem Raw Content das gewünschte Ausgabeformat. Das SiteKit stellt Renderer zur Verfügung die kundenspezifisch angepasst werden können. Kunden-Module stellen auch eigene Renderer bereit.<br /> <br /> Mit Hilfe eines Styleguide werden für das Styling der Webseite '''CSS''' und '''JavaScript''' implementiert.</div>

Liebold https://wiki.sitepark.com/index.php?title=Infosite_6_Enterprise_Edition&diff=8470 2017-07-13T11:33:26Z

<p>Liebold: /* Generelle Funktionen */</p> <hr /> <div>=Motivation=<br /> <br /> Bevor die Technik für die 'Infosite 6 Enterprise Edition' zur Verfügung stand, sind Projekte mit 'alten' Methoden aufgebaut worden. Hier sollen die alten Methoden kurz beschrieben werden um den Bedarf dieser Neukonzeption nachvollziehen zu können.<br /> <br /> Templates für den Aufbau einer Webseite werden in der Datenbank eines IES-Mandanten gespeichert.<br /> Sie werden verwenden um Eingabe-Masken für das CMS zu erzeugen und Ausgaben für die Webseite. Die durch die Ausgabe-Templates generierten Dateien enthalten in der Regel PHP-, HTML-, JavaScript- und CSS-Code, der auf die Anforderungen der Webseite angepasst ist.<br /> <br /> Bearbeitet wurden die Templates im Browser über ein Textarea-Feld im Template-Editor. Dieser Template-Editor ist Teil von Infosite.<br /> <br /> Zusätzlich zu den Templates werden bei diesem Vorgen noch JavaScripte, CSS, PHP-Klassen und ggf. Bilder benötigt die als Artikel und Medien-Artikel im Mandanten gespeichert sind.<br /> <br /> Für neuen Projekte hat Sitepark ein Master-System das als Vorlage dient. Das Master-System wird einmalig in das Kunden-System kopiert.<br /> <br /> <br /> Dieses Vorgehen hatte einige Probleme zur Folge. Diese waren z.B.<br /> <br /> ;Template-Bearbeitung im Textarea-Feld: Die Bearbeitung der Templates muss Systembedingt in einem Textarea-Feld erfolgen. Durch den Template-Editor steht zwar z.B. ein Syntax-Highlighting zur Verfügung, es fehlt aber der Funktionsumfang eines Text-Editors. Um den Funktions-Umfang eines Editors nutzen zu können, muss das Template in einen Text-Editor kopiert werden. Nach der Bearbeitung muss es wieder in das Textarea-Feld kopiert werden.<br /> <br /> ;Kollaboratives Arbeiten im Projekt: Es ist nicht möglich parallel an einem Template zu arbeiten. Besonders problematisch bei zentralen Templates wie z.b. 'PHP-Head'<br /> <br /> ;Übertragung des Entwicklungsstandes vom Aufbau- zum Live-System: Auf dem Aufbau-System werden Templates entwickelt, so wie JavaScripte und CSS erzeugt. Diese müssen in regelmäßigen Abständen auf des Live-System gespielt werden. Hier nutzen wir XIP um die notwendigen Daten zu exportieren und auf dem Live-System wieder zu importieren. Bei diesem Verfahren muss bekannt sein welche Templates und Ressourcen übertragen werden dürfen und welche noch in der Entwicklung sind. Dies zu verwalten ist sehr aufwendig und Fehler-trächtig.<br /> <br /> ;Änderungen an Templates hat oft das Generieren der gesamten Site zur Folge: Änderungen am Ausgabeteil eines Templates wirken sich erst aus, wenn die Artikel, die dieses Template verwenden neu generiert werden. Häufig ist es der Fall, dass dann die gesamte Website neu generiert werden muss. Da dies bei großen Websites mehrere Stunden in Anspruch nehmen kann, blockiert das den Entwicklungs-Prozess.<br /> <br /> ;Produkt-Features werden im Kunden-System implementiert: Da die Entwicklung immer im Kunden-System und nicht im Master-System erfolgt, werden hier auch Funktionen implementiert, die in das Master-System zurück fließen müssen. Da die Templates sich durch kundenspezifische Anpassungen von dem Templates im Master-System unterscheiden kann nicht das gesamte Template übernommen werden. Es müssen im Prinzip Zeilenweise die Code-Stellen in das Master-System übertragen werden. Bei parallel laufenden Projekten, die die Funktionalität ebenfalls nutzen möchten, müssen diese Code-Stellen auch noch in das andere Kunden-Projekt übertragen werden.<br /> <br /> ;Template-Code wird schnell unübersichtlich: Bei Templates die eine Ausgabe erzeugen, möchte man möglichst unnötige Zeilenumbrüche vermeiden, die durch die Verwendung von SP-Tags entstehen. Daher werden oft Zeilenumbrüche in Kommentare gefasst oder ganz auf Zeilenumbrüche bei SP-Tags verzichtet. Weiter ist SPML-Logik mit PHP-Logik vermischt. Dadurch können Templates schnell unübersichtlich werden.<br /> <br /> ;Templates sind nicht updatefähig: Das Master-System dient nur als Kopiervorlage für Projekte. Die Templates werden nach den kundenspezifischen Anforderungen angepasst. Dadurch sind sie nicht mehr updatefähig. Neue Funktionalitäten können nur mit Aufwand in Bestands-Systeme integriert werden, da hier auch die einzelnen Code-Stellen einzeln in die Templates übertragen werden muss.<br /> <br /> ;Keine einheitliche Basis für Module: Module wie Veranstaltungskalender, Verzeichnis-Modul, Voting-Modul, Shop-Module, ... werden für einen bestimmten Stand des Master-System entwickelt. Das Master-System entwickelt sich mit jedem Projekt weiter, ohne aber eine einheitliche Basis sicherzustellen. Dies hat zur Folge das Module auf jedes System angepasst werden müssen, und nicht einfach installierbar sind.<br /> <br /> =Sitekit-Framework=<br /> <br /> Um die oben genannte Probleme zu lösen, wurden neue Konzepte entwickelt, dessen technische Implementierung eine neue Plattform bildet, die Sitekit-Framework genannt wird.<br /> <br /> Ein grundsätzliches Problem war, das Templates über Textarea-Felder in der Datenbank gespeichert werden. Templates sollen Dateien sein. Templates eines Projektes sollen in einem kundenspezifischen Modul zusammengefasst werden. Auch JavaScript, CSS, Fonts, Bilder und PHP-Dateien liegen in diesem Modul. Diese Module werden über ein GIT-Repository versioniert. Das Modul kann mit einer IDE bearbeitet werden. Auf jedem Arbeitsplatz existiert eine IES-Installation und die Arbeit an Templates kann lokal auf dem eigenen Entwicklungs-Rechner erfolgen. <br /> <br /> Damit können folgende Probleme gelöst werden:<br /> <br /> ;Template-Bearbeitung im Textarea-Feld: wird nicht mehr benötigt. Bearbeitung erfolgt über eine IDE.<br /> ;Kollaboratives Arbeiten im Projekt: Jeder entwickelt auf seinem eigenen System und über GIT werden alle Änderungen zusammengeführt.<br /> ;Übertragung des Entwicklungsstandes vom Aufbau- zum Live-System: Die Entwicklungsarbeiten werden in einem Kunden-Modul zusammengefasst und können als eine Module-Datei (war-Datei, ZIP-Format) auf das Aufbau- und Live-System gespielt werden.<br /> <br /> <br /> Wenn es keine Templates in der Datenbank mehr gibt, dann gibt es auch keine Template-Pools mehr. Template-Pools sind aber notwendig, um Artikel-Pools zu konfigurieren, damit bestimmt werden kann, mit welchen Templates Artikel angelegt werden können. Weiter wurde über Template-Pools bestimmt, welche Abschnitte für einen bestimmten Artikel-Typ ausgewählt werden dürfen. Daher wurde hier eine Alternative geschaffen.<br /> <br /> Es gibt nun Group-Types (Artikel-Pool-Typen), Objects-Types (Artikel-Typen), Steps und Sections (Abschnitte)<br /> <br /> [[Datei:Sitekit-Types-Steps-Sections.png|Sitekit Typen, Steps und Abschnitte|center|frame|800px]]<br /> <br /> Ein Objekt-Type ist ein Seiten-Typ. Dieser kann z.B. eine Homepage, eine Rubrik-Seite, eine Inhalts-Seite oder irgend eine spezialisierte Seite sein. Je nach Object-Type existieren unterschiedliche Ein- und Ausgaben. Ein Group-Type definiert eine bestimmte Art von Artikel-Pool. Über den Group-Typ wird fest gelegt, welche Objekt-Typen in Artikel-Pools eines bestimmen Group-Typs angelegt werden können. Die Bearbeitung eines Artikels ist in einzelne Schritte (Steps) unterteilt. In jedem Step gibt es verschiedene Abschnitte, in der die Teile der Eingabe-Masken strukturiert sind. Objekt-Typen definieren welche Steps verwendet werden. Steps definieren welche Abschnitte verwendet werden.<br /> <br /> <br /> Ein weiteres, grundsätzliches Problem ist die Vermischung von Daten, Logik und Darstellung. Die PHP-Seiten, die mit bisherigen Templates generiert wurden, enthielten Daten, Logik und HTML-Code an den Stellen, wo sie gerade benötigt wurden. Alles sehr vermischt in einer PHP-Datei.<br /> <br /> ;Daten (Raw-Content):<br /> Templates des Sitekit-Frameworks generieren nur noch die Daten in die PHP-Datei. Daher bezeichnen wir die Ausgabe-Templates des Sitekit-Frameworks als Aggregatoren. Zur Generierungszeit werden über die Aggregatoren die Daten so aufbereitet und angereichert, dass sie für die Darstellung gut geeignet sind. Diese Aufbereitung erfolg Ausgabe-Neutral, so dass aus den Daten nicht nur HTML, sondern auch andere Formate wie XML oder JSON erzeugt werden können. Mit diesem Ansatz wird aus Infosite ein Headless CMS. Durch dieses Vorgehen profitiert z.B auch die Suche. Bisher konnten in einem Suchergebnis nur die Daten dargestellt werden die im Suchindex enthalten waren. Jetzt ist es möglich ggf. die gesamten Daten eines Artikels für die Darstellung eines Suchergebnisses nachzuladen.<br /> <br /> ;Logik:<br /> Die Logik wird in Komponenten abgelegt. Komponenten sind Teilbereiche einer Webseite. Die gesamte Webseite wird in einzelne Komponenten zerlegt, die auch ineinander verschachtelt sein können. Viele Komponenten habe keine Logik, dann dienen sie nur als Platzhalter für die Darstellung. Komponenten wie z.B. die Suche enthalten aber auch Logik. Das Sitekit-Frameworks sorgt dafür das zunächst die Logik der Komponenten ausgeführt wird. Ist die gesamte Logik ausgeführt, kann die Webseite dargestellt werden.<br /> <br /> ;Ausgabe:<br /> Für jede Komponente existiert ein Renderer. Dieser erzeugt das HTML (oder ein anderes Ausgabeformat) für die Komponenten.<br /> <br /> ;Styling<br /> Auf Basis des HTML, das die Renderer erzeugen können Styles definiert werden um die gewünschte Darstellung zu erreichen. <br /> <br /> So sind Daten, Logik und Darstellung in Aggregatoren, Komponenten und Renderer aufgeteilt.<br /> <br /> <br /> Auf Basis dieser Technik werden von Sitepark Komponenten entwickelt, die in den Kunden-Projekten eingesetzt werden können. Ziel ist es die Komponenten konfigurativ so anpassen zu können das sie den individuellen Anforderungen der Projekte genügen. Sollte das nicht ausreichen, können kundenspezifische Komponenten erzeugt werden.<br /> <br /> <br /> Mit den oben beschriebenen Mitteln sollen folgende Probleme gelöst werden.<br /> <br /> ;Änderungen an Templates hat oft das Generieren der gesamten Site zur Folge: Die Seiten müssen nur noch generiert werden, wenn sich die Aggregatoren ändern. Bei Änderungen an der Logik oder an der Darstellung ist kein neu-generieren mehr notwendig.<br /> <br /> ;Produkt-Features werden im Kunden-System implementiert: Es gibt keinen Master-System mehr. Produkterweiterungen, die sich aus dem Projekt ergeben werden während des Projektes in das Produkt-Modul integriert und auch direkt verwendet.<br /> <br /> ;Template-Code wird schnell unübersichtlich: Auf Zeilenumbrüche muss keine Rücksicht mehr genommen werden, da Aggregatoren nur Maps und Collections füllen und keine Ausgabe erzeugen. Durch die Trennung von Daten, Logik und Ausgabe sind auch die verschiedenen Technologien SMPL, PHP, JavaScript und CSS getrennt und nicht mehr in einer Datei enthalten. <br /> <br /> ;Templates sind nicht updatefähig: Produkt- und Kunden-Anpassungen werden strickt getrennt. Produkte werden abwärts-kompatibel gehalten und sind damit updatefähig.<br /> <br /> ;Keine einheitliche Basis für Module: Das Sitekit-Framework liefert eine stabile Basis für Module.<br /> <br /> ==Enthaltene Funktionen und Komponenten==<br /> Im Sitekit-Framework enthalten sind Funktionen und Komponenten die Sitepark als &quot;Standard&quot; definiert hat, da sie in den meisten Projekten Verwendung finden.<br /> <br /> Alle von Sitekit-Framework bereit gestellten Komponenten sind barrierefrei und verhalten sich responsive.<br /> <br /> ===Generelle Funktionen===<br /> <br /> ;Navigation: Komplettes Navigations-Konzept mit verschiedenen Features wie Vererbbarkeit von Eigenschaften durch die Navigations-Struktur (z.B. Rubrik-Farbe), Mehrfachverknüpfung von Artikeln in der Navigation, geeignet für große Sites (100.000 Seiten und mehr), beliebige Navigations-Tiefe, JavaScript-basierte Mobile-fähige Navigation mit Offline-Caching.<br /> <br /> ;Suche: Voll integrierte Volltext Suche auf Basis von Solr mit Suggest, erweiterten Suchoptionen, Facettierung, unterstützt geschützte Seiten, bietet Ad-Hoc-Indizierung getriggert durch das Speichern eines Artikels, liefert Werkzeuge zur Analyse des Volltext-Index z.B. zum debuggen.<br /> <br /> ;Fehlerseiten: Redaktionell pflegbare Fehlerseiten für HTTP-Fehler (404 - Datei oder Verzeichnis nicht gefunden, ...)<br /> <br /> ;Favicons: Verwaltung der Favicons<br /> <br /> ;Geolocation: Definition von GEO-Koordinaten an Artikel. Volle Integration in die Suche für z.B. Umkreissuchen.<br /> <br /> ;Kategorisierung: Kategorie-System zur Kategorisierung von Artikeln mit voller Integration in die Suche für z.B. Facetierung.<br /> <br /> ;Teaser: Teaser-System zur Verwendung von Teasern in verschiedenen Kontexten wie: Navigation, Teaser-Listen, Slider, Karten-Marker-Info-Boxen, Suchergebnisse, Kachelsystem, Zeitsteuerung.<br /> <br /> ;Kurzadressen: Definition von Kurz-Urls<br /> <br /> ;Microsites: Microsite-System zur Erstellung von untergeordneten Sites unter eigener Domain mit geteiltem, aber Theming-fähigem Design.<br /> <br /> ;Mehrsprachigkeit (Website): Alle nicht-redaktionellen Inhalte, die auf der Webseite dargestellt werden, können über Sprachpakete in andere Sprachen übersetzt werden. Für die deutsche Sprache wird ein Sprachpaket mitgeliefert das auch nach Kundenwunsch angepasst werden kann.<br /> <br /> =Whitelabel=<br /> <br /> Damit neue Projekte nicht von Null begonnen werden müssen, wurden das Whitelabel-Modul erstellt. In diesem Modul sind immer die aktuellen Techniken zur Umsetzung von neuen Projekten enthalten. Dieses Modul dient als Kopiervorlage. Es wird immer auf die aktuellen Anforderungen von neuen Projekten angepasst. Hier wird keine Rücksicht auf Updatefähigkeit genommen.<br /> <br /> Das SiteKit soll die Technik enthalten die Projekt-übergreifend verwendet wird. Sitepark sorgt dafür, dass das SiteKit-Modul update-fähig ist und somit als langfristige Plattform für Projekt- und Produkt-Module verwendet werden kann.<br /> <br /> Besonders im Front-End-Bereich (CSS, JavaScript) werden etablierte Techniken schneller von neueren Techniken überholt. In diesem Bereich wäre eine langfristige update-Fähigkeit eine große Innovations-Bremse. Daher ist ein großer Teil der Front-End-Technik nicht im Sitekit-Modul, sondern im Whitelabel-Modul enthalten.<br /> <br /> Das Whitelabel-Modul besteht aus zwei Unter-Modulen<br /> <br /> ;IES-Modul:<br /> Das IES Modul enthält Eingabe-Templates, Aggregatoren, Komponenten, Renderer und Basis-Konfigurationen<br /> ;Styleguide:<br /> In diesem Modul ist ein Styleguide enthalten in dem das HTML hinterlegt ist, dass auch die Renderer erzeugen. Alle Komponenten sind nach dem Atomic-Design-Prinzip in Atome, Moleküle, Organismen und Templates erlegt und können so gestylt werden.<br /> <br /> =Kundenmodul=<br /> <br /> Ein Kundenmodul wird als Kopie von Whitelabel erzeugt. In diesem Modul werden alle Kundenspezifischen Anforderungen implementiert.<br /> <br /> =Systemarchitektur (vereinfacht)=<br /> <br /> SiteKit und Infosite6 zusammen bilden &quot;Infosite 6 Enterprise-Edition&quot; (Infosite 6 EE)<br /> <br /> <br /> [[Datei:InfoSite6-EE-Systemarchitektur-vereinfacht.png|800px]]<br /> <br /> Die '''CMS-Oberfläche''' stellt die Eingabemaken dar, die sich aus einzelnen Abschnitten zusammensetzen. Das SiteKit stellt diese Abschnitte bereit. Das Kunden-Modul enthält kundenspezifische Konfigurationen der SiteKit-Abschnitte und kundenspezifische Abschnitte.<br /> <br /> Das '''IES Repository''' hält die Artikel-Daten, die über die CMS-Oberfläche dargestellt und bearbeitet werden können.<br /> <br /> Der '''Raw Content''' wird pro Artikel als PHP-Datei vom CMS auf dem Webserver publiziert. Die Daten werden über Sitekit- und Kundenspezifischen-Aggregatoren aus dem IES Repository geladen und in einer für die Darstellung optimierten Form zusammengestellt.<br /> <br /> Die '''Renderer''' erzeugen beim Aufruf einer Seite aus dem Raw Content das gewünschte Ausgabeformat. Das SiteKit stellt Renderer zur Verfügung die kundenspezifisch angepasst werden können. Kunden-Module stellen auch eigene Renderer bereit.<br /> <br /> Mit Hilfe eines Styleguide werden für das Styling der Webseite '''CSS''' und '''JavaScript''' implementiert.</div>

Liebold https://wiki.sitepark.com/index.php?title=Infosite_6_Enterprise_Edition&diff=8469 2017-07-13T11:32:05Z

<p>Liebold: /* Sitekit-Framework */</p> <hr /> <div>=Motivation=<br /> <br /> Bevor die Technik für die 'Infosite 6 Enterprise Edition' zur Verfügung stand, sind Projekte mit 'alten' Methoden aufgebaut worden. Hier sollen die alten Methoden kurz beschrieben werden um den Bedarf dieser Neukonzeption nachvollziehen zu können.<br /> <br /> Templates für den Aufbau einer Webseite werden in der Datenbank eines IES-Mandanten gespeichert.<br /> Sie werden verwenden um Eingabe-Masken für das CMS zu erzeugen und Ausgaben für die Webseite. Die durch die Ausgabe-Templates generierten Dateien enthalten in der Regel PHP-, HTML-, JavaScript- und CSS-Code, der auf die Anforderungen der Webseite angepasst ist.<br /> <br /> Bearbeitet wurden die Templates im Browser über ein Textarea-Feld im Template-Editor. Dieser Template-Editor ist Teil von Infosite.<br /> <br /> Zusätzlich zu den Templates werden bei diesem Vorgen noch JavaScripte, CSS, PHP-Klassen und ggf. Bilder benötigt die als Artikel und Medien-Artikel im Mandanten gespeichert sind.<br /> <br /> Für neuen Projekte hat Sitepark ein Master-System das als Vorlage dient. Das Master-System wird einmalig in das Kunden-System kopiert.<br /> <br /> <br /> Dieses Vorgehen hatte einige Probleme zur Folge. Diese waren z.B.<br /> <br /> ;Template-Bearbeitung im Textarea-Feld: Die Bearbeitung der Templates muss Systembedingt in einem Textarea-Feld erfolgen. Durch den Template-Editor steht zwar z.B. ein Syntax-Highlighting zur Verfügung, es fehlt aber der Funktionsumfang eines Text-Editors. Um den Funktions-Umfang eines Editors nutzen zu können, muss das Template in einen Text-Editor kopiert werden. Nach der Bearbeitung muss es wieder in das Textarea-Feld kopiert werden.<br /> <br /> ;Kollaboratives Arbeiten im Projekt: Es ist nicht möglich parallel an einem Template zu arbeiten. Besonders problematisch bei zentralen Templates wie z.b. 'PHP-Head'<br /> <br /> ;Übertragung des Entwicklungsstandes vom Aufbau- zum Live-System: Auf dem Aufbau-System werden Templates entwickelt, so wie JavaScripte und CSS erzeugt. Diese müssen in regelmäßigen Abständen auf des Live-System gespielt werden. Hier nutzen wir XIP um die notwendigen Daten zu exportieren und auf dem Live-System wieder zu importieren. Bei diesem Verfahren muss bekannt sein welche Templates und Ressourcen übertragen werden dürfen und welche noch in der Entwicklung sind. Dies zu verwalten ist sehr aufwendig und Fehler-trächtig.<br /> <br /> ;Änderungen an Templates hat oft das Generieren der gesamten Site zur Folge: Änderungen am Ausgabeteil eines Templates wirken sich erst aus, wenn die Artikel, die dieses Template verwenden neu generiert werden. Häufig ist es der Fall, dass dann die gesamte Website neu generiert werden muss. Da dies bei großen Websites mehrere Stunden in Anspruch nehmen kann, blockiert das den Entwicklungs-Prozess.<br /> <br /> ;Produkt-Features werden im Kunden-System implementiert: Da die Entwicklung immer im Kunden-System und nicht im Master-System erfolgt, werden hier auch Funktionen implementiert, die in das Master-System zurück fließen müssen. Da die Templates sich durch kundenspezifische Anpassungen von dem Templates im Master-System unterscheiden kann nicht das gesamte Template übernommen werden. Es müssen im Prinzip Zeilenweise die Code-Stellen in das Master-System übertragen werden. Bei parallel laufenden Projekten, die die Funktionalität ebenfalls nutzen möchten, müssen diese Code-Stellen auch noch in das andere Kunden-Projekt übertragen werden.<br /> <br /> ;Template-Code wird schnell unübersichtlich: Bei Templates die eine Ausgabe erzeugen, möchte man möglichst unnötige Zeilenumbrüche vermeiden, die durch die Verwendung von SP-Tags entstehen. Daher werden oft Zeilenumbrüche in Kommentare gefasst oder ganz auf Zeilenumbrüche bei SP-Tags verzichtet. Weiter ist SPML-Logik mit PHP-Logik vermischt. Dadurch können Templates schnell unübersichtlich werden.<br /> <br /> ;Templates sind nicht updatefähig: Das Master-System dient nur als Kopiervorlage für Projekte. Die Templates werden nach den kundenspezifischen Anforderungen angepasst. Dadurch sind sie nicht mehr updatefähig. Neue Funktionalitäten können nur mit Aufwand in Bestands-Systeme integriert werden, da hier auch die einzelnen Code-Stellen einzeln in die Templates übertragen werden muss.<br /> <br /> ;Keine einheitliche Basis für Module: Module wie Veranstaltungskalender, Verzeichnis-Modul, Voting-Modul, Shop-Module, ... werden für einen bestimmten Stand des Master-System entwickelt. Das Master-System entwickelt sich mit jedem Projekt weiter, ohne aber eine einheitliche Basis sicherzustellen. Dies hat zur Folge das Module auf jedes System angepasst werden müssen, und nicht einfach installierbar sind.<br /> <br /> =Sitekit-Framework=<br /> <br /> Um die oben genannte Probleme zu lösen, wurden neue Konzepte entwickelt, dessen technische Implementierung eine neue Plattform bildet, die Sitekit-Framework genannt wird.<br /> <br /> Ein grundsätzliches Problem war, das Templates über Textarea-Felder in der Datenbank gespeichert werden. Templates sollen Dateien sein. Templates eines Projektes sollen in einem kundenspezifischen Modul zusammengefasst werden. Auch JavaScript, CSS, Fonts, Bilder und PHP-Dateien liegen in diesem Modul. Diese Module werden über ein GIT-Repository versioniert. Das Modul kann mit einer IDE bearbeitet werden. Auf jedem Arbeitsplatz existiert eine IES-Installation und die Arbeit an Templates kann lokal auf dem eigenen Entwicklungs-Rechner erfolgen. <br /> <br /> Damit können folgende Probleme gelöst werden:<br /> <br /> ;Template-Bearbeitung im Textarea-Feld: wird nicht mehr benötigt. Bearbeitung erfolgt über eine IDE.<br /> ;Kollaboratives Arbeiten im Projekt: Jeder entwickelt auf seinem eigenen System und über GIT werden alle Änderungen zusammengeführt.<br /> ;Übertragung des Entwicklungsstandes vom Aufbau- zum Live-System: Die Entwicklungsarbeiten werden in einem Kunden-Modul zusammengefasst und können als eine Module-Datei (war-Datei, ZIP-Format) auf das Aufbau- und Live-System gespielt werden.<br /> <br /> <br /> Wenn es keine Templates in der Datenbank mehr gibt, dann gibt es auch keine Template-Pools mehr. Template-Pools sind aber notwendig, um Artikel-Pools zu konfigurieren, damit bestimmt werden kann, mit welchen Templates Artikel angelegt werden können. Weiter wurde über Template-Pools bestimmt, welche Abschnitte für einen bestimmten Artikel-Typ ausgewählt werden dürfen. Daher wurde hier eine Alternative geschaffen.<br /> <br /> Es gibt nun Group-Types (Artikel-Pool-Typen), Objects-Types (Artikel-Typen), Steps und Sections (Abschnitte)<br /> <br /> [[Datei:Sitekit-Types-Steps-Sections.png|Sitekit Typen, Steps und Abschnitte|center|frame|800px]]<br /> <br /> Ein Objekt-Type ist ein Seiten-Typ. Dieser kann z.B. eine Homepage, eine Rubrik-Seite, eine Inhalts-Seite oder irgend eine spezialisierte Seite sein. Je nach Object-Type existieren unterschiedliche Ein- und Ausgaben. Ein Group-Type definiert eine bestimmte Art von Artikel-Pool. Über den Group-Typ wird fest gelegt, welche Objekt-Typen in Artikel-Pools eines bestimmen Group-Typs angelegt werden können. Die Bearbeitung eines Artikels ist in einzelne Schritte (Steps) unterteilt. In jedem Step gibt es verschiedene Abschnitte, in der die Teile der Eingabe-Masken strukturiert sind. Objekt-Typen definieren welche Steps verwendet werden. Steps definieren welche Abschnitte verwendet werden.<br /> <br /> <br /> Ein weiteres, grundsätzliches Problem ist die Vermischung von Daten, Logik und Darstellung. Die PHP-Seiten, die mit bisherigen Templates generiert wurden, enthielten Daten, Logik und HTML-Code an den Stellen, wo sie gerade benötigt wurden. Alles sehr vermischt in einer PHP-Datei.<br /> <br /> ;Daten (Raw-Content):<br /> Templates des Sitekit-Frameworks generieren nur noch die Daten in die PHP-Datei. Daher bezeichnen wir die Ausgabe-Templates des Sitekit-Frameworks als Aggregatoren. Zur Generierungszeit werden über die Aggregatoren die Daten so aufbereitet und angereichert, dass sie für die Darstellung gut geeignet sind. Diese Aufbereitung erfolg Ausgabe-Neutral, so dass aus den Daten nicht nur HTML, sondern auch andere Formate wie XML oder JSON erzeugt werden können. Mit diesem Ansatz wird aus Infosite ein Headless CMS. Durch dieses Vorgehen profitiert z.B auch die Suche. Bisher konnten in einem Suchergebnis nur die Daten dargestellt werden die im Suchindex enthalten waren. Jetzt ist es möglich ggf. die gesamten Daten eines Artikels für die Darstellung eines Suchergebnisses nachzuladen.<br /> <br /> ;Logik:<br /> Die Logik wird in Komponenten abgelegt. Komponenten sind Teilbereiche einer Webseite. Die gesamte Webseite wird in einzelne Komponenten zerlegt, die auch ineinander verschachtelt sein können. Viele Komponenten habe keine Logik, dann dienen sie nur als Platzhalter für die Darstellung. Komponenten wie z.B. die Suche enthalten aber auch Logik. Das Sitekit-Frameworks sorgt dafür das zunächst die Logik der Komponenten ausgeführt wird. Ist die gesamte Logik ausgeführt, kann die Webseite dargestellt werden.<br /> <br /> ;Ausgabe:<br /> Für jede Komponente existiert ein Renderer. Dieser erzeugt das HTML (oder ein anderes Ausgabeformat) für die Komponenten.<br /> <br /> ;Styling<br /> Auf Basis des HTML, das die Renderer erzeugen können Styles definiert werden um die gewünschte Darstellung zu erreichen. <br /> <br /> So sind Daten, Logik und Darstellung in Aggregatoren, Komponenten und Renderer aufgeteilt.<br /> <br /> <br /> Auf Basis dieser Technik werden von Sitepark Komponenten entwickelt, die in den Kunden-Projekten eingesetzt werden können. Ziel ist es die Komponenten konfigurativ so anpassen zu können das sie den individuellen Anforderungen der Projekte genügen. Sollte das nicht ausreichen, können kundenspezifische Komponenten erzeugt werden.<br /> <br /> <br /> Mit den oben beschriebenen Mitteln sollen folgende Probleme gelöst werden.<br /> <br /> ;Änderungen an Templates hat oft das Generieren der gesamten Site zur Folge: Die Seiten müssen nur noch generiert werden, wenn sich die Aggregatoren ändern. Bei Änderungen an der Logik oder an der Darstellung ist kein neu-generieren mehr notwendig.<br /> <br /> ;Produkt-Features werden im Kunden-System implementiert: Es gibt keinen Master-System mehr. Produkterweiterungen, die sich aus dem Projekt ergeben werden während des Projektes in das Produkt-Modul integriert und auch direkt verwendet.<br /> <br /> ;Template-Code wird schnell unübersichtlich: Auf Zeilenumbrüche muss keine Rücksicht mehr genommen werden, da Aggregatoren nur Maps und Collections füllen und keine Ausgabe erzeugen. Durch die Trennung von Daten, Logik und Ausgabe sind auch die verschiedenen Technologien SMPL, PHP, JavaScript und CSS getrennt und nicht mehr in einer Datei enthalten. <br /> <br /> ;Templates sind nicht updatefähig: Produkt- und Kunden-Anpassungen werden strickt getrennt. Produkte werden abwärts-kompatibel gehalten und sind damit updatefähig.<br /> <br /> ;Keine einheitliche Basis für Module: Das Sitekit-Framework liefert eine stabile Basis für Module.<br /> <br /> ==Enthaltene Funktionen und Komponenten==<br /> Im Sitekit-Framework enthalten sind Funktionen und Komponenten die Sitepark als &quot;Standard&quot; definiert hat, da sie in den meisten Projekten Verwendung finden.<br /> <br /> Alle von Sitekit-Framework bereit gestellten Komponenten sind barrierefrei und verhalten sich responsive.<br /> <br /> ===Generelle Funktionen===<br /> <br /> ;Navigation: Komplettes Navigations-Konzept mit verschiedenen Features wie Vererbbarkeit von Eigenschaften durch die Navigations-Struktur (z.B. Rubrik-Farbe), Mehrfachverknüpfung von Artikeln in der Navigation, geeignet für große Sites (100.000 Seiten und mehr), beliebige Navigations-Tiefe, JavaScript-basierte Mobile-fähige Navigation mit Offline-Caching.<br /> <br /> ;Suche: Voll integrierte Volltext Suche auf Basis von Solr mit Suggest, erweiterten Suchoptionen, Facettierung, unterstützt geschützte Seiten, bietet Ad-Hoc-Indizierung getriggert durch das Speichern eines Artikels, liefert Werkzeuge zur Analyse des Volltext-Index z.B. zum debuggen.<br /> <br /> ;Fehlerseiten: Redaktionell pflegbare Fehlerseiten für HTTP-Fehler (404 - Datei oder Verzeichnis nicht gefunden, ...)<br /> <br /> ;Favicons: Verwaltung der Favicons<br /> <br /> ;Geolokation: Definition von GEO-Koordinaten an Artikel. Volle Integration in die Suche für Z.B. Umkreissuchen.<br /> <br /> ;Kategorisierung: Kategorie-System zur Kategorisierung von Artikeln mit voller Integration in die Suche für z.B. Facetierung.<br /> <br /> ;Teaser: Teaser-System zur Verwendung von Teasern in verschiedenen Kontexten wie: Navigation, Teaser-Listen, Slider, Karten-Marker-Info-Boxen, Suchergebnisse, Kachelsystem. Zeitsteuerung<br /> <br /> ;Kurzadressen: Definition von Kurz-Urls<br /> <br /> ;Microsites: Microsite-System zur Erstellung von untergeordneten Sites unter eigener Domain mit geteiltem, aber Theming-fähigem Design.<br /> <br /> ;Mehrsprachigkeit (Website): Alle nicht-redaktionellen Inhalte, die auf der Webseite dargestellt werden, können über Sprachpakete in andere Sprachen übersetzt werden. Für die deutsche Sprache wird ein Sprachpaket mitgeliefert das auch nach Kundenwunsch angepasst werden kann.<br /> <br /> =Whitelabel=<br /> <br /> Damit neue Projekte nicht von Null begonnen werden müssen, wurden das Whitelabel-Modul erstellt. In diesem Modul sind immer die aktuellen Techniken zur Umsetzung von neuen Projekten enthalten. Dieses Modul dient als Kopiervorlage. Es wird immer auf die aktuellen Anforderungen von neuen Projekten angepasst. Hier wird keine Rücksicht auf Updatefähigkeit genommen.<br /> <br /> Das SiteKit soll die Technik enthalten die Projekt-übergreifend verwendet wird. Sitepark sorgt dafür, dass das SiteKit-Modul update-fähig ist und somit als langfristige Plattform für Projekt- und Produkt-Module verwendet werden kann.<br /> <br /> Besonders im Front-End-Bereich (CSS, JavaScript) werden etablierte Techniken schneller von neueren Techniken überholt. In diesem Bereich wäre eine langfristige update-Fähigkeit eine große Innovations-Bremse. Daher ist ein großer Teil der Front-End-Technik nicht im Sitekit-Modul, sondern im Whitelabel-Modul enthalten.<br /> <br /> Das Whitelabel-Modul besteht aus zwei Unter-Modulen<br /> <br /> ;IES-Modul:<br /> Das IES Modul enthält Eingabe-Templates, Aggregatoren, Komponenten, Renderer und Basis-Konfigurationen<br /> ;Styleguide:<br /> In diesem Modul ist ein Styleguide enthalten in dem das HTML hinterlegt ist, dass auch die Renderer erzeugen. Alle Komponenten sind nach dem Atomic-Design-Prinzip in Atome, Moleküle, Organismen und Templates erlegt und können so gestylt werden.<br /> <br /> =Kundenmodul=<br /> <br /> Ein Kundenmodul wird als Kopie von Whitelabel erzeugt. In diesem Modul werden alle Kundenspezifischen Anforderungen implementiert.<br /> <br /> =Systemarchitektur (vereinfacht)=<br /> <br /> SiteKit und Infosite6 zusammen bilden &quot;Infosite 6 Enterprise-Edition&quot; (Infosite 6 EE)<br /> <br /> <br /> [[Datei:InfoSite6-EE-Systemarchitektur-vereinfacht.png|800px]]<br /> <br /> Die '''CMS-Oberfläche''' stellt die Eingabemaken dar, die sich aus einzelnen Abschnitten zusammensetzen. Das SiteKit stellt diese Abschnitte bereit. Das Kunden-Modul enthält kundenspezifische Konfigurationen der SiteKit-Abschnitte und kundenspezifische Abschnitte.<br /> <br /> Das '''IES Repository''' hält die Artikel-Daten, die über die CMS-Oberfläche dargestellt und bearbeitet werden können.<br /> <br /> Der '''Raw Content''' wird pro Artikel als PHP-Datei vom CMS auf dem Webserver publiziert. Die Daten werden über Sitekit- und Kundenspezifischen-Aggregatoren aus dem IES Repository geladen und in einer für die Darstellung optimierten Form zusammengestellt.<br /> <br /> Die '''Renderer''' erzeugen beim Aufruf einer Seite aus dem Raw Content das gewünschte Ausgabeformat. Das SiteKit stellt Renderer zur Verfügung die kundenspezifisch angepasst werden können. Kunden-Module stellen auch eigene Renderer bereit.<br /> <br /> Mit Hilfe eines Styleguide werden für das Styling der Webseite '''CSS''' und '''JavaScript''' implementiert.</div>

Liebold https://wiki.sitepark.com/index.php?title=Infosite_6_Enterprise_Edition&diff=8468 2017-07-13T11:29:58Z

<p>Liebold: /* Sitekit-Framework */</p> <hr /> <div>=Motivation=<br /> <br /> Bevor die Technik für die 'Infosite 6 Enterprise Edition' zur Verfügung stand, sind Projekte mit 'alten' Methoden aufgebaut worden. Hier sollen die alten Methoden kurz beschrieben werden um den Bedarf dieser Neukonzeption nachvollziehen zu können.<br /> <br /> Templates für den Aufbau einer Webseite werden in der Datenbank eines IES-Mandanten gespeichert.<br /> Sie werden verwenden um Eingabe-Masken für das CMS zu erzeugen und Ausgaben für die Webseite. Die durch die Ausgabe-Templates generierten Dateien enthalten in der Regel PHP-, HTML-, JavaScript- und CSS-Code, der auf die Anforderungen der Webseite angepasst ist.<br /> <br /> Bearbeitet wurden die Templates im Browser über ein Textarea-Feld im Template-Editor. Dieser Template-Editor ist Teil von Infosite.<br /> <br /> Zusätzlich zu den Templates werden bei diesem Vorgen noch JavaScripte, CSS, PHP-Klassen und ggf. Bilder benötigt die als Artikel und Medien-Artikel im Mandanten gespeichert sind.<br /> <br /> Für neuen Projekte hat Sitepark ein Master-System das als Vorlage dient. Das Master-System wird einmalig in das Kunden-System kopiert.<br /> <br /> <br /> Dieses Vorgehen hatte einige Probleme zur Folge. Diese waren z.B.<br /> <br /> ;Template-Bearbeitung im Textarea-Feld: Die Bearbeitung der Templates muss Systembedingt in einem Textarea-Feld erfolgen. Durch den Template-Editor steht zwar z.B. ein Syntax-Highlighting zur Verfügung, es fehlt aber der Funktionsumfang eines Text-Editors. Um den Funktions-Umfang eines Editors nutzen zu können, muss das Template in einen Text-Editor kopiert werden. Nach der Bearbeitung muss es wieder in das Textarea-Feld kopiert werden.<br /> <br /> ;Kollaboratives Arbeiten im Projekt: Es ist nicht möglich parallel an einem Template zu arbeiten. Besonders problematisch bei zentralen Templates wie z.b. 'PHP-Head'<br /> <br /> ;Übertragung des Entwicklungsstandes vom Aufbau- zum Live-System: Auf dem Aufbau-System werden Templates entwickelt, so wie JavaScripte und CSS erzeugt. Diese müssen in regelmäßigen Abständen auf des Live-System gespielt werden. Hier nutzen wir XIP um die notwendigen Daten zu exportieren und auf dem Live-System wieder zu importieren. Bei diesem Verfahren muss bekannt sein welche Templates und Ressourcen übertragen werden dürfen und welche noch in der Entwicklung sind. Dies zu verwalten ist sehr aufwendig und Fehler-trächtig.<br /> <br /> ;Änderungen an Templates hat oft das Generieren der gesamten Site zur Folge: Änderungen am Ausgabeteil eines Templates wirken sich erst aus, wenn die Artikel, die dieses Template verwenden neu generiert werden. Häufig ist es der Fall, dass dann die gesamte Website neu generiert werden muss. Da dies bei großen Websites mehrere Stunden in Anspruch nehmen kann, blockiert das den Entwicklungs-Prozess.<br /> <br /> ;Produkt-Features werden im Kunden-System implementiert: Da die Entwicklung immer im Kunden-System und nicht im Master-System erfolgt, werden hier auch Funktionen implementiert, die in das Master-System zurück fließen müssen. Da die Templates sich durch kundenspezifische Anpassungen von dem Templates im Master-System unterscheiden kann nicht das gesamte Template übernommen werden. Es müssen im Prinzip Zeilenweise die Code-Stellen in das Master-System übertragen werden. Bei parallel laufenden Projekten, die die Funktionalität ebenfalls nutzen möchten, müssen diese Code-Stellen auch noch in das andere Kunden-Projekt übertragen werden.<br /> <br /> ;Template-Code wird schnell unübersichtlich: Bei Templates die eine Ausgabe erzeugen, möchte man möglichst unnötige Zeilenumbrüche vermeiden, die durch die Verwendung von SP-Tags entstehen. Daher werden oft Zeilenumbrüche in Kommentare gefasst oder ganz auf Zeilenumbrüche bei SP-Tags verzichtet. Weiter ist SPML-Logik mit PHP-Logik vermischt. Dadurch können Templates schnell unübersichtlich werden.<br /> <br /> ;Templates sind nicht updatefähig: Das Master-System dient nur als Kopiervorlage für Projekte. Die Templates werden nach den kundenspezifischen Anforderungen angepasst. Dadurch sind sie nicht mehr updatefähig. Neue Funktionalitäten können nur mit Aufwand in Bestands-Systeme integriert werden, da hier auch die einzelnen Code-Stellen einzeln in die Templates übertragen werden muss.<br /> <br /> ;Keine einheitliche Basis für Module: Module wie Veranstaltungskalender, Verzeichnis-Modul, Voting-Modul, Shop-Module, ... werden für einen bestimmten Stand des Master-System entwickelt. Das Master-System entwickelt sich mit jedem Projekt weiter, ohne aber eine einheitliche Basis sicherzustellen. Dies hat zur Folge das Module auf jedes System angepasst werden müssen, und nicht einfach installierbar sind.<br /> <br /> =Sitekit-Framework=<br /> <br /> Um die oben genannte Probleme zu lösen, wurden neue Konzepte entwickelt, dessen technische Implementierung eine neue Plattform bildet, die Sitekit-Framework genannt wird.<br /> <br /> Ein grundsätzliches Problem war, das Templates über Textarea-Felder in der Datenbank gespeichert werden. Templates sollen Dateien sein. Templates eines Projektes sollen in einem kundenspezifischen Modul zusammengefasst werden. Auch JavaScript, CSS, Fonts, Bilder und PHP-Dateien liegen in diesem Modul. Diese Module werden über ein GIT-Repository versioniert. Das Modul kann mit einer IDE bearbeitet werden. Auf jedem Arbeitsplatz existiert eine IES-Installation und die Arbeit an Templates kann lokal auf dem eigenen Entwicklungs-Rechner erfolgen. <br /> <br /> Damit können folgende Probleme gelöst werden:<br /> <br /> ;Template-Bearbeitung im Textarea-Feld: wird nicht mehr benötigt. Bearbeitung erfolgt über eine IDE.<br /> ;Kollaboratives Arbeiten im Projekt: Jeder entwickelt auf seinem eigenen System und über GIT werden alle Änderungen zusammengeführt.<br /> ;Übertragung des Entwicklungsstandes vom Aufbau- zum Live-System: Die Entwicklungsarbeiten werden in einem Kunden-Modul zusammengefasst und können als eine Module-Datei (war-Datei, ZIP-Format) auf das Aufbau- und Live-System gespielt werden.<br /> <br /> <br /> Wenn es keine Templates in der Datenbank mehr gibt, dann gibt es auch keine Template-Pools mehr. Template-Pools sind aber notwendig, um Artikel-Pools zu konfigurieren, damit bestimmt werden kann, mit welchen Templates Artikel angelegt werden können. Weiter wurde über Template-Pools bestimmt, welche Abschnitte für einen bestimmten Artikel-Typ ausgewählt werden dürfen. Daher wurde hier eine Alternative geschaffen.<br /> <br /> Es gibt nun Group-Types (Artikel-Pool-Typen), Objects-Types (Artikel-Typen), Steps und Sections (Abschnitte)<br /> <br /> [[Datei:Sitekit-Types-Steps-Sections.png|Sitekit Typen, Steps und Abschnitte|center|frame|800px]]<br /> <br /> Ein Objekt-Type ist ein Seiten-Typ. Dieser kann z.B. eine Homepage, eine Rubrik-Seite, eine Inhalts-Seite oder irgend eine spezialisierte Seite sein. Je nach Object-Type existieren unterschiedliche Ein- und Ausgaben. Ein Group-Type definiert eine bestimmte Art von Artikel-Pool. Über den Group-Typ wird fest gelegt, welche Objekt-Typen in Artikel-Pools eines bestimmen Group-Typs angelegt werden können. Die Bearbeitung eines Artikels ist in einzelne Schritte (Steps) unterteilt. In jedem Step gibt es verschiedene Abschnitte, in der die Teile der Eingabe-Masken strukturiert sind. Objekt-Typen definieren welche Steps verwendet werden. Steps definieren welche Abschnitte verwendet werden.<br /> <br /> <br /> Ein weiteres, grundsätzliches Problem ist die Vermischung von Daten, Logik und Darstellung. Die PHP-Seiten, die mit bisherigen Templates generiert wurden, enthielten Daten, Logik und HTML-Code an den Stellen, wo sie gerade benötigt wurden. Alles sehr vermischt in einer PHP-Datei.<br /> <br /> ;Daten (Raw-Content):<br /> Templates des SiteKit generieren nur noch die Daten in die PHP-Datei. Daher bezeichnen wir die Ausgabe-Templates des SiteKit als Aggregatoren. Zur Generierungszeit werden über die Aggregatoren die Daten so aufbereitet und angereichert, dass sie für die Darstellung gut geeignet sind. Diese Aufbereitung erfolg Ausgabe-Neutral, so dass aus den Daten nicht nur HTML, sondern auch andere Formate wie XML oder JSON erzeugt werden können. Mit diesem Ansatz wird aus Infosite ein Headless CMS. Durch dieses Vorgehen profitiert z.B auch die Suche. Bisher konnten in einem Suchergebnis nur die Daten dargestellt werden die im Suchindex enthalten waren. Jetzt ist es möglich ggf. die gesamten Daten eines Artikels für die Darstellung eines Suchergebnisses nachzuladen.<br /> <br /> ;Logik:<br /> Die Logik wird in Komponenten abgelegt. Komponenten sind Teilbereiche einer Webseite. Die gesamte Webseite wird in einzelne Komponenten zerlegt, die auch ineinander verschachtelt sein können. Viele Komponenten habe keine Logik, dann dienen sie nur als Platzhalter für die Darstellung. Komponenten wie z.B. die Suche enthalten aber auch Logik. Das SiteKit sorgt dafür das zunächst die Logik der Komponenten ausgeführt wird. Ist die gesamte Logik ausgeführt, kann die Webseite dargestellt werden.<br /> <br /> ;Ausgabe:<br /> Für jede Komponente existiert ein Renderer. Dieser erzeugt das HTML (oder ein anderes Ausgabeformat) für die Komponenten.<br /> <br /> ;Styling<br /> Auf Basis des HTML, das die Renderer erzeugen können Styles definiert werden um die gewünschte Darstellung zu erreichen. <br /> <br /> So sind Daten, Logik und Darstellung in Aggregatoren, Komponenten und Renderer aufgeteilt.<br /> <br /> <br /> Auf Basis dieser Technik werden von Sitepark Komponenten entwickelt, die in den Kunden-Projekten eingesetzt werden können. Ziel ist es die Komponenten konfigurativ so anpassen zu können das sie den individuellen Anforderungen der Projekte genügen. Sollte das nicht ausreichen, können kundenspezifische Komponenten erzeugt werden.<br /> <br /> <br /> Mit den oben beschriebenen Mitteln sollen folgende Probleme gelöst werden.<br /> <br /> ;Änderungen an Templates hat oft das Generieren der gesamten Site zur Folge: Die Seiten müssen nur noch generiert werden, wenn sich die Aggregatoren ändern. Bei Änderungen an der Logik oder an der Darstellung ist kein neu-generieren mehr notwendig.<br /> <br /> ;Produkt-Features werden im Kunden-System implementiert: Es gibt keinen Master-System mehr. Produkterweiterungen, die sich aus dem Projekt ergeben werden während des Projektes in das Produkt-Modul integriert und auch direkt verwendet.<br /> <br /> ;Template-Code wird schnell unübersichtlich: Auf Zeilenumbrüche muss keine Rücksicht mehr genommen werden, da Aggregatoren nur Maps und Collections füllen und keine Ausgabe erzeugen. Durch die Trennung von Daten, Logik und Ausgabe sind auch die verschiedenen Technologien SMPL, PHP, JavaScript und CSS getrennt und nicht mehr in einer Datei enthalten. <br /> <br /> ;Templates sind nicht updatefähig: Produkt- und Kunden-Anpassungen werden strickt getrennt. Produkte werden abwärts-kompatibel gehalten und sind damit updatefähig.<br /> <br /> ;Keine einheitliche Basis für Module: Das SiteKit liefert eine stabile Basis für Module.<br /> <br /> ==Enthaltene Funktionen und Komponenten==<br /> Im SiteKit enthalten sind Funktionen und Komponenten die Sitepark als &quot;Standard&quot; definiert hat, da sie in den meisten Projekten Verwendung finden.<br /> <br /> Alle von SiteKit bereit gestellten Komponenten sind barrierefrei und responsive.<br /> <br /> ===Generelle Funktionen===<br /> <br /> ;Navigation: Komplettes Navigations-Konzept mit verschiedenen Features wie Vererbbarkeit von Eigenschaften durch die Navigations-Struktur (z.B. Rubrik-Farbe), Mehrfachverknüpfung von Artikeln in der Navigation, geeignet für große Sites (100.000 Seiten und mehr), beliebige Navigations-Tiefe, JavaScript-basierte Mobile-fähige Navigation mit Offline-Caching.<br /> <br /> ;Suche: Voll integrierte Volltext Suche auf Basis von Solr mit Suggest, erweiterten Suchoptionen, Facettierung, unterstützt geschützte Seiten, bietet Ad-Hoc-Indizierung getriggert durch das Speichern eines Artikels, liefert Werkzeuge zur Analyse des Volltext-Index z.B. zum debuggen.<br /> <br /> ;Fehlerseiten: Redaktionell pflegbare Fehlerseiten für HTTP-Fehler (404 - Datei oder Verzeichnis nicht gefunden, ...)<br /> <br /> ;Favicons: Verwaltung der Favicons<br /> <br /> ;Geolokation: Definition von GEO-Koordinaten an Artikel. Volle Integration in die Suche für Z.B. Umkreissuchen.<br /> <br /> ;Kategorisierung: Kategorie-System zur Kategorisierung von Artikeln mit voller Integration in die Suche für z.B. Facetierung.<br /> <br /> ;Teaser: Teaser-System zur Verwendung von Teasern in verschiedenen Kontexten wie: Navigation, Teaser-Listen, Slider, Karten-Marker-Info-Boxen, Suchergebnisse, Kachelsystem. Zeitsteuerung<br /> <br /> ;Kurzadressen: Definition von Kurz-Urls<br /> <br /> ;Microsites: Microsite-System zur Erstellung von untergeordneten Sites unter eigener Domain mit geteiltem, aber Theming-fähigem Design.<br /> <br /> ;Mehrsprachigkeit (Website): Alle nicht-redaktionellen Inhalte, die auf der Webseite dargestellt werden, können über Sprachpakete in andere Sprachen übersetzt werden. Für die deutsche Sprache wird ein Sprachpaket mitgeliefert das auch nach Kundenwunsch angepasst werden kann.<br /> <br /> =Whitelabel=<br /> <br /> Damit neue Projekte nicht von Null begonnen werden müssen, wurden das Whitelabel-Modul erstellt. In diesem Modul sind immer die aktuellen Techniken zur Umsetzung von neuen Projekten enthalten. Dieses Modul dient als Kopiervorlage. Es wird immer auf die aktuellen Anforderungen von neuen Projekten angepasst. Hier wird keine Rücksicht auf Updatefähigkeit genommen.<br /> <br /> Das SiteKit soll die Technik enthalten die Projekt-übergreifend verwendet wird. Sitepark sorgt dafür, dass das SiteKit-Modul update-fähig ist und somit als langfristige Plattform für Projekt- und Produkt-Module verwendet werden kann.<br /> <br /> Besonders im Front-End-Bereich (CSS, JavaScript) werden etablierte Techniken schneller von neueren Techniken überholt. In diesem Bereich wäre eine langfristige update-Fähigkeit eine große Innovations-Bremse. Daher ist ein großer Teil der Front-End-Technik nicht im Sitekit-Modul, sondern im Whitelabel-Modul enthalten.<br /> <br /> Das Whitelabel-Modul besteht aus zwei Unter-Modulen<br /> <br /> ;IES-Modul:<br /> Das IES Modul enthält Eingabe-Templates, Aggregatoren, Komponenten, Renderer und Basis-Konfigurationen<br /> ;Styleguide:<br /> In diesem Modul ist ein Styleguide enthalten in dem das HTML hinterlegt ist, dass auch die Renderer erzeugen. Alle Komponenten sind nach dem Atomic-Design-Prinzip in Atome, Moleküle, Organismen und Templates erlegt und können so gestylt werden.<br /> <br /> =Kundenmodul=<br /> <br /> Ein Kundenmodul wird als Kopie von Whitelabel erzeugt. In diesem Modul werden alle Kundenspezifischen Anforderungen implementiert.<br /> <br /> =Systemarchitektur (vereinfacht)=<br /> <br /> SiteKit und Infosite6 zusammen bilden &quot;Infosite 6 Enterprise-Edition&quot; (Infosite 6 EE)<br /> <br /> <br /> [[Datei:InfoSite6-EE-Systemarchitektur-vereinfacht.png|800px]]<br /> <br /> Die '''CMS-Oberfläche''' stellt die Eingabemaken dar, die sich aus einzelnen Abschnitten zusammensetzen. Das SiteKit stellt diese Abschnitte bereit. Das Kunden-Modul enthält kundenspezifische Konfigurationen der SiteKit-Abschnitte und kundenspezifische Abschnitte.<br /> <br /> Das '''IES Repository''' hält die Artikel-Daten, die über die CMS-Oberfläche dargestellt und bearbeitet werden können.<br /> <br /> Der '''Raw Content''' wird pro Artikel als PHP-Datei vom CMS auf dem Webserver publiziert. Die Daten werden über Sitekit- und Kundenspezifischen-Aggregatoren aus dem IES Repository geladen und in einer für die Darstellung optimierten Form zusammengestellt.<br /> <br /> Die '''Renderer''' erzeugen beim Aufruf einer Seite aus dem Raw Content das gewünschte Ausgabeformat. Das SiteKit stellt Renderer zur Verfügung die kundenspezifisch angepasst werden können. Kunden-Module stellen auch eigene Renderer bereit.<br /> <br /> Mit Hilfe eines Styleguide werden für das Styling der Webseite '''CSS''' und '''JavaScript''' implementiert.</div>

Liebold https://wiki.sitepark.com/index.php?title=Infosite_6_Enterprise_Edition&diff=8467 2017-07-13T11:29:08Z

<p>Liebold: /* Sitekit-Framework */</p> <hr /> <div>=Motivation=<br /> <br /> Bevor die Technik für die 'Infosite 6 Enterprise Edition' zur Verfügung stand, sind Projekte mit 'alten' Methoden aufgebaut worden. Hier sollen die alten Methoden kurz beschrieben werden um den Bedarf dieser Neukonzeption nachvollziehen zu können.<br /> <br /> Templates für den Aufbau einer Webseite werden in der Datenbank eines IES-Mandanten gespeichert.<br /> Sie werden verwenden um Eingabe-Masken für das CMS zu erzeugen und Ausgaben für die Webseite. Die durch die Ausgabe-Templates generierten Dateien enthalten in der Regel PHP-, HTML-, JavaScript- und CSS-Code, der auf die Anforderungen der Webseite angepasst ist.<br /> <br /> Bearbeitet wurden die Templates im Browser über ein Textarea-Feld im Template-Editor. Dieser Template-Editor ist Teil von Infosite.<br /> <br /> Zusätzlich zu den Templates werden bei diesem Vorgen noch JavaScripte, CSS, PHP-Klassen und ggf. Bilder benötigt die als Artikel und Medien-Artikel im Mandanten gespeichert sind.<br /> <br /> Für neuen Projekte hat Sitepark ein Master-System das als Vorlage dient. Das Master-System wird einmalig in das Kunden-System kopiert.<br /> <br /> <br /> Dieses Vorgehen hatte einige Probleme zur Folge. Diese waren z.B.<br /> <br /> ;Template-Bearbeitung im Textarea-Feld: Die Bearbeitung der Templates muss Systembedingt in einem Textarea-Feld erfolgen. Durch den Template-Editor steht zwar z.B. ein Syntax-Highlighting zur Verfügung, es fehlt aber der Funktionsumfang eines Text-Editors. Um den Funktions-Umfang eines Editors nutzen zu können, muss das Template in einen Text-Editor kopiert werden. Nach der Bearbeitung muss es wieder in das Textarea-Feld kopiert werden.<br /> <br /> ;Kollaboratives Arbeiten im Projekt: Es ist nicht möglich parallel an einem Template zu arbeiten. Besonders problematisch bei zentralen Templates wie z.b. 'PHP-Head'<br /> <br /> ;Übertragung des Entwicklungsstandes vom Aufbau- zum Live-System: Auf dem Aufbau-System werden Templates entwickelt, so wie JavaScripte und CSS erzeugt. Diese müssen in regelmäßigen Abständen auf des Live-System gespielt werden. Hier nutzen wir XIP um die notwendigen Daten zu exportieren und auf dem Live-System wieder zu importieren. Bei diesem Verfahren muss bekannt sein welche Templates und Ressourcen übertragen werden dürfen und welche noch in der Entwicklung sind. Dies zu verwalten ist sehr aufwendig und Fehler-trächtig.<br /> <br /> ;Änderungen an Templates hat oft das Generieren der gesamten Site zur Folge: Änderungen am Ausgabeteil eines Templates wirken sich erst aus, wenn die Artikel, die dieses Template verwenden neu generiert werden. Häufig ist es der Fall, dass dann die gesamte Website neu generiert werden muss. Da dies bei großen Websites mehrere Stunden in Anspruch nehmen kann, blockiert das den Entwicklungs-Prozess.<br /> <br /> ;Produkt-Features werden im Kunden-System implementiert: Da die Entwicklung immer im Kunden-System und nicht im Master-System erfolgt, werden hier auch Funktionen implementiert, die in das Master-System zurück fließen müssen. Da die Templates sich durch kundenspezifische Anpassungen von dem Templates im Master-System unterscheiden kann nicht das gesamte Template übernommen werden. Es müssen im Prinzip Zeilenweise die Code-Stellen in das Master-System übertragen werden. Bei parallel laufenden Projekten, die die Funktionalität ebenfalls nutzen möchten, müssen diese Code-Stellen auch noch in das andere Kunden-Projekt übertragen werden.<br /> <br /> ;Template-Code wird schnell unübersichtlich: Bei Templates die eine Ausgabe erzeugen, möchte man möglichst unnötige Zeilenumbrüche vermeiden, die durch die Verwendung von SP-Tags entstehen. Daher werden oft Zeilenumbrüche in Kommentare gefasst oder ganz auf Zeilenumbrüche bei SP-Tags verzichtet. Weiter ist SPML-Logik mit PHP-Logik vermischt. Dadurch können Templates schnell unübersichtlich werden.<br /> <br /> ;Templates sind nicht updatefähig: Das Master-System dient nur als Kopiervorlage für Projekte. Die Templates werden nach den kundenspezifischen Anforderungen angepasst. Dadurch sind sie nicht mehr updatefähig. Neue Funktionalitäten können nur mit Aufwand in Bestands-Systeme integriert werden, da hier auch die einzelnen Code-Stellen einzeln in die Templates übertragen werden muss.<br /> <br /> ;Keine einheitliche Basis für Module: Module wie Veranstaltungskalender, Verzeichnis-Modul, Voting-Modul, Shop-Module, ... werden für einen bestimmten Stand des Master-System entwickelt. Das Master-System entwickelt sich mit jedem Projekt weiter, ohne aber eine einheitliche Basis sicherzustellen. Dies hat zur Folge das Module auf jedes System angepasst werden müssen, und nicht einfach installierbar sind.<br /> <br /> =Sitekit-Framework=<br /> <br /> Um die oben genannte Probleme zu lösen, wurden neue Konzepte entwickelt, dessen technische Implementierung eine neue Plattform bildet, die Sitekit-Framework genannt wird.<br /> <br /> Ein grundsätzliches Problem war, das Templates über Textarea-Felder in der Datenbank gespeichert werden. Templates sollen Dateien sein. Templates eines Projektes sollen in einem kundenspezifischen Modul zusammengefasst werden. Auch JavaScript, CSS, Fonts, Bilder und PHP-Dateien liegen in diesem Modul. Diese Module werden über ein GIT-Repository versioniert. Das Modul kann mit einer IDE bearbeitet werden. Auf jedem Arbeitsplatz existiert eine IES-Installation und die Arbeit an Templates kann lokal auf dem eigenen Entwicklungs-Rechner erfolgen. <br /> <br /> Damit können folgende Probleme gelöst werden:<br /> <br /> ;Template-Bearbeitung im Textarea-Feld: wird nicht mehr benötigt. Bearbeitung erfolgt über eine IDE.<br /> ;Kollaboratives Arbeiten im Projekt: Jeder entwickelt auf seinem eigenen System und über GIT werden alle Änderungen zusammengeführt.<br /> ;Übertragung des Entwicklungsstandes vom Aufbau- zum Live-System: Die Entwicklungsarbeiten werden in einem Kunden-Modul zusammengefasst und können als eine Module-Datei (war-Datei, ZIP-Format) auf das Aufbau- und Live-System gespielt werden.<br /> <br /> <br /> Wenn es keine Templates in der Datenbank mehr gibt, dann gibt es auch keine Template-Pools mehr. Template-Pools sind aber notwendig, um Artikel-Pools zu konfigurieren, damit bestimmt werden kann, mit welchen Templates Artikel angelegt werden können. Weiter wurde über Template-Pools bestimmt, welche Abschnitte für einen bestimmten Artikel-Typ ausgewählt werden dürfen. Daher wurde hier eine alternative geschaffen.<br /> <br /> Es gibt nun Group-Types (Artikel-Pool-Typen), Objects-Types (Artikel-Typen), Steps und Sections (Abschnitte)<br /> <br /> [[Datei:Sitekit-Types-Steps-Sections.png|Sitekit Typen, Steps und Abschnitte|center|frame|800px]]<br /> <br /> Ein Objekt-Type ist ein Seiten-Typ. Dieser kann z.B. eine Homepage, eine Rubrik-Seite, eine Inhalts-Seite oder irgend eine spezialisierte Seite sein. Je nach Object-Type existieren unterschiedliche Ein- und Ausgaben. Ein Group-Type definiert eine bestimmte Art von Artikel-Pool. Über den Group-Typ wird fest gelegt, welche Objekt-Typen in Artikel-Pools eines bestimmen Group-Typs angelegt werden können. Die Bearbeitung eines Artikels ist in einzelne Schritte (Steps) unterteilt. In jedem Step gibt es verschiedene Abschnitte, in der die Teile der Eingabe-Masken strukturiert sind. Objekt-Typen definieren welche Steps verwendet werden. Steps definieren welche Abschnitte verwendet werden.<br /> <br /> <br /> Ein weiteres, grundsätzliches Problem ist die Vermischung von Daten, Logik und Darstellung. Die PHP-Seiten, die mit bisherigen Templates generiert wurden, enthielten Daten, Logik und HTML-Code an den Stellen, wo sie gerade benötigt wurden. Alles sehr vermischt in einer PHP-Datei.<br /> <br /> ;Daten (Raw-Content):<br /> Templates des SiteKit generieren nur noch die Daten in die PHP-Datei. Daher bezeichnen wir die Ausgabe-Templates des SiteKit als Aggregatoren. Zur Generierungszeit werden über die Aggregatoren die Daten so aufbereitet und angereichert, dass sie für die Darstellung gut geeignet sind. Diese Aufbereitung erfolg Ausgabe-Neutral, so dass aus den Daten nicht nur HTML, sondern auch andere Formate wie XML oder JSON erzeugt werden können. Mit diesem Ansatz wird aus Infosite ein Headless CMS. Durch dieses Vorgehen profitiert z.B auch die Suche. Bisher konnten in einem Suchergebnis nur die Daten dargestellt werden die im Suchindex enthalten waren. Jetzt ist es möglich ggf. die gesamten Daten eines Artikels für die Darstellung eines Suchergebnisses nachzuladen.<br /> <br /> ;Logik:<br /> Die Logik wird in Komponenten abgelegt. Komponenten sind Teilbereiche einer Webseite. Die gesamte Webseite wird in einzelne Komponenten zerlegt, die auch ineinander verschachtelt sein können. Viele Komponenten habe keine Logik, dann dienen sie nur als Platzhalter für die Darstellung. Komponenten wie z.B. die Suche enthalten aber auch Logik. Das SiteKit sorgt dafür das zunächst die Logik der Komponenten ausgeführt wird. Ist die gesamte Logik ausgeführt, kann die Webseite dargestellt werden.<br /> <br /> ;Ausgabe:<br /> Für jede Komponente existiert ein Renderer. Dieser erzeugt das HTML (oder ein anderes Ausgabeformat) für die Komponenten.<br /> <br /> ;Styling<br /> Auf Basis des HTML, das die Renderer erzeugen können Styles definiert werden um die gewünschte Darstellung zu erreichen. <br /> <br /> So sind Daten, Logik und Darstellung in Aggregatoren, Komponenten und Renderer aufgeteilt.<br /> <br /> <br /> Auf Basis dieser Technik werden von Sitepark Komponenten entwickelt, die in den Kunden-Projekten eingesetzt werden können. Ziel ist es die Komponenten konfigurativ so anpassen zu können das sie den individuellen Anforderungen der Projekte genügen. Sollte das nicht ausreichen, können kundenspezifische Komponenten erzeugt werden.<br /> <br /> <br /> Mit den oben beschriebenen Mitteln sollen folgende Probleme gelöst werden.<br /> <br /> ;Änderungen an Templates hat oft das Generieren der gesamten Site zur Folge: Die Seiten müssen nur noch generiert werden, wenn sich die Aggregatoren ändern. Bei Änderungen an der Logik oder an der Darstellung ist kein neu-generieren mehr notwendig.<br /> <br /> ;Produkt-Features werden im Kunden-System implementiert: Es gibt keinen Master-System mehr. Produkterweiterungen, die sich aus dem Projekt ergeben werden während des Projektes in das Produkt-Modul integriert und auch direkt verwendet.<br /> <br /> ;Template-Code wird schnell unübersichtlich: Auf Zeilenumbrüche muss keine Rücksicht mehr genommen werden, da Aggregatoren nur Maps und Collections füllen und keine Ausgabe erzeugen. Durch die Trennung von Daten, Logik und Ausgabe sind auch die verschiedenen Technologien SMPL, PHP, JavaScript und CSS getrennt und nicht mehr in einer Datei enthalten. <br /> <br /> ;Templates sind nicht updatefähig: Produkt- und Kunden-Anpassungen werden strickt getrennt. Produkte werden abwärts-kompatibel gehalten und sind damit updatefähig.<br /> <br /> ;Keine einheitliche Basis für Module: Das SiteKit liefert eine stabile Basis für Module.<br /> <br /> ==Enthaltene Funktionen und Komponenten==<br /> Im SiteKit enthalten sind Funktionen und Komponenten die Sitepark als &quot;Standard&quot; definiert hat, da sie in den meisten Projekten Verwendung finden.<br /> <br /> Alle von SiteKit bereit gestellten Komponenten sind barrierefrei und responsive.<br /> <br /> ===Generelle Funktionen===<br /> <br /> ;Navigation: Komplettes Navigations-Konzept mit verschiedenen Features wie Vererbbarkeit von Eigenschaften durch die Navigations-Struktur (z.B. Rubrik-Farbe), Mehrfachverknüpfung von Artikeln in der Navigation, geeignet für große Sites (100.000 Seiten und mehr), beliebige Navigations-Tiefe, JavaScript-basierte Mobile-fähige Navigation mit Offline-Caching.<br /> <br /> ;Suche: Voll integrierte Volltext Suche auf Basis von Solr mit Suggest, erweiterten Suchoptionen, Facettierung, unterstützt geschützte Seiten, bietet Ad-Hoc-Indizierung getriggert durch das Speichern eines Artikels, liefert Werkzeuge zur Analyse des Volltext-Index z.B. zum debuggen.<br /> <br /> ;Fehlerseiten: Redaktionell pflegbare Fehlerseiten für HTTP-Fehler (404 - Datei oder Verzeichnis nicht gefunden, ...)<br /> <br /> ;Favicons: Verwaltung der Favicons<br /> <br /> ;Geolokation: Definition von GEO-Koordinaten an Artikel. Volle Integration in die Suche für Z.B. Umkreissuchen.<br /> <br /> ;Kategorisierung: Kategorie-System zur Kategorisierung von Artikeln mit voller Integration in die Suche für z.B. Facetierung.<br /> <br /> ;Teaser: Teaser-System zur Verwendung von Teasern in verschiedenen Kontexten wie: Navigation, Teaser-Listen, Slider, Karten-Marker-Info-Boxen, Suchergebnisse, Kachelsystem. Zeitsteuerung<br /> <br /> ;Kurzadressen: Definition von Kurz-Urls<br /> <br /> ;Microsites: Microsite-System zur Erstellung von untergeordneten Sites unter eigener Domain mit geteiltem, aber Theming-fähigem Design.<br /> <br /> ;Mehrsprachigkeit (Website): Alle nicht-redaktionellen Inhalte, die auf der Webseite dargestellt werden, können über Sprachpakete in andere Sprachen übersetzt werden. Für die deutsche Sprache wird ein Sprachpaket mitgeliefert das auch nach Kundenwunsch angepasst werden kann.<br /> <br /> =Whitelabel=<br /> <br /> Damit neue Projekte nicht von Null begonnen werden müssen, wurden das Whitelabel-Modul erstellt. In diesem Modul sind immer die aktuellen Techniken zur Umsetzung von neuen Projekten enthalten. Dieses Modul dient als Kopiervorlage. Es wird immer auf die aktuellen Anforderungen von neuen Projekten angepasst. Hier wird keine Rücksicht auf Updatefähigkeit genommen.<br /> <br /> Das SiteKit soll die Technik enthalten die Projekt-übergreifend verwendet wird. Sitepark sorgt dafür, dass das SiteKit-Modul update-fähig ist und somit als langfristige Plattform für Projekt- und Produkt-Module verwendet werden kann.<br /> <br /> Besonders im Front-End-Bereich (CSS, JavaScript) werden etablierte Techniken schneller von neueren Techniken überholt. In diesem Bereich wäre eine langfristige update-Fähigkeit eine große Innovations-Bremse. Daher ist ein großer Teil der Front-End-Technik nicht im Sitekit-Modul, sondern im Whitelabel-Modul enthalten.<br /> <br /> Das Whitelabel-Modul besteht aus zwei Unter-Modulen<br /> <br /> ;IES-Modul:<br /> Das IES Modul enthält Eingabe-Templates, Aggregatoren, Komponenten, Renderer und Basis-Konfigurationen<br /> ;Styleguide:<br /> In diesem Modul ist ein Styleguide enthalten in dem das HTML hinterlegt ist, dass auch die Renderer erzeugen. Alle Komponenten sind nach dem Atomic-Design-Prinzip in Atome, Moleküle, Organismen und Templates erlegt und können so gestylt werden.<br /> <br /> =Kundenmodul=<br /> <br /> Ein Kundenmodul wird als Kopie von Whitelabel erzeugt. In diesem Modul werden alle Kundenspezifischen Anforderungen implementiert.<br /> <br /> =Systemarchitektur (vereinfacht)=<br /> <br /> SiteKit und Infosite6 zusammen bilden &quot;Infosite 6 Enterprise-Edition&quot; (Infosite 6 EE)<br /> <br /> <br /> [[Datei:InfoSite6-EE-Systemarchitektur-vereinfacht.png|800px]]<br /> <br /> Die '''CMS-Oberfläche''' stellt die Eingabemaken dar, die sich aus einzelnen Abschnitten zusammensetzen. Das SiteKit stellt diese Abschnitte bereit. Das Kunden-Modul enthält kundenspezifische Konfigurationen der SiteKit-Abschnitte und kundenspezifische Abschnitte.<br /> <br /> Das '''IES Repository''' hält die Artikel-Daten, die über die CMS-Oberfläche dargestellt und bearbeitet werden können.<br /> <br /> Der '''Raw Content''' wird pro Artikel als PHP-Datei vom CMS auf dem Webserver publiziert. Die Daten werden über Sitekit- und Kundenspezifischen-Aggregatoren aus dem IES Repository geladen und in einer für die Darstellung optimierten Form zusammengestellt.<br /> <br /> Die '''Renderer''' erzeugen beim Aufruf einer Seite aus dem Raw Content das gewünschte Ausgabeformat. Das SiteKit stellt Renderer zur Verfügung die kundenspezifisch angepasst werden können. Kunden-Module stellen auch eigene Renderer bereit.<br /> <br /> Mit Hilfe eines Styleguide werden für das Styling der Webseite '''CSS''' und '''JavaScript''' implementiert.</div>

Liebold https://wiki.sitepark.com/index.php?title=Infosite_6_Enterprise_Edition&diff=8466 2017-07-13T11:28:28Z

<p>Liebold: /* Sitekit-Framework */</p> <hr /> <div>=Motivation=<br /> <br /> Bevor die Technik für die 'Infosite 6 Enterprise Edition' zur Verfügung stand, sind Projekte mit 'alten' Methoden aufgebaut worden. Hier sollen die alten Methoden kurz beschrieben werden um den Bedarf dieser Neukonzeption nachvollziehen zu können.<br /> <br /> Templates für den Aufbau einer Webseite werden in der Datenbank eines IES-Mandanten gespeichert.<br /> Sie werden verwenden um Eingabe-Masken für das CMS zu erzeugen und Ausgaben für die Webseite. Die durch die Ausgabe-Templates generierten Dateien enthalten in der Regel PHP-, HTML-, JavaScript- und CSS-Code, der auf die Anforderungen der Webseite angepasst ist.<br /> <br /> Bearbeitet wurden die Templates im Browser über ein Textarea-Feld im Template-Editor. Dieser Template-Editor ist Teil von Infosite.<br /> <br /> Zusätzlich zu den Templates werden bei diesem Vorgen noch JavaScripte, CSS, PHP-Klassen und ggf. Bilder benötigt die als Artikel und Medien-Artikel im Mandanten gespeichert sind.<br /> <br /> Für neuen Projekte hat Sitepark ein Master-System das als Vorlage dient. Das Master-System wird einmalig in das Kunden-System kopiert.<br /> <br /> <br /> Dieses Vorgehen hatte einige Probleme zur Folge. Diese waren z.B.<br /> <br /> ;Template-Bearbeitung im Textarea-Feld: Die Bearbeitung der Templates muss Systembedingt in einem Textarea-Feld erfolgen. Durch den Template-Editor steht zwar z.B. ein Syntax-Highlighting zur Verfügung, es fehlt aber der Funktionsumfang eines Text-Editors. Um den Funktions-Umfang eines Editors nutzen zu können, muss das Template in einen Text-Editor kopiert werden. Nach der Bearbeitung muss es wieder in das Textarea-Feld kopiert werden.<br /> <br /> ;Kollaboratives Arbeiten im Projekt: Es ist nicht möglich parallel an einem Template zu arbeiten. Besonders problematisch bei zentralen Templates wie z.b. 'PHP-Head'<br /> <br /> ;Übertragung des Entwicklungsstandes vom Aufbau- zum Live-System: Auf dem Aufbau-System werden Templates entwickelt, so wie JavaScripte und CSS erzeugt. Diese müssen in regelmäßigen Abständen auf des Live-System gespielt werden. Hier nutzen wir XIP um die notwendigen Daten zu exportieren und auf dem Live-System wieder zu importieren. Bei diesem Verfahren muss bekannt sein welche Templates und Ressourcen übertragen werden dürfen und welche noch in der Entwicklung sind. Dies zu verwalten ist sehr aufwendig und Fehler-trächtig.<br /> <br /> ;Änderungen an Templates hat oft das Generieren der gesamten Site zur Folge: Änderungen am Ausgabeteil eines Templates wirken sich erst aus, wenn die Artikel, die dieses Template verwenden neu generiert werden. Häufig ist es der Fall, dass dann die gesamte Website neu generiert werden muss. Da dies bei großen Websites mehrere Stunden in Anspruch nehmen kann, blockiert das den Entwicklungs-Prozess.<br /> <br /> ;Produkt-Features werden im Kunden-System implementiert: Da die Entwicklung immer im Kunden-System und nicht im Master-System erfolgt, werden hier auch Funktionen implementiert, die in das Master-System zurück fließen müssen. Da die Templates sich durch kundenspezifische Anpassungen von dem Templates im Master-System unterscheiden kann nicht das gesamte Template übernommen werden. Es müssen im Prinzip Zeilenweise die Code-Stellen in das Master-System übertragen werden. Bei parallel laufenden Projekten, die die Funktionalität ebenfalls nutzen möchten, müssen diese Code-Stellen auch noch in das andere Kunden-Projekt übertragen werden.<br /> <br /> ;Template-Code wird schnell unübersichtlich: Bei Templates die eine Ausgabe erzeugen, möchte man möglichst unnötige Zeilenumbrüche vermeiden, die durch die Verwendung von SP-Tags entstehen. Daher werden oft Zeilenumbrüche in Kommentare gefasst oder ganz auf Zeilenumbrüche bei SP-Tags verzichtet. Weiter ist SPML-Logik mit PHP-Logik vermischt. Dadurch können Templates schnell unübersichtlich werden.<br /> <br /> ;Templates sind nicht updatefähig: Das Master-System dient nur als Kopiervorlage für Projekte. Die Templates werden nach den kundenspezifischen Anforderungen angepasst. Dadurch sind sie nicht mehr updatefähig. Neue Funktionalitäten können nur mit Aufwand in Bestands-Systeme integriert werden, da hier auch die einzelnen Code-Stellen einzeln in die Templates übertragen werden muss.<br /> <br /> ;Keine einheitliche Basis für Module: Module wie Veranstaltungskalender, Verzeichnis-Modul, Voting-Modul, Shop-Module, ... werden für einen bestimmten Stand des Master-System entwickelt. Das Master-System entwickelt sich mit jedem Projekt weiter, ohne aber eine einheitliche Basis sicherzustellen. Dies hat zur Folge das Module auf jedes System angepasst werden müssen, und nicht einfach installierbar sind.<br /> <br /> =Sitekit-Framework=<br /> <br /> Um die oben genannte Probleme zu lösen, wurden neue Konzepte entwickelt, dessen technische Implementierung eine neue Plattform bildet, die Sitekit-Framework genannt wird.<br /> <br /> Ein grundsätzliches Problem war, das Templates über Textarea-Felder in der Datenbank gespeichert werden. Templates sollen Dateien sein. Templates eines Projektes sollen in einem kundenspezifischen Modul zusammengefasst werden. Auch JavaScript, CSS, Fonts, Bilder und PHP-Dateien liegen in diesem Modul. Diese Module werden über ein GIT-Repository versioniert. Das Modul kann mit einer IDE bearbeitet werden. Auf jedem Arbeitsplatz existiert eine IES-Installation und die Arbeit an Templates kann lokal auf dem eigenen Entwicklungs-Rechner erfolgen. Damit können folgende Probleme gelöst werden:<br /> <br /> ;Template-Bearbeitung im Textarea-Feld: wird nicht mehr benötigt. Bearbeitung erfolgt über eine IDE.<br /> ;Kollaboratives Arbeiten im Projekt: Jeder entwickelt auf seinem eigenen System und über GIT werden alle Änderungen zusammengeführt.<br /> ;Übertragung des Entwicklungsstandes vom Aufbau- zum Live-System: Die Entwicklungsarbeiten werden in einem Kunden-Modul zusammengefasst und können als eine Module-Datei (war-Datei, ZIP-Format) auf das Aufbau- und Live-System gespielt werden.<br /> <br /> <br /> Wenn es keine Templates in der Datenbank mehr gibt, dann gibt es auch keine Template-Pools mehr. Template-Pools sind aber notwendig, um Artikel-Pools zu konfigurieren, damit bestimmt werden kann, mit welchen Templates Artikel angelegt werden können. Weiter wurde über Template-Pools bestimmt, welche Abschnitte für einen bestimmten Artikel-Typ ausgewählt werden dürfen. Daher wurde hier eine alternative geschaffen.<br /> <br /> Es gibt nun Group-Types (Artikel-Pool-Typen), Objects-Types (Artikel-Typen), Steps und Sections (Abschnitte)<br /> <br /> [[Datei:Sitekit-Types-Steps-Sections.png|Sitekit Typen, Steps und Abschnitte|center|frame|800px]]<br /> <br /> Ein Objekt-Type ist ein Seiten-Typ. Dieser kann z.B. eine Homepage, eine Rubrik-Seite, eine Inhalts-Seite oder irgend eine spezialisierte Seite sein. Je nach Object-Type existieren unterschiedliche Ein- und Ausgaben. Ein Group-Type definiert eine bestimmte Art von Artikel-Pool. Über den Group-Typ wird fest gelegt, welche Objekt-Typen in Artikel-Pools eines bestimmen Group-Typs angelegt werden können. Die Bearbeitung eines Artikels ist in einzelne Schritte (Steps) unterteilt. In jedem Step gibt es verschiedene Abschnitte, in der die Teile der Eingabe-Masken strukturiert sind. Objekt-Typen definieren welche Steps verwendet werden. Steps definieren welche Abschnitte verwendet werden.<br /> <br /> <br /> Ein weiteres, grundsätzliches Problem ist die Vermischung von Daten, Logik und Darstellung. Die PHP-Seiten, die mit bisherigen Templates generiert wurden, enthielten Daten, Logik und HTML-Code an den Stellen, wo sie gerade benötigt wurden. Alles sehr vermischt in einer PHP-Datei.<br /> <br /> ;Daten (Raw-Content):<br /> Templates des SiteKit generieren nur noch die Daten in die PHP-Datei. Daher bezeichnen wir die Ausgabe-Templates des SiteKit als Aggregatoren. Zur Generierungszeit werden über die Aggregatoren die Daten so aufbereitet und angereichert, dass sie für die Darstellung gut geeignet sind. Diese Aufbereitung erfolg Ausgabe-Neutral, so dass aus den Daten nicht nur HTML, sondern auch andere Formate wie XML oder JSON erzeugt werden können. Mit diesem Ansatz wird aus Infosite ein Headless CMS. Durch dieses Vorgehen profitiert z.B auch die Suche. Bisher konnten in einem Suchergebnis nur die Daten dargestellt werden die im Suchindex enthalten waren. Jetzt ist es möglich ggf. die gesamten Daten eines Artikels für die Darstellung eines Suchergebnisses nachzuladen.<br /> <br /> ;Logik:<br /> Die Logik wird in Komponenten abgelegt. Komponenten sind Teilbereiche einer Webseite. Die gesamte Webseite wird in einzelne Komponenten zerlegt, die auch ineinander verschachtelt sein können. Viele Komponenten habe keine Logik, dann dienen sie nur als Platzhalter für die Darstellung. Komponenten wie z.B. die Suche enthalten aber auch Logik. Das SiteKit sorgt dafür das zunächst die Logik der Komponenten ausgeführt wird. Ist die gesamte Logik ausgeführt, kann die Webseite dargestellt werden.<br /> <br /> ;Ausgabe:<br /> Für jede Komponente existiert ein Renderer. Dieser erzeugt das HTML (oder ein anderes Ausgabeformat) für die Komponenten.<br /> <br /> ;Styling<br /> Auf Basis des HTML, das die Renderer erzeugen können Styles definiert werden um die gewünschte Darstellung zu erreichen. <br /> <br /> So sind Daten, Logik und Darstellung in Aggregatoren, Komponenten und Renderer aufgeteilt.<br /> <br /> <br /> Auf Basis dieser Technik werden von Sitepark Komponenten entwickelt, die in den Kunden-Projekten eingesetzt werden können. Ziel ist es die Komponenten konfigurativ so anpassen zu können das sie den individuellen Anforderungen der Projekte genügen. Sollte das nicht ausreichen, können kundenspezifische Komponenten erzeugt werden.<br /> <br /> <br /> Mit den oben beschriebenen Mitteln sollen folgende Probleme gelöst werden.<br /> <br /> ;Änderungen an Templates hat oft das Generieren der gesamten Site zur Folge: Die Seiten müssen nur noch generiert werden, wenn sich die Aggregatoren ändern. Bei Änderungen an der Logik oder an der Darstellung ist kein neu-generieren mehr notwendig.<br /> <br /> ;Produkt-Features werden im Kunden-System implementiert: Es gibt keinen Master-System mehr. Produkterweiterungen, die sich aus dem Projekt ergeben werden während des Projektes in das Produkt-Modul integriert und auch direkt verwendet.<br /> <br /> ;Template-Code wird schnell unübersichtlich: Auf Zeilenumbrüche muss keine Rücksicht mehr genommen werden, da Aggregatoren nur Maps und Collections füllen und keine Ausgabe erzeugen. Durch die Trennung von Daten, Logik und Ausgabe sind auch die verschiedenen Technologien SMPL, PHP, JavaScript und CSS getrennt und nicht mehr in einer Datei enthalten. <br /> <br /> ;Templates sind nicht updatefähig: Produkt- und Kunden-Anpassungen werden strickt getrennt. Produkte werden abwärts-kompatibel gehalten und sind damit updatefähig.<br /> <br /> ;Keine einheitliche Basis für Module: Das SiteKit liefert eine stabile Basis für Module.<br /> <br /> ==Enthaltene Funktionen und Komponenten==<br /> Im SiteKit enthalten sind Funktionen und Komponenten die Sitepark als &quot;Standard&quot; definiert hat, da sie in den meisten Projekten Verwendung finden.<br /> <br /> Alle von SiteKit bereit gestellten Komponenten sind barrierefrei und responsive.<br /> <br /> ===Generelle Funktionen===<br /> <br /> ;Navigation: Komplettes Navigations-Konzept mit verschiedenen Features wie Vererbbarkeit von Eigenschaften durch die Navigations-Struktur (z.B. Rubrik-Farbe), Mehrfachverknüpfung von Artikeln in der Navigation, geeignet für große Sites (100.000 Seiten und mehr), beliebige Navigations-Tiefe, JavaScript-basierte Mobile-fähige Navigation mit Offline-Caching.<br /> <br /> ;Suche: Voll integrierte Volltext Suche auf Basis von Solr mit Suggest, erweiterten Suchoptionen, Facettierung, unterstützt geschützte Seiten, bietet Ad-Hoc-Indizierung getriggert durch das Speichern eines Artikels, liefert Werkzeuge zur Analyse des Volltext-Index z.B. zum debuggen.<br /> <br /> ;Fehlerseiten: Redaktionell pflegbare Fehlerseiten für HTTP-Fehler (404 - Datei oder Verzeichnis nicht gefunden, ...)<br /> <br /> ;Favicons: Verwaltung der Favicons<br /> <br /> ;Geolokation: Definition von GEO-Koordinaten an Artikel. Volle Integration in die Suche für Z.B. Umkreissuchen.<br /> <br /> ;Kategorisierung: Kategorie-System zur Kategorisierung von Artikeln mit voller Integration in die Suche für z.B. Facetierung.<br /> <br /> ;Teaser: Teaser-System zur Verwendung von Teasern in verschiedenen Kontexten wie: Navigation, Teaser-Listen, Slider, Karten-Marker-Info-Boxen, Suchergebnisse, Kachelsystem. Zeitsteuerung<br /> <br /> ;Kurzadressen: Definition von Kurz-Urls<br /> <br /> ;Microsites: Microsite-System zur Erstellung von untergeordneten Sites unter eigener Domain mit geteiltem, aber Theming-fähigem Design.<br /> <br /> ;Mehrsprachigkeit (Website): Alle nicht-redaktionellen Inhalte, die auf der Webseite dargestellt werden, können über Sprachpakete in andere Sprachen übersetzt werden. Für die deutsche Sprache wird ein Sprachpaket mitgeliefert das auch nach Kundenwunsch angepasst werden kann.<br /> <br /> =Whitelabel=<br /> <br /> Damit neue Projekte nicht von Null begonnen werden müssen, wurden das Whitelabel-Modul erstellt. In diesem Modul sind immer die aktuellen Techniken zur Umsetzung von neuen Projekten enthalten. Dieses Modul dient als Kopiervorlage. Es wird immer auf die aktuellen Anforderungen von neuen Projekten angepasst. Hier wird keine Rücksicht auf Updatefähigkeit genommen.<br /> <br /> Das SiteKit soll die Technik enthalten die Projekt-übergreifend verwendet wird. Sitepark sorgt dafür, dass das SiteKit-Modul update-fähig ist und somit als langfristige Plattform für Projekt- und Produkt-Module verwendet werden kann.<br /> <br /> Besonders im Front-End-Bereich (CSS, JavaScript) werden etablierte Techniken schneller von neueren Techniken überholt. In diesem Bereich wäre eine langfristige update-Fähigkeit eine große Innovations-Bremse. Daher ist ein großer Teil der Front-End-Technik nicht im Sitekit-Modul, sondern im Whitelabel-Modul enthalten.<br /> <br /> Das Whitelabel-Modul besteht aus zwei Unter-Modulen<br /> <br /> ;IES-Modul:<br /> Das IES Modul enthält Eingabe-Templates, Aggregatoren, Komponenten, Renderer und Basis-Konfigurationen<br /> ;Styleguide:<br /> In diesem Modul ist ein Styleguide enthalten in dem das HTML hinterlegt ist, dass auch die Renderer erzeugen. Alle Komponenten sind nach dem Atomic-Design-Prinzip in Atome, Moleküle, Organismen und Templates erlegt und können so gestylt werden.<br /> <br /> =Kundenmodul=<br /> <br /> Ein Kundenmodul wird als Kopie von Whitelabel erzeugt. In diesem Modul werden alle Kundenspezifischen Anforderungen implementiert.<br /> <br /> =Systemarchitektur (vereinfacht)=<br /> <br /> SiteKit und Infosite6 zusammen bilden &quot;Infosite 6 Enterprise-Edition&quot; (Infosite 6 EE)<br /> <br /> <br /> [[Datei:InfoSite6-EE-Systemarchitektur-vereinfacht.png|800px]]<br /> <br /> Die '''CMS-Oberfläche''' stellt die Eingabemaken dar, die sich aus einzelnen Abschnitten zusammensetzen. Das SiteKit stellt diese Abschnitte bereit. Das Kunden-Modul enthält kundenspezifische Konfigurationen der SiteKit-Abschnitte und kundenspezifische Abschnitte.<br /> <br /> Das '''IES Repository''' hält die Artikel-Daten, die über die CMS-Oberfläche dargestellt und bearbeitet werden können.<br /> <br /> Der '''Raw Content''' wird pro Artikel als PHP-Datei vom CMS auf dem Webserver publiziert. Die Daten werden über Sitekit- und Kundenspezifischen-Aggregatoren aus dem IES Repository geladen und in einer für die Darstellung optimierten Form zusammengestellt.<br /> <br /> Die '''Renderer''' erzeugen beim Aufruf einer Seite aus dem Raw Content das gewünschte Ausgabeformat. Das SiteKit stellt Renderer zur Verfügung die kundenspezifisch angepasst werden können. Kunden-Module stellen auch eigene Renderer bereit.<br /> <br /> Mit Hilfe eines Styleguide werden für das Styling der Webseite '''CSS''' und '''JavaScript''' implementiert.</div>

Liebold https://wiki.sitepark.com/index.php?title=Infosite_6_Enterprise_Edition&diff=8465 2017-07-13T11:27:17Z

<p>Liebold: /* Sitekit-Framework */</p> <hr /> <div>=Motivation=<br /> <br /> Bevor die Technik für die 'Infosite 6 Enterprise Edition' zur Verfügung stand, sind Projekte mit 'alten' Methoden aufgebaut worden. Hier sollen die alten Methoden kurz beschrieben werden um den Bedarf dieser Neukonzeption nachvollziehen zu können.<br /> <br /> Templates für den Aufbau einer Webseite werden in der Datenbank eines IES-Mandanten gespeichert.<br /> Sie werden verwenden um Eingabe-Masken für das CMS zu erzeugen und Ausgaben für die Webseite. Die durch die Ausgabe-Templates generierten Dateien enthalten in der Regel PHP-, HTML-, JavaScript- und CSS-Code, der auf die Anforderungen der Webseite angepasst ist.<br /> <br /> Bearbeitet wurden die Templates im Browser über ein Textarea-Feld im Template-Editor. Dieser Template-Editor ist Teil von Infosite.<br /> <br /> Zusätzlich zu den Templates werden bei diesem Vorgen noch JavaScripte, CSS, PHP-Klassen und ggf. Bilder benötigt die als Artikel und Medien-Artikel im Mandanten gespeichert sind.<br /> <br /> Für neuen Projekte hat Sitepark ein Master-System das als Vorlage dient. Das Master-System wird einmalig in das Kunden-System kopiert.<br /> <br /> <br /> Dieses Vorgehen hatte einige Probleme zur Folge. Diese waren z.B.<br /> <br /> ;Template-Bearbeitung im Textarea-Feld: Die Bearbeitung der Templates muss Systembedingt in einem Textarea-Feld erfolgen. Durch den Template-Editor steht zwar z.B. ein Syntax-Highlighting zur Verfügung, es fehlt aber der Funktionsumfang eines Text-Editors. Um den Funktions-Umfang eines Editors nutzen zu können, muss das Template in einen Text-Editor kopiert werden. Nach der Bearbeitung muss es wieder in das Textarea-Feld kopiert werden.<br /> <br /> ;Kollaboratives Arbeiten im Projekt: Es ist nicht möglich parallel an einem Template zu arbeiten. Besonders problematisch bei zentralen Templates wie z.b. 'PHP-Head'<br /> <br /> ;Übertragung des Entwicklungsstandes vom Aufbau- zum Live-System: Auf dem Aufbau-System werden Templates entwickelt, so wie JavaScripte und CSS erzeugt. Diese müssen in regelmäßigen Abständen auf des Live-System gespielt werden. Hier nutzen wir XIP um die notwendigen Daten zu exportieren und auf dem Live-System wieder zu importieren. Bei diesem Verfahren muss bekannt sein welche Templates und Ressourcen übertragen werden dürfen und welche noch in der Entwicklung sind. Dies zu verwalten ist sehr aufwendig und Fehler-trächtig.<br /> <br /> ;Änderungen an Templates hat oft das Generieren der gesamten Site zur Folge: Änderungen am Ausgabeteil eines Templates wirken sich erst aus, wenn die Artikel, die dieses Template verwenden neu generiert werden. Häufig ist es der Fall, dass dann die gesamte Website neu generiert werden muss. Da dies bei großen Websites mehrere Stunden in Anspruch nehmen kann, blockiert das den Entwicklungs-Prozess.<br /> <br /> ;Produkt-Features werden im Kunden-System implementiert: Da die Entwicklung immer im Kunden-System und nicht im Master-System erfolgt, werden hier auch Funktionen implementiert, die in das Master-System zurück fließen müssen. Da die Templates sich durch kundenspezifische Anpassungen von dem Templates im Master-System unterscheiden kann nicht das gesamte Template übernommen werden. Es müssen im Prinzip Zeilenweise die Code-Stellen in das Master-System übertragen werden. Bei parallel laufenden Projekten, die die Funktionalität ebenfalls nutzen möchten, müssen diese Code-Stellen auch noch in das andere Kunden-Projekt übertragen werden.<br /> <br /> ;Template-Code wird schnell unübersichtlich: Bei Templates die eine Ausgabe erzeugen, möchte man möglichst unnötige Zeilenumbrüche vermeiden, die durch die Verwendung von SP-Tags entstehen. Daher werden oft Zeilenumbrüche in Kommentare gefasst oder ganz auf Zeilenumbrüche bei SP-Tags verzichtet. Weiter ist SPML-Logik mit PHP-Logik vermischt. Dadurch können Templates schnell unübersichtlich werden.<br /> <br /> ;Templates sind nicht updatefähig: Das Master-System dient nur als Kopiervorlage für Projekte. Die Templates werden nach den kundenspezifischen Anforderungen angepasst. Dadurch sind sie nicht mehr updatefähig. Neue Funktionalitäten können nur mit Aufwand in Bestands-Systeme integriert werden, da hier auch die einzelnen Code-Stellen einzeln in die Templates übertragen werden muss.<br /> <br /> ;Keine einheitliche Basis für Module: Module wie Veranstaltungskalender, Verzeichnis-Modul, Voting-Modul, Shop-Module, ... werden für einen bestimmten Stand des Master-System entwickelt. Das Master-System entwickelt sich mit jedem Projekt weiter, ohne aber eine einheitliche Basis sicherzustellen. Dies hat zur Folge das Module auf jedes System angepasst werden müssen, und nicht einfach installierbar sind.<br /> <br /> =Sitekit-Framework=<br /> <br /> Um die oben genannte Probleme zu lösen, wurden neue Konzepte entwickelt, dessen technische Implementierung eine neue Plattform bildet, die Sitekit-Framework genannt wird.<br /> <br /> Ein grundsätzliches Problem war, das Templates über Textarea-Felder in der Datenbank gespeichert werden. Templates sollen Dateien sein. Templates eines Projektes sollen in einem kundenspezifischen Modul zusammengefasst werden. Auch JavaScript, CSS, Fonts, Bilder und PHP-Dateien liegen in diesem Modul. Diese Module werden über ein GIT-Repository versioniert. Das Modul kann mit einer IDE bearbeitet werden. Auf jedem Arbeitsplatz existiert eine IES-Installation und die arbeit an Templates kann lokal auf dem eigenen Entwicklungs-Rechner erfolgen. Damit können folgende Probleme gelöst werden.<br /> <br /> ;Template-Bearbeitung im Textarea-Feld: wird nicht mehr benötigt. Bearbeitung erfolgt über eine IDE.<br /> ;Kollaboratives Arbeiten im Projekt: Jeder entwickelt auf seinem eigenen System und über GIT werden alle Änderungen zusammengeführt.<br /> ;Übertragung des Entwicklungsstandes vom Aufbau- zum Live-System: Die Entwicklungsarbeiten werden in einem Kunden-Modul zusammengefasst und können als eine Module-Datei (war-Datei, ZIP-Format) auf das Aufbau- und Live-System gespielt werden.<br /> <br /> <br /> Wenn es keine Templates in der Datenbank mehr gibt, dann gibt es auch keine Template-Pools mehr. Template-Pools sind aber notwendig, um Artikel-Pools zu konfigurieren, damit bestimmt werden kann, mit welchen Templates Artikel angelegt werden können. Weiter wurde über Template-Pools bestimmt, welche Abschnitte für einen bestimmten Artikel-Typ ausgewählt werden dürfen. Daher wurde hier eine alternative geschaffen.<br /> <br /> Es gibt nun Group-Types (Artikel-Pool-Typen), Objects-Types (Artikel-Typen), Steps und Sections (Abschnitte)<br /> <br /> [[Datei:Sitekit-Types-Steps-Sections.png|Sitekit Typen, Steps und Abschnitte|center|frame|800px]]<br /> <br /> Ein Objekt-Type ist ein Seiten-Typ. Dieser kann z.B. eine Homepage, eine Rubrik-Seite, eine Inhalts-Seite oder irgend eine spezialisierte Seite sein. Je nach Object-Type existieren unterschiedliche Ein- und Ausgaben. Ein Group-Type definiert eine bestimmte Art von Artikel-Pool. Über den Group-Typ wird fest gelegt, welche Objekt-Typen in Artikel-Pools eines bestimmen Group-Typs angelegt werden können. Die Bearbeitung eines Artikels ist in einzelne Schritte (Steps) unterteilt. In jedem Step gibt es verschiedene Abschnitte, in der die Teile der Eingabe-Masken strukturiert sind. Objekt-Typen definieren welche Steps verwendet werden. Steps definieren welche Abschnitte verwendet werden.<br /> <br /> <br /> Ein weiteres, grundsätzliches Problem ist die Vermischung von Daten, Logik und Darstellung. Die PHP-Seiten, die mit bisherigen Templates generiert wurden, enthielten Daten, Logik und HTML-Code an den Stellen, wo sie gerade benötigt wurden. Alles sehr vermischt in einer PHP-Datei.<br /> <br /> ;Daten (Raw-Content):<br /> Templates des SiteKit generieren nur noch die Daten in die PHP-Datei. Daher bezeichnen wir die Ausgabe-Templates des SiteKit als Aggregatoren. Zur Generierungszeit werden über die Aggregatoren die Daten so aufbereitet und angereichert, dass sie für die Darstellung gut geeignet sind. Diese Aufbereitung erfolg Ausgabe-Neutral, so dass aus den Daten nicht nur HTML, sondern auch andere Formate wie XML oder JSON erzeugt werden können. Mit diesem Ansatz wird aus Infosite ein Headless CMS. Durch dieses Vorgehen profitiert z.B auch die Suche. Bisher konnten in einem Suchergebnis nur die Daten dargestellt werden die im Suchindex enthalten waren. Jetzt ist es möglich ggf. die gesamten Daten eines Artikels für die Darstellung eines Suchergebnisses nachzuladen.<br /> <br /> ;Logik:<br /> Die Logik wird in Komponenten abgelegt. Komponenten sind Teilbereiche einer Webseite. Die gesamte Webseite wird in einzelne Komponenten zerlegt, die auch ineinander verschachtelt sein können. Viele Komponenten habe keine Logik, dann dienen sie nur als Platzhalter für die Darstellung. Komponenten wie z.B. die Suche enthalten aber auch Logik. Das SiteKit sorgt dafür das zunächst die Logik der Komponenten ausgeführt wird. Ist die gesamte Logik ausgeführt, kann die Webseite dargestellt werden.<br /> <br /> ;Ausgabe:<br /> Für jede Komponente existiert ein Renderer. Dieser erzeugt das HTML (oder ein anderes Ausgabeformat) für die Komponenten.<br /> <br /> ;Styling<br /> Auf Basis des HTML, das die Renderer erzeugen können Styles definiert werden um die gewünschte Darstellung zu erreichen. <br /> <br /> So sind Daten, Logik und Darstellung in Aggregatoren, Komponenten und Renderer aufgeteilt.<br /> <br /> <br /> Auf Basis dieser Technik werden von Sitepark Komponenten entwickelt, die in den Kunden-Projekten eingesetzt werden können. Ziel ist es die Komponenten konfigurativ so anpassen zu können das sie den individuellen Anforderungen der Projekte genügen. Sollte das nicht ausreichen, können kundenspezifische Komponenten erzeugt werden.<br /> <br /> <br /> Mit den oben beschriebenen Mitteln sollen folgende Probleme gelöst werden.<br /> <br /> ;Änderungen an Templates hat oft das Generieren der gesamten Site zur Folge: Die Seiten müssen nur noch generiert werden, wenn sich die Aggregatoren ändern. Bei Änderungen an der Logik oder an der Darstellung ist kein neu-generieren mehr notwendig.<br /> <br /> ;Produkt-Features werden im Kunden-System implementiert: Es gibt keinen Master-System mehr. Produkterweiterungen, die sich aus dem Projekt ergeben werden während des Projektes in das Produkt-Modul integriert und auch direkt verwendet.<br /> <br /> ;Template-Code wird schnell unübersichtlich: Auf Zeilenumbrüche muss keine Rücksicht mehr genommen werden, da Aggregatoren nur Maps und Collections füllen und keine Ausgabe erzeugen. Durch die Trennung von Daten, Logik und Ausgabe sind auch die verschiedenen Technologien SMPL, PHP, JavaScript und CSS getrennt und nicht mehr in einer Datei enthalten. <br /> <br /> ;Templates sind nicht updatefähig: Produkt- und Kunden-Anpassungen werden strickt getrennt. Produkte werden abwärts-kompatibel gehalten und sind damit updatefähig.<br /> <br /> ;Keine einheitliche Basis für Module: Das SiteKit liefert eine stabile Basis für Module.<br /> <br /> ==Enthaltene Funktionen und Komponenten==<br /> Im SiteKit enthalten sind Funktionen und Komponenten die Sitepark als &quot;Standard&quot; definiert hat, da sie in den meisten Projekten Verwendung finden.<br /> <br /> Alle von SiteKit bereit gestellten Komponenten sind barrierefrei und responsive.<br /> <br /> ===Generelle Funktionen===<br /> <br /> ;Navigation: Komplettes Navigations-Konzept mit verschiedenen Features wie Vererbbarkeit von Eigenschaften durch die Navigations-Struktur (z.B. Rubrik-Farbe), Mehrfachverknüpfung von Artikeln in der Navigation, geeignet für große Sites (100.000 Seiten und mehr), beliebige Navigations-Tiefe, JavaScript-basierte Mobile-fähige Navigation mit Offline-Caching.<br /> <br /> ;Suche: Voll integrierte Volltext Suche auf Basis von Solr mit Suggest, erweiterten Suchoptionen, Facettierung, unterstützt geschützte Seiten, bietet Ad-Hoc-Indizierung getriggert durch das Speichern eines Artikels, liefert Werkzeuge zur Analyse des Volltext-Index z.B. zum debuggen.<br /> <br /> ;Fehlerseiten: Redaktionell pflegbare Fehlerseiten für HTTP-Fehler (404 - Datei oder Verzeichnis nicht gefunden, ...)<br /> <br /> ;Favicons: Verwaltung der Favicons<br /> <br /> ;Geolokation: Definition von GEO-Koordinaten an Artikel. Volle Integration in die Suche für Z.B. Umkreissuchen.<br /> <br /> ;Kategorisierung: Kategorie-System zur Kategorisierung von Artikeln mit voller Integration in die Suche für z.B. Facetierung.<br /> <br /> ;Teaser: Teaser-System zur Verwendung von Teasern in verschiedenen Kontexten wie: Navigation, Teaser-Listen, Slider, Karten-Marker-Info-Boxen, Suchergebnisse, Kachelsystem. Zeitsteuerung<br /> <br /> ;Kurzadressen: Definition von Kurz-Urls<br /> <br /> ;Microsites: Microsite-System zur Erstellung von untergeordneten Sites unter eigener Domain mit geteiltem, aber Theming-fähigem Design.<br /> <br /> ;Mehrsprachigkeit (Website): Alle nicht-redaktionellen Inhalte, die auf der Webseite dargestellt werden, können über Sprachpakete in andere Sprachen übersetzt werden. Für die deutsche Sprache wird ein Sprachpaket mitgeliefert das auch nach Kundenwunsch angepasst werden kann.<br /> <br /> =Whitelabel=<br /> <br /> Damit neue Projekte nicht von Null begonnen werden müssen, wurden das Whitelabel-Modul erstellt. In diesem Modul sind immer die aktuellen Techniken zur Umsetzung von neuen Projekten enthalten. Dieses Modul dient als Kopiervorlage. Es wird immer auf die aktuellen Anforderungen von neuen Projekten angepasst. Hier wird keine Rücksicht auf Updatefähigkeit genommen.<br /> <br /> Das SiteKit soll die Technik enthalten die Projekt-übergreifend verwendet wird. Sitepark sorgt dafür, dass das SiteKit-Modul update-fähig ist und somit als langfristige Plattform für Projekt- und Produkt-Module verwendet werden kann.<br /> <br /> Besonders im Front-End-Bereich (CSS, JavaScript) werden etablierte Techniken schneller von neueren Techniken überholt. In diesem Bereich wäre eine langfristige update-Fähigkeit eine große Innovations-Bremse. Daher ist ein großer Teil der Front-End-Technik nicht im Sitekit-Modul, sondern im Whitelabel-Modul enthalten.<br /> <br /> Das Whitelabel-Modul besteht aus zwei Unter-Modulen<br /> <br /> ;IES-Modul:<br /> Das IES Modul enthält Eingabe-Templates, Aggregatoren, Komponenten, Renderer und Basis-Konfigurationen<br /> ;Styleguide:<br /> In diesem Modul ist ein Styleguide enthalten in dem das HTML hinterlegt ist, dass auch die Renderer erzeugen. Alle Komponenten sind nach dem Atomic-Design-Prinzip in Atome, Moleküle, Organismen und Templates erlegt und können so gestylt werden.<br /> <br /> =Kundenmodul=<br /> <br /> Ein Kundenmodul wird als Kopie von Whitelabel erzeugt. In diesem Modul werden alle Kundenspezifischen Anforderungen implementiert.<br /> <br /> =Systemarchitektur (vereinfacht)=<br /> <br /> SiteKit und Infosite6 zusammen bilden &quot;Infosite 6 Enterprise-Edition&quot; (Infosite 6 EE)<br /> <br /> <br /> [[Datei:InfoSite6-EE-Systemarchitektur-vereinfacht.png|800px]]<br /> <br /> Die '''CMS-Oberfläche''' stellt die Eingabemaken dar, die sich aus einzelnen Abschnitten zusammensetzen. Das SiteKit stellt diese Abschnitte bereit. Das Kunden-Modul enthält kundenspezifische Konfigurationen der SiteKit-Abschnitte und kundenspezifische Abschnitte.<br /> <br /> Das '''IES Repository''' hält die Artikel-Daten, die über die CMS-Oberfläche dargestellt und bearbeitet werden können.<br /> <br /> Der '''Raw Content''' wird pro Artikel als PHP-Datei vom CMS auf dem Webserver publiziert. Die Daten werden über Sitekit- und Kundenspezifischen-Aggregatoren aus dem IES Repository geladen und in einer für die Darstellung optimierten Form zusammengestellt.<br /> <br /> Die '''Renderer''' erzeugen beim Aufruf einer Seite aus dem Raw Content das gewünschte Ausgabeformat. Das SiteKit stellt Renderer zur Verfügung die kundenspezifisch angepasst werden können. Kunden-Module stellen auch eigene Renderer bereit.<br /> <br /> Mit Hilfe eines Styleguide werden für das Styling der Webseite '''CSS''' und '''JavaScript''' implementiert.</div>

Liebold https://wiki.sitepark.com/index.php?title=Infosite_6_Enterprise_Edition&diff=8464 2017-07-13T11:26:55Z

<p>Liebold: /* Sitekit */</p> <hr /> <div>=Motivation=<br /> <br /> Bevor die Technik für die 'Infosite 6 Enterprise Edition' zur Verfügung stand, sind Projekte mit 'alten' Methoden aufgebaut worden. Hier sollen die alten Methoden kurz beschrieben werden um den Bedarf dieser Neukonzeption nachvollziehen zu können.<br /> <br /> Templates für den Aufbau einer Webseite werden in der Datenbank eines IES-Mandanten gespeichert.<br /> Sie werden verwenden um Eingabe-Masken für das CMS zu erzeugen und Ausgaben für die Webseite. Die durch die Ausgabe-Templates generierten Dateien enthalten in der Regel PHP-, HTML-, JavaScript- und CSS-Code, der auf die Anforderungen der Webseite angepasst ist.<br /> <br /> Bearbeitet wurden die Templates im Browser über ein Textarea-Feld im Template-Editor. Dieser Template-Editor ist Teil von Infosite.<br /> <br /> Zusätzlich zu den Templates werden bei diesem Vorgen noch JavaScripte, CSS, PHP-Klassen und ggf. Bilder benötigt die als Artikel und Medien-Artikel im Mandanten gespeichert sind.<br /> <br /> Für neuen Projekte hat Sitepark ein Master-System das als Vorlage dient. Das Master-System wird einmalig in das Kunden-System kopiert.<br /> <br /> <br /> Dieses Vorgehen hatte einige Probleme zur Folge. Diese waren z.B.<br /> <br /> ;Template-Bearbeitung im Textarea-Feld: Die Bearbeitung der Templates muss Systembedingt in einem Textarea-Feld erfolgen. Durch den Template-Editor steht zwar z.B. ein Syntax-Highlighting zur Verfügung, es fehlt aber der Funktionsumfang eines Text-Editors. Um den Funktions-Umfang eines Editors nutzen zu können, muss das Template in einen Text-Editor kopiert werden. Nach der Bearbeitung muss es wieder in das Textarea-Feld kopiert werden.<br /> <br /> ;Kollaboratives Arbeiten im Projekt: Es ist nicht möglich parallel an einem Template zu arbeiten. Besonders problematisch bei zentralen Templates wie z.b. 'PHP-Head'<br /> <br /> ;Übertragung des Entwicklungsstandes vom Aufbau- zum Live-System: Auf dem Aufbau-System werden Templates entwickelt, so wie JavaScripte und CSS erzeugt. Diese müssen in regelmäßigen Abständen auf des Live-System gespielt werden. Hier nutzen wir XIP um die notwendigen Daten zu exportieren und auf dem Live-System wieder zu importieren. Bei diesem Verfahren muss bekannt sein welche Templates und Ressourcen übertragen werden dürfen und welche noch in der Entwicklung sind. Dies zu verwalten ist sehr aufwendig und Fehler-trächtig.<br /> <br /> ;Änderungen an Templates hat oft das Generieren der gesamten Site zur Folge: Änderungen am Ausgabeteil eines Templates wirken sich erst aus, wenn die Artikel, die dieses Template verwenden neu generiert werden. Häufig ist es der Fall, dass dann die gesamte Website neu generiert werden muss. Da dies bei großen Websites mehrere Stunden in Anspruch nehmen kann, blockiert das den Entwicklungs-Prozess.<br /> <br /> ;Produkt-Features werden im Kunden-System implementiert: Da die Entwicklung immer im Kunden-System und nicht im Master-System erfolgt, werden hier auch Funktionen implementiert, die in das Master-System zurück fließen müssen. Da die Templates sich durch kundenspezifische Anpassungen von dem Templates im Master-System unterscheiden kann nicht das gesamte Template übernommen werden. Es müssen im Prinzip Zeilenweise die Code-Stellen in das Master-System übertragen werden. Bei parallel laufenden Projekten, die die Funktionalität ebenfalls nutzen möchten, müssen diese Code-Stellen auch noch in das andere Kunden-Projekt übertragen werden.<br /> <br /> ;Template-Code wird schnell unübersichtlich: Bei Templates die eine Ausgabe erzeugen, möchte man möglichst unnötige Zeilenumbrüche vermeiden, die durch die Verwendung von SP-Tags entstehen. Daher werden oft Zeilenumbrüche in Kommentare gefasst oder ganz auf Zeilenumbrüche bei SP-Tags verzichtet. Weiter ist SPML-Logik mit PHP-Logik vermischt. Dadurch können Templates schnell unübersichtlich werden.<br /> <br /> ;Templates sind nicht updatefähig: Das Master-System dient nur als Kopiervorlage für Projekte. Die Templates werden nach den kundenspezifischen Anforderungen angepasst. Dadurch sind sie nicht mehr updatefähig. Neue Funktionalitäten können nur mit Aufwand in Bestands-Systeme integriert werden, da hier auch die einzelnen Code-Stellen einzeln in die Templates übertragen werden muss.<br /> <br /> ;Keine einheitliche Basis für Module: Module wie Veranstaltungskalender, Verzeichnis-Modul, Voting-Modul, Shop-Module, ... werden für einen bestimmten Stand des Master-System entwickelt. Das Master-System entwickelt sich mit jedem Projekt weiter, ohne aber eine einheitliche Basis sicherzustellen. Dies hat zur Folge das Module auf jedes System angepasst werden müssen, und nicht einfach installierbar sind.<br /> <br /> =Sitekit-Framework=<br /> <br /> Um die oben genannte Probleme zu lösen, wurden neue Konzepte entwickelt, dessen technische Implementierung eine neue Plattform bildet, die SiteKit-Framework genannt wird.<br /> <br /> Ein grundsätzliches Problem war, das Templates über Textarea-Felder in der Datenbank gespeichert werden. Templates sollen Dateien sein. Templates eines Projektes sollen in einem kundenspezifischen Modul zusammengefasst werden. Auch JavaScript, CSS, Fonts, Bilder und PHP-Dateien liegen in diesem Modul. Diese Module werden über ein GIT-Repository versioniert. Das Modul kann mit einer IDE bearbeitet werden. Auf jedem Arbeitsplatz existiert eine IES-Installation und die arbeit an Templates kann lokal auf dem eigenen Entwicklungs-Rechner erfolgen. Damit können folgende Probleme gelöst werden.<br /> <br /> ;Template-Bearbeitung im Textarea-Feld: wird nicht mehr benötigt. Bearbeitung erfolgt über eine IDE.<br /> ;Kollaboratives Arbeiten im Projekt: Jeder entwickelt auf seinem eigenen System und über GIT werden alle Änderungen zusammengeführt.<br /> ;Übertragung des Entwicklungsstandes vom Aufbau- zum Live-System: Die Entwicklungsarbeiten werden in einem Kunden-Modul zusammengefasst und können als eine Module-Datei (war-Datei, ZIP-Format) auf das Aufbau- und Live-System gespielt werden.<br /> <br /> <br /> Wenn es keine Templates in der Datenbank mehr gibt, dann gibt es auch keine Template-Pools mehr. Template-Pools sind aber notwendig, um Artikel-Pools zu konfigurieren, damit bestimmt werden kann, mit welchen Templates Artikel angelegt werden können. Weiter wurde über Template-Pools bestimmt, welche Abschnitte für einen bestimmten Artikel-Typ ausgewählt werden dürfen. Daher wurde hier eine alternative geschaffen.<br /> <br /> Es gibt nun Group-Types (Artikel-Pool-Typen), Objects-Types (Artikel-Typen), Steps und Sections (Abschnitte)<br /> <br /> [[Datei:Sitekit-Types-Steps-Sections.png|Sitekit Typen, Steps und Abschnitte|center|frame|800px]]<br /> <br /> Ein Objekt-Type ist ein Seiten-Typ. Dieser kann z.B. eine Homepage, eine Rubrik-Seite, eine Inhalts-Seite oder irgend eine spezialisierte Seite sein. Je nach Object-Type existieren unterschiedliche Ein- und Ausgaben. Ein Group-Type definiert eine bestimmte Art von Artikel-Pool. Über den Group-Typ wird fest gelegt, welche Objekt-Typen in Artikel-Pools eines bestimmen Group-Typs angelegt werden können. Die Bearbeitung eines Artikels ist in einzelne Schritte (Steps) unterteilt. In jedem Step gibt es verschiedene Abschnitte, in der die Teile der Eingabe-Masken strukturiert sind. Objekt-Typen definieren welche Steps verwendet werden. Steps definieren welche Abschnitte verwendet werden.<br /> <br /> <br /> Ein weiteres, grundsätzliches Problem ist die Vermischung von Daten, Logik und Darstellung. Die PHP-Seiten, die mit bisherigen Templates generiert wurden, enthielten Daten, Logik und HTML-Code an den Stellen, wo sie gerade benötigt wurden. Alles sehr vermischt in einer PHP-Datei.<br /> <br /> ;Daten (Raw-Content):<br /> Templates des SiteKit generieren nur noch die Daten in die PHP-Datei. Daher bezeichnen wir die Ausgabe-Templates des SiteKit als Aggregatoren. Zur Generierungszeit werden über die Aggregatoren die Daten so aufbereitet und angereichert, dass sie für die Darstellung gut geeignet sind. Diese Aufbereitung erfolg Ausgabe-Neutral, so dass aus den Daten nicht nur HTML, sondern auch andere Formate wie XML oder JSON erzeugt werden können. Mit diesem Ansatz wird aus Infosite ein Headless CMS. Durch dieses Vorgehen profitiert z.B auch die Suche. Bisher konnten in einem Suchergebnis nur die Daten dargestellt werden die im Suchindex enthalten waren. Jetzt ist es möglich ggf. die gesamten Daten eines Artikels für die Darstellung eines Suchergebnisses nachzuladen.<br /> <br /> ;Logik:<br /> Die Logik wird in Komponenten abgelegt. Komponenten sind Teilbereiche einer Webseite. Die gesamte Webseite wird in einzelne Komponenten zerlegt, die auch ineinander verschachtelt sein können. Viele Komponenten habe keine Logik, dann dienen sie nur als Platzhalter für die Darstellung. Komponenten wie z.B. die Suche enthalten aber auch Logik. Das SiteKit sorgt dafür das zunächst die Logik der Komponenten ausgeführt wird. Ist die gesamte Logik ausgeführt, kann die Webseite dargestellt werden.<br /> <br /> ;Ausgabe:<br /> Für jede Komponente existiert ein Renderer. Dieser erzeugt das HTML (oder ein anderes Ausgabeformat) für die Komponenten.<br /> <br /> ;Styling<br /> Auf Basis des HTML, das die Renderer erzeugen können Styles definiert werden um die gewünschte Darstellung zu erreichen. <br /> <br /> So sind Daten, Logik und Darstellung in Aggregatoren, Komponenten und Renderer aufgeteilt.<br /> <br /> <br /> Auf Basis dieser Technik werden von Sitepark Komponenten entwickelt, die in den Kunden-Projekten eingesetzt werden können. Ziel ist es die Komponenten konfigurativ so anpassen zu können das sie den individuellen Anforderungen der Projekte genügen. Sollte das nicht ausreichen, können kundenspezifische Komponenten erzeugt werden.<br /> <br /> <br /> Mit den oben beschriebenen Mitteln sollen folgende Probleme gelöst werden.<br /> <br /> ;Änderungen an Templates hat oft das Generieren der gesamten Site zur Folge: Die Seiten müssen nur noch generiert werden, wenn sich die Aggregatoren ändern. Bei Änderungen an der Logik oder an der Darstellung ist kein neu-generieren mehr notwendig.<br /> <br /> ;Produkt-Features werden im Kunden-System implementiert: Es gibt keinen Master-System mehr. Produkterweiterungen, die sich aus dem Projekt ergeben werden während des Projektes in das Produkt-Modul integriert und auch direkt verwendet.<br /> <br /> ;Template-Code wird schnell unübersichtlich: Auf Zeilenumbrüche muss keine Rücksicht mehr genommen werden, da Aggregatoren nur Maps und Collections füllen und keine Ausgabe erzeugen. Durch die Trennung von Daten, Logik und Ausgabe sind auch die verschiedenen Technologien SMPL, PHP, JavaScript und CSS getrennt und nicht mehr in einer Datei enthalten. <br /> <br /> ;Templates sind nicht updatefähig: Produkt- und Kunden-Anpassungen werden strickt getrennt. Produkte werden abwärts-kompatibel gehalten und sind damit updatefähig.<br /> <br /> ;Keine einheitliche Basis für Module: Das SiteKit liefert eine stabile Basis für Module.<br /> <br /> ==Enthaltene Funktionen und Komponenten==<br /> Im SiteKit enthalten sind Funktionen und Komponenten die Sitepark als &quot;Standard&quot; definiert hat, da sie in den meisten Projekten Verwendung finden.<br /> <br /> Alle von SiteKit bereit gestellten Komponenten sind barrierefrei und responsive.<br /> <br /> ===Generelle Funktionen===<br /> <br /> ;Navigation: Komplettes Navigations-Konzept mit verschiedenen Features wie Vererbbarkeit von Eigenschaften durch die Navigations-Struktur (z.B. Rubrik-Farbe), Mehrfachverknüpfung von Artikeln in der Navigation, geeignet für große Sites (100.000 Seiten und mehr), beliebige Navigations-Tiefe, JavaScript-basierte Mobile-fähige Navigation mit Offline-Caching.<br /> <br /> ;Suche: Voll integrierte Volltext Suche auf Basis von Solr mit Suggest, erweiterten Suchoptionen, Facettierung, unterstützt geschützte Seiten, bietet Ad-Hoc-Indizierung getriggert durch das Speichern eines Artikels, liefert Werkzeuge zur Analyse des Volltext-Index z.B. zum debuggen.<br /> <br /> ;Fehlerseiten: Redaktionell pflegbare Fehlerseiten für HTTP-Fehler (404 - Datei oder Verzeichnis nicht gefunden, ...)<br /> <br /> ;Favicons: Verwaltung der Favicons<br /> <br /> ;Geolokation: Definition von GEO-Koordinaten an Artikel. Volle Integration in die Suche für Z.B. Umkreissuchen.<br /> <br /> ;Kategorisierung: Kategorie-System zur Kategorisierung von Artikeln mit voller Integration in die Suche für z.B. Facetierung.<br /> <br /> ;Teaser: Teaser-System zur Verwendung von Teasern in verschiedenen Kontexten wie: Navigation, Teaser-Listen, Slider, Karten-Marker-Info-Boxen, Suchergebnisse, Kachelsystem. Zeitsteuerung<br /> <br /> ;Kurzadressen: Definition von Kurz-Urls<br /> <br /> ;Microsites: Microsite-System zur Erstellung von untergeordneten Sites unter eigener Domain mit geteiltem, aber Theming-fähigem Design.<br /> <br /> ;Mehrsprachigkeit (Website): Alle nicht-redaktionellen Inhalte, die auf der Webseite dargestellt werden, können über Sprachpakete in andere Sprachen übersetzt werden. Für die deutsche Sprache wird ein Sprachpaket mitgeliefert das auch nach Kundenwunsch angepasst werden kann.<br /> <br /> =Whitelabel=<br /> <br /> Damit neue Projekte nicht von Null begonnen werden müssen, wurden das Whitelabel-Modul erstellt. In diesem Modul sind immer die aktuellen Techniken zur Umsetzung von neuen Projekten enthalten. Dieses Modul dient als Kopiervorlage. Es wird immer auf die aktuellen Anforderungen von neuen Projekten angepasst. Hier wird keine Rücksicht auf Updatefähigkeit genommen.<br /> <br /> Das SiteKit soll die Technik enthalten die Projekt-übergreifend verwendet wird. Sitepark sorgt dafür, dass das SiteKit-Modul update-fähig ist und somit als langfristige Plattform für Projekt- und Produkt-Module verwendet werden kann.<br /> <br /> Besonders im Front-End-Bereich (CSS, JavaScript) werden etablierte Techniken schneller von neueren Techniken überholt. In diesem Bereich wäre eine langfristige update-Fähigkeit eine große Innovations-Bremse. Daher ist ein großer Teil der Front-End-Technik nicht im Sitekit-Modul, sondern im Whitelabel-Modul enthalten.<br /> <br /> Das Whitelabel-Modul besteht aus zwei Unter-Modulen<br /> <br /> ;IES-Modul:<br /> Das IES Modul enthält Eingabe-Templates, Aggregatoren, Komponenten, Renderer und Basis-Konfigurationen<br /> ;Styleguide:<br /> In diesem Modul ist ein Styleguide enthalten in dem das HTML hinterlegt ist, dass auch die Renderer erzeugen. Alle Komponenten sind nach dem Atomic-Design-Prinzip in Atome, Moleküle, Organismen und Templates erlegt und können so gestylt werden.<br /> <br /> =Kundenmodul=<br /> <br /> Ein Kundenmodul wird als Kopie von Whitelabel erzeugt. In diesem Modul werden alle Kundenspezifischen Anforderungen implementiert.<br /> <br /> =Systemarchitektur (vereinfacht)=<br /> <br /> SiteKit und Infosite6 zusammen bilden &quot;Infosite 6 Enterprise-Edition&quot; (Infosite 6 EE)<br /> <br /> <br /> [[Datei:InfoSite6-EE-Systemarchitektur-vereinfacht.png|800px]]<br /> <br /> Die '''CMS-Oberfläche''' stellt die Eingabemaken dar, die sich aus einzelnen Abschnitten zusammensetzen. Das SiteKit stellt diese Abschnitte bereit. Das Kunden-Modul enthält kundenspezifische Konfigurationen der SiteKit-Abschnitte und kundenspezifische Abschnitte.<br /> <br /> Das '''IES Repository''' hält die Artikel-Daten, die über die CMS-Oberfläche dargestellt und bearbeitet werden können.<br /> <br /> Der '''Raw Content''' wird pro Artikel als PHP-Datei vom CMS auf dem Webserver publiziert. Die Daten werden über Sitekit- und Kundenspezifischen-Aggregatoren aus dem IES Repository geladen und in einer für die Darstellung optimierten Form zusammengestellt.<br /> <br /> Die '''Renderer''' erzeugen beim Aufruf einer Seite aus dem Raw Content das gewünschte Ausgabeformat. Das SiteKit stellt Renderer zur Verfügung die kundenspezifisch angepasst werden können. Kunden-Module stellen auch eigene Renderer bereit.<br /> <br /> Mit Hilfe eines Styleguide werden für das Styling der Webseite '''CSS''' und '''JavaScript''' implementiert.</div>

Liebold https://wiki.sitepark.com/index.php?title=Infosite_6_Enterprise_Edition&diff=8463 2017-07-13T11:20:00Z

<p>Liebold: /* Motivation */</p> <hr /> <div>=Motivation=<br /> <br /> Bevor die Technik für die 'Infosite 6 Enterprise Edition' zur Verfügung stand, sind Projekte mit 'alten' Methoden aufgebaut worden. Hier sollen die alten Methoden kurz beschrieben werden um den Bedarf dieser Neukonzeption nachvollziehen zu können.<br /> <br /> Templates für den Aufbau einer Webseite werden in der Datenbank eines IES-Mandanten gespeichert.<br /> Sie werden verwenden um Eingabe-Masken für das CMS zu erzeugen und Ausgaben für die Webseite. Die durch die Ausgabe-Templates generierten Dateien enthalten in der Regel PHP-, HTML-, JavaScript- und CSS-Code, der auf die Anforderungen der Webseite angepasst ist.<br /> <br /> Bearbeitet wurden die Templates im Browser über ein Textarea-Feld im Template-Editor. Dieser Template-Editor ist Teil von Infosite.<br /> <br /> Zusätzlich zu den Templates werden bei diesem Vorgen noch JavaScripte, CSS, PHP-Klassen und ggf. Bilder benötigt die als Artikel und Medien-Artikel im Mandanten gespeichert sind.<br /> <br /> Für neuen Projekte hat Sitepark ein Master-System das als Vorlage dient. Das Master-System wird einmalig in das Kunden-System kopiert.<br /> <br /> <br /> Dieses Vorgehen hatte einige Probleme zur Folge. Diese waren z.B.<br /> <br /> ;Template-Bearbeitung im Textarea-Feld: Die Bearbeitung der Templates muss Systembedingt in einem Textarea-Feld erfolgen. Durch den Template-Editor steht zwar z.B. ein Syntax-Highlighting zur Verfügung, es fehlt aber der Funktionsumfang eines Text-Editors. Um den Funktions-Umfang eines Editors nutzen zu können, muss das Template in einen Text-Editor kopiert werden. Nach der Bearbeitung muss es wieder in das Textarea-Feld kopiert werden.<br /> <br /> ;Kollaboratives Arbeiten im Projekt: Es ist nicht möglich parallel an einem Template zu arbeiten. Besonders problematisch bei zentralen Templates wie z.b. 'PHP-Head'<br /> <br /> ;Übertragung des Entwicklungsstandes vom Aufbau- zum Live-System: Auf dem Aufbau-System werden Templates entwickelt, so wie JavaScripte und CSS erzeugt. Diese müssen in regelmäßigen Abständen auf des Live-System gespielt werden. Hier nutzen wir XIP um die notwendigen Daten zu exportieren und auf dem Live-System wieder zu importieren. Bei diesem Verfahren muss bekannt sein welche Templates und Ressourcen übertragen werden dürfen und welche noch in der Entwicklung sind. Dies zu verwalten ist sehr aufwendig und Fehler-trächtig.<br /> <br /> ;Änderungen an Templates hat oft das Generieren der gesamten Site zur Folge: Änderungen am Ausgabeteil eines Templates wirken sich erst aus, wenn die Artikel, die dieses Template verwenden neu generiert werden. Häufig ist es der Fall, dass dann die gesamte Website neu generiert werden muss. Da dies bei großen Websites mehrere Stunden in Anspruch nehmen kann, blockiert das den Entwicklungs-Prozess.<br /> <br /> ;Produkt-Features werden im Kunden-System implementiert: Da die Entwicklung immer im Kunden-System und nicht im Master-System erfolgt, werden hier auch Funktionen implementiert, die in das Master-System zurück fließen müssen. Da die Templates sich durch kundenspezifische Anpassungen von dem Templates im Master-System unterscheiden kann nicht das gesamte Template übernommen werden. Es müssen im Prinzip Zeilenweise die Code-Stellen in das Master-System übertragen werden. Bei parallel laufenden Projekten, die die Funktionalität ebenfalls nutzen möchten, müssen diese Code-Stellen auch noch in das andere Kunden-Projekt übertragen werden.<br /> <br /> ;Template-Code wird schnell unübersichtlich: Bei Templates die eine Ausgabe erzeugen, möchte man möglichst unnötige Zeilenumbrüche vermeiden, die durch die Verwendung von SP-Tags entstehen. Daher werden oft Zeilenumbrüche in Kommentare gefasst oder ganz auf Zeilenumbrüche bei SP-Tags verzichtet. Weiter ist SPML-Logik mit PHP-Logik vermischt. Dadurch können Templates schnell unübersichtlich werden.<br /> <br /> ;Templates sind nicht updatefähig: Das Master-System dient nur als Kopiervorlage für Projekte. Die Templates werden nach den kundenspezifischen Anforderungen angepasst. Dadurch sind sie nicht mehr updatefähig. Neue Funktionalitäten können nur mit Aufwand in Bestands-Systeme integriert werden, da hier auch die einzelnen Code-Stellen einzeln in die Templates übertragen werden muss.<br /> <br /> ;Keine einheitliche Basis für Module: Module wie Veranstaltungskalender, Verzeichnis-Modul, Voting-Modul, Shop-Module, ... werden für einen bestimmten Stand des Master-System entwickelt. Das Master-System entwickelt sich mit jedem Projekt weiter, ohne aber eine einheitliche Basis sicherzustellen. Dies hat zur Folge das Module auf jedes System angepasst werden müssen, und nicht einfach installierbar sind.<br /> <br /> =Sitekit=<br /> <br /> Um die oben genannte Probleme zu lösen, wurden neue Konzepte entwickelt, dessen technische Implementierung eine neue Plattform bildet, die SiteKit genannt wird.<br /> <br /> Ein grundsätzliches Problem war, das Templates über Textarea-Felder in der Datenbank gespeichert werden. Templates sollen Dateien sein. Templates eines Projektes sollen in einem kundenspezifischen Modul zusammengefasst werden. Auch JavaScript, CSS, Fonts, Bilder und PHP-Dateien liegen in diesem Modul. Diese Module werden über ein GIT-Repository versioniert. Das Modul kann mit einer IDE bearbeitet werden. Auf jedem Arbeitsplatz existiert eine IES-Installation und die arbeit an Templates kann lokal auf dem eigenen Entwicklungs-Rechner erfolgen. Damit können folgende Probleme gelöst werden.<br /> <br /> ;Template-Bearbeitung im Textarea-Feld: wird nicht mehr benötigt. Bearbeitung erfolgt über eine IDE.<br /> ;Kollaboratives Arbeiten im Projekt: Jeder entwickelt auf seinem eigenen System und über GIT werden alle Änderungen zusammengeführt.<br /> ;Übertragung des Entwicklungsstandes vom Aufbau- zum Live-System: Die Entwicklungsarbeiten werden in einem Kunden-Modul zusammengefasst und können als eine Module-Datei (war-Datei, ZIP-Format) auf das Aufbau- und Live-System gespielt werden.<br /> <br /> <br /> Wenn es keine Templates in der Datenbank mehr gibt, dann gibt es auch keine Template-Pools mehr. Template-Pools sind aber notwendig, um Artikel-Pools zu konfigurieren, damit bestimmt werden kann, mit welchen Templates Artikel angelegt werden können. Weiter wurde über Template-Pools bestimmt, welche Abschnitte für einen bestimmten Artikel-Typ ausgewählt werden dürfen. Daher wurde hier eine alternative geschaffen.<br /> <br /> Es gibt nun Group-Types (Artikel-Pool-Typen), Objects-Types (Artikel-Typen), Steps und Sections (Abschnitte)<br /> <br /> [[Datei:Sitekit-Types-Steps-Sections.png|Sitekit Typen, Steps und Abschnitte|center|frame|800px]]<br /> <br /> Ein Objekt-Type ist ein Seiten-Typ. Dieser kann z.B. eine Homepage, eine Rubrik-Seite, eine Inhalts-Seite oder irgend eine spezialisierte Seite sein. Je nach Object-Type existieren unterschiedliche Ein- und Ausgaben. Ein Group-Type definiert eine bestimmte Art von Artikel-Pool. Über den Group-Typ wird fest gelegt, welche Objekt-Typen in Artikel-Pools eines bestimmen Group-Typs angelegt werden können. Die Bearbeitung eines Artikels ist in einzelne Schritte (Steps) unterteilt. In jedem Step gibt es verschiedene Abschnitte, in der die Teile der Eingabe-Masken strukturiert sind. Objekt-Typen definieren welche Steps verwendet werden. Steps definieren welche Abschnitte verwendet werden.<br /> <br /> <br /> Ein weiteres, grundsätzliches Problem ist die Vermischung von Daten, Logik und Darstellung. Die PHP-Seiten, die mit bisherigen Templates generiert wurden, enthielten Daten, Logik und HTML-Code an den Stellen, wo sie gerade benötigt wurden. Alles sehr vermischt in einer PHP-Datei.<br /> <br /> ;Daten (Raw-Content):<br /> Templates des SiteKit generieren nur noch die Daten in die PHP-Datei. Daher bezeichnen wir die Ausgabe-Templates des SiteKit als Aggregatoren. Zur Generierungszeit werden über die Aggregatoren die Daten so aufbereitet und angereichert, dass sie für die Darstellung gut geeignet sind. Diese Aufbereitung erfolg Ausgabe-Neutral, so dass aus den Daten nicht nur HTML, sondern auch andere Formate wie XML oder JSON erzeugt werden können. Mit diesem Ansatz wird aus Infosite ein Headless CMS. Durch dieses Vorgehen profitiert z.B auch die Suche. Bisher konnten in einem Suchergebnis nur die Daten dargestellt werden die im Suchindex enthalten waren. Jetzt ist es möglich ggf. die gesamten Daten eines Artikels für die Darstellung eines Suchergebnisses nachzuladen.<br /> <br /> ;Logik:<br /> Die Logik wird in Komponenten abgelegt. Komponenten sind Teilbereiche einer Webseite. Die gesamte Webseite wird in einzelne Komponenten zerlegt, die auch ineinander verschachtelt sein können. Viele Komponenten habe keine Logik, dann dienen sie nur als Platzhalter für die Darstellung. Komponenten wie z.B. die Suche enthalten aber auch Logik. Das SiteKit sorgt dafür das zunächst die Logik der Komponenten ausgeführt wird. Ist die gesamte Logik ausgeführt, kann die Webseite dargestellt werden.<br /> <br /> ;Ausgabe:<br /> Für jede Komponente existiert ein Renderer. Dieser erzeugt das HTML (oder ein anderes Ausgabeformat) für die Komponenten.<br /> <br /> ;Styling<br /> Auf Basis des HTML, das die Renderer erzeugen können Styles definiert werden um die gewünschte Darstellung zu erreichen. <br /> <br /> So sind Daten, Logik und Darstellung in Aggregatoren, Komponenten und Renderer aufgeteilt.<br /> <br /> <br /> Auf Basis dieser Technik werden von Sitepark Komponenten entwickelt, die in den Kunden-Projekten eingesetzt werden können. Ziel ist es die Komponenten konfigurativ so anpassen zu können das sie den individuellen Anforderungen der Projekte genügen. Sollte das nicht ausreichen, können kundenspezifische Komponenten erzeugt werden.<br /> <br /> <br /> Mit den oben beschriebenen Mitteln sollen folgende Probleme gelöst werden.<br /> <br /> ;Änderungen an Templates hat oft das Generieren der gesamten Site zur Folge: Die Seiten müssen nur noch generiert werden, wenn sich die Aggregatoren ändern. Bei Änderungen an der Logik oder an der Darstellung ist kein neu-generieren mehr notwendig.<br /> <br /> ;Produkt-Features werden im Kunden-System implementiert: Es gibt keinen Master-System mehr. Produkterweiterungen, die sich aus dem Projekt ergeben werden während des Projektes in das Produkt-Modul integriert und auch direkt verwendet.<br /> <br /> ;Template-Code wird schnell unübersichtlich: Auf Zeilenumbrüche muss keine Rücksicht mehr genommen werden, da Aggregatoren nur Maps und Collections füllen und keine Ausgabe erzeugen. Durch die Trennung von Daten, Logik und Ausgabe sind auch die verschiedenen Technologien SMPL, PHP, JavaScript und CSS getrennt und nicht mehr in einer Datei enthalten. <br /> <br /> ;Templates sind nicht updatefähig: Produkt- und Kunden-Anpassungen werden strickt getrennt. Produkte werden abwärts-kompatibel gehalten und sind damit updatefähig.<br /> <br /> ;Keine einheitliche Basis für Module: Das SiteKit liefert eine stabile Basis für Module.<br /> <br /> ==Enthaltene Funktionen und Komponenten==<br /> Im SiteKit enthalten sind Funktionen und Komponenten die Sitepark als &quot;Standard&quot; definiert hat, da sie in den meisten Projekten Verwendung finden.<br /> <br /> Alle von SiteKit bereit gestellten Komponenten sind barrierefrei und responsive.<br /> <br /> ===Generelle Funktionen===<br /> <br /> ;Navigation: Komplettes Navigations-Konzept mit verschiedenen Features wie Vererbbarkeit von Eigenschaften durch die Navigations-Struktur (z.B. Rubrik-Farbe), Mehrfachverknüpfung von Artikeln in der Navigation, geeignet für große Sites (100.000 Seiten und mehr), beliebige Navigations-Tiefe, JavaScript-basierte Mobile-fähige Navigation mit Offline-Caching.<br /> <br /> ;Suche: Voll integrierte Volltext Suche auf Basis von Solr mit Suggest, erweiterten Suchoptionen, Facettierung, unterstützt geschützte Seiten, bietet Ad-Hoc-Indizierung getriggert durch das Speichern eines Artikels, liefert Werkzeuge zur Analyse des Volltext-Index z.B. zum debuggen.<br /> <br /> ;Fehlerseiten: Redaktionell pflegbare Fehlerseiten für HTTP-Fehler (404 - Datei oder Verzeichnis nicht gefunden, ...)<br /> <br /> ;Favicons: Verwaltung der Favicons<br /> <br /> ;Geolokation: Definition von GEO-Koordinaten an Artikel. Volle Integration in die Suche für Z.B. Umkreissuchen.<br /> <br /> ;Kategorisierung: Kategorie-System zur Kategorisierung von Artikeln mit voller Integration in die Suche für z.B. Facetierung.<br /> <br /> ;Teaser: Teaser-System zur Verwendung von Teasern in verschiedenen Kontexten wie: Navigation, Teaser-Listen, Slider, Karten-Marker-Info-Boxen, Suchergebnisse, Kachelsystem. Zeitsteuerung<br /> <br /> ;Kurzadressen: Definition von Kurz-Urls<br /> <br /> ;Microsites: Microsite-System zur Erstellung von untergeordneten Sites unter eigener Domain mit geteiltem, aber Theming-fähigem Design.<br /> <br /> ;Mehrsprachigkeit (Website): Alle nicht-redaktionellen Inhalte, die auf der Webseite dargestellt werden, können über Sprachpakete in andere Sprachen übersetzt werden. Für die deutsche Sprache wird ein Sprachpaket mitgeliefert das auch nach Kundenwunsch angepasst werden kann.<br /> <br /> =Whitelabel=<br /> <br /> Damit neue Projekte nicht von Null begonnen werden müssen, wurden das Whitelabel-Modul erstellt. In diesem Modul sind immer die aktuellen Techniken zur Umsetzung von neuen Projekten enthalten. Dieses Modul dient als Kopiervorlage. Es wird immer auf die aktuellen Anforderungen von neuen Projekten angepasst. Hier wird keine Rücksicht auf Updatefähigkeit genommen.<br /> <br /> Das SiteKit soll die Technik enthalten die Projekt-übergreifend verwendet wird. Sitepark sorgt dafür, dass das SiteKit-Modul update-fähig ist und somit als langfristige Plattform für Projekt- und Produkt-Module verwendet werden kann.<br /> <br /> Besonders im Front-End-Bereich (CSS, JavaScript) werden etablierte Techniken schneller von neueren Techniken überholt. In diesem Bereich wäre eine langfristige update-Fähigkeit eine große Innovations-Bremse. Daher ist ein großer Teil der Front-End-Technik nicht im Sitekit-Modul, sondern im Whitelabel-Modul enthalten.<br /> <br /> Das Whitelabel-Modul besteht aus zwei Unter-Modulen<br /> <br /> ;IES-Modul:<br /> Das IES Modul enthält Eingabe-Templates, Aggregatoren, Komponenten, Renderer und Basis-Konfigurationen<br /> ;Styleguide:<br /> In diesem Modul ist ein Styleguide enthalten in dem das HTML hinterlegt ist, dass auch die Renderer erzeugen. Alle Komponenten sind nach dem Atomic-Design-Prinzip in Atome, Moleküle, Organismen und Templates erlegt und können so gestylt werden.<br /> <br /> =Kundenmodul=<br /> <br /> Ein Kundenmodul wird als Kopie von Whitelabel erzeugt. In diesem Modul werden alle Kundenspezifischen Anforderungen implementiert.<br /> <br /> =Systemarchitektur (vereinfacht)=<br /> <br /> SiteKit und Infosite6 zusammen bilden &quot;Infosite 6 Enterprise-Edition&quot; (Infosite 6 EE)<br /> <br /> <br /> [[Datei:InfoSite6-EE-Systemarchitektur-vereinfacht.png|800px]]<br /> <br /> Die '''CMS-Oberfläche''' stellt die Eingabemaken dar, die sich aus einzelnen Abschnitten zusammensetzen. Das SiteKit stellt diese Abschnitte bereit. Das Kunden-Modul enthält kundenspezifische Konfigurationen der SiteKit-Abschnitte und kundenspezifische Abschnitte.<br /> <br /> Das '''IES Repository''' hält die Artikel-Daten, die über die CMS-Oberfläche dargestellt und bearbeitet werden können.<br /> <br /> Der '''Raw Content''' wird pro Artikel als PHP-Datei vom CMS auf dem Webserver publiziert. Die Daten werden über Sitekit- und Kundenspezifischen-Aggregatoren aus dem IES Repository geladen und in einer für die Darstellung optimierten Form zusammengestellt.<br /> <br /> Die '''Renderer''' erzeugen beim Aufruf einer Seite aus dem Raw Content das gewünschte Ausgabeformat. Das SiteKit stellt Renderer zur Verfügung die kundenspezifisch angepasst werden können. Kunden-Module stellen auch eigene Renderer bereit.<br /> <br /> Mit Hilfe eines Styleguide werden für das Styling der Webseite '''CSS''' und '''JavaScript''' implementiert.</div>

Liebold https://wiki.sitepark.com/index.php?title=Scaleimage_(SP-Tag)&diff=7703 2015-10-02T08:52:03Z

<p>Liebold: /* Attribute */</p> <hr /> <div>==Name==<br /> &lt;sp:scaleimage&gt; - Verkleinert Bilder<br /> <br /> ==Syntax==<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;sp:scaleimage<br /> name=&quot;variable&quot;<br /> scope=&quot;page&quot;<br /> object=&quot;${myImageLink.link}&quot;<br /> width=&quot;40&quot;<br /> height=&quot;40&quot;<br /> padding=&quot;on&quot;<br /> background=&quot;0000FF&quot;<br /> /&gt;<br /> &lt;/source&gt; <br /> <br /> ==Beschreibung==<br /> Bilder die im [[IES]] abgelegt wurden, können mit Hilfe dieses Tags verkleinert werden (z.B. für Thumbnails). Dieser Tag kann sowohl im Eingabe- als auch im Ausgabemodus verwendet werden. Mit dem object-Attribut wird das zu verkleinernde Bild angegeben. Mit den Attributen width und height wird die Größe des Bildes definiert. Wird nur die Breite oder nur die Höhe angegeben, ergibt sich der Wert aus dem proportionalen Seitenverhältnis des Bildes. Die Daten des klein gerechneten Bildes werden in einem [[ScaleImage]]-Objekt abgelegt, das über den im Attribut &lt;code&gt;name&lt;/code&gt; angegebenen Variablennamen erreichbar ist.<br /> <br /> Für die Skalierung von Bildern gelten folgende Regeln:<br /> * Ein Bild wird immer proportional verkleinert. Das Seitenverhältnis des Bildes bleibt stets erhalten.<br /> * Bilder werden nicht vergrößert<br /> <br /> Die Verkleinerung des Bildes kann in drei unterschiedlichen Modi erfolgen:<br /> <br /> ;kein Padding (padding=&quot;off&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Das Bild wird so verkleinert, dass es komplett in den angegebenen Rahmen passt. Hierbei ist es möglich, dass entweder die Höhe oder die Breite des verkleinerten Bildes kleiner als der definierte Wert ist. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 50x50 Pixel groß sein. Sind die definierten Ausmaße größer als das Original, so bleibt das Bild unverändert.<br /> <br /> ;Padding (padding=&quot;on&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Das Bild wird so verkleinert, das es komplett in den angegebenen Rahmen passt. Hierbei ist es möglich das entweder die Höhe oder die Breite des verkleinerten Bildes kleiner als des definierten Wertes ist. In diesem Fall wird das Bild rechts und links, bzw. oben und unten mit einem Padding aufgefüllt. Die Farbe für das Padding wird mit dem Attribut background angegeben. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 50x50 Pixel groß sein und erhält links und rechts einen 25 Pixel breiten Balken in der angegebene background-Farbe. Sind die definierten Ausmaße größer als das Original, wird das Bild mit der background-Farbe aufgefüllt, so dass in jedem Fall die definierte Größe erreicht wird.<br /> <br /> ;Fit-Padding (padding=&quot;fit&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Dabei wird das Bild soweit verkleinert, bis entweder die Höhe oder die Breite in den Rahmen passt. Dabei ist es möglich, dass entweder die linke- und rechte- oder ober- und unter-Seite über den Rahmen herausragen. Die überstehenden Seiten werden abgeschnitten um die angegebene Größe zu erreichen. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 100x100 Pixel groß sein. Anschließend werden noch oben und unten 25 Pixel abgeschnitten um die angegebene größe von 100x50 Pixel zu erreichen. Sind die definierten Ausmaße größer als das Original wird das Bild mit der background-Farbe aufgefüllt, so dass in jedem Fall die definierte Größe erreicht wird.<br /> :Über die Optionen kann ein Focus-Point angegeben werden, der den Bildmittelpunkt für den Zuschnitt definiert. In diesem Fall werden die Kanten nicht gleichmäßig abgeschnitten sondern so, dass der Focus-Point möglichst die Mitte des zugeschnittenen Bildes definiert.<br /> <br /> Im Padding und Fit-Padding Modus ist immer sichergestellt, dass die angegebene Bildgröße erreicht wird.<br /> <br /> Dieser Tag verhält sich im [[Template-Modus|In-]] und im [[Template-Modus|Out-Modus]] unterschiedlich.<br /> <br /> ;Out-Modus<br /> :Wird &lt;code&gt;sp:scaleimage&lt;/code&gt; im [[Template-Modus|Out-Modus]] betrieben, wird das verkleinerte Bild in einem Verzeichnis parallel zu dem Original abgelegt. Der Verzeichnisname besteht aus dem Dateinamen des originalen Bildes mit dem Zusatz ''.scaled'' (z.B. logo.jpg.scaled für ein Bild logo.jpg). Die Bilder werden während des Publizier-Vorgangs berechnet sowie jedes mal, wenn sich das Original geändert hat.<br /> <br /> ;In-Modus<br /> :Wird sp:scaleimage im [[Template-Modus|In-Modus]] betrieben, liegen die verkleinerten Bild zusammen mit dem Original in der BinDB des [[IES]]. Im In-Modus werden nicht alle angegebenen Bildgrößen berechnet, sondern nur bestimmte Größen, die in der [[BinDB]] definiert sind. In der BinDB sind z.B. die Größen 40,h40,w50,100 definiert. Dies bedeutet folgendes:<br /> :;40<br /> ::Bild wird mit einer Höhe und Breite von 40 Pixeln mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;h40<br /> ::Bild wird mit einer Höhe von 40 Pixel und einer Breite proportional zum Original mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;w50<br /> ::Bild wird mit einer Breite von 50 Pixel und einer Höhe proportional zum Original mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;100<br /> ::Bild wird mit einer Höhe und Breite von 100 Pixeln mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> <br /> :Wird nun ein Bild von 30x30 Pixel verlangt wird das '''40'''-Bild verwendet. Wird ein 300x300 Pixel Bild verlangt, wird das '''100'''-Bild verwendet. Der Sinn dabei ist, dass nicht eine sehr große Anzahl von Bilder berechnet und in der BinDB abgelegt werden soll. Die zurückgegebenen Bilder können auf das verlangte Maß vom Browser skaliert werden. Das Padding kann über CSS-Styles erfolgen.<br /> <br /> :Dieses Verhalten der 'Skalierungs-Schritte' kann über das Attribut &lt;code&gt;scaleSteps=&quot;false&quot;&lt;/code&gt; ausgeschaltet werden. Das ist aber nur in Ausnahmefällen empfehlenswert und kann sich negativ auf die Performanz des Systems auswirken.<br /> <br /> ==Attribute==<br /> {| class=&quot;prettytable sortable&quot;<br /> |- class=&quot;hintergrundfarbe1&quot;<br /> ! Name || Type || Required || Default || ab IES Version<br /> |-<br /> | &lt;code&gt;name&lt;/code&gt;<br /> | [[Variable]]<br /> | Ja<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;object&lt;/code&gt;<br /> | [[Attribute]]<br /> | Nein<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;width&lt;/code&gt;<br /> | [[Expression]]<br /> | Ja und / oder &lt;code&gt;height&lt;/code&gt;<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;height&lt;/code&gt;<br /> | [[Expression]]<br /> | Ja und / oder &lt;code&gt;width&lt;/code&gt;<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;padding&lt;/code&gt;<br /> | [[Text]]<br /> | Nein<br /> | off (Achtung: anderer Default-Wert als bei [[spt:imp]])<br /> | 2<br /> |-<br /> | &lt;code&gt;background&lt;/code&gt;<br /> | [[Text]]<br /> | Nein<br /> | FFFFFF<br /> | 2<br /> |-<br /> | &lt;code&gt;scalesteps&lt;/code&gt;<br /> | [[Condition]]<br /> | Nein<br /> | true, wirkt sich nur im In-Modus aus<br /> | 2<br /> |-<br /> | &lt;code&gt;options&lt;/code&gt;<br /> | [[String]] (Im JSON-Format)<br /> | Nein<br /> | None<br /> | 2.11<br /> |-<br /> | &lt;code&gt;locale&lt;/code&gt;<br /> | [[Locale]]<br /> | Nein<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;scope&lt;/code&gt;<br /> | [[Scope]]<br /> | Nein<br /> | request<br /> | 2<br /> |}<br /> <br /> ;&lt;code&gt;name&lt;/code&gt;<br /> :Name der Variable für den Zugriff auf das [[ScaleImage]]-Objekt.<br /> <br /> ;&lt;code&gt;object&lt;/code&gt;<br /> :Original-Bild.<br /> <br /> ;&lt;code&gt;width&lt;/code&gt;<br /> :Breite des zu berechnenden Bildes.<br /> <br /> ;&lt;code&gt;height&lt;/code&gt;<br /> :Höhe des zu berechnenden Bildes.<br /> <br /> ;&lt;code&gt;padding&lt;/code&gt;<br /> :Der Wert &quot;on&quot; erzeugt Rahmen zur Auffüllung der Flächen um das Bild. Damit ist das resultierende Bild immer so groß. wie durch die Auflösung gefordert.<br /> <br /> :Der Wert &quot;off&quot; erzeugt keinen Rahmen zur Auffüllung der Flächen um das Bild. Damit ist das resultierende Bild unter Umständen kleiner als die geforderte Auflösung.<br /> <br /> :Mit &quot;fit&quot; wird der größtmögliche Ausschnitt aus dem Originalbild bzw. aus dem durch excerpt gewählten Ausschnitt gesucht, bei dem das Seitenverhältnis der geforderten Auflösung entspricht. Es wird kein Rahmen erzeugt, sondern das Bild in einer Dimension gegebenenfalls gekürzt.<br /> <br /> :Aufgrund von Abwärtskompatibilität wird auch der Wert &quot;yes&quot; (entspricht &quot;on&quot;) und &quot;no&quot; (entspricht &quot;off&quot;) unterstützt.<br /> <br /> ;&lt;code&gt;background&lt;/code&gt;<br /> :Hintergrundfabe für das Padding als HEX-Wert im RGB oder RGBA-Format.<br /> :Transparente Farben funktionieren nur bei PNG-Bildern.<br /> ::ffffff = weiß<br /> ::ffffff00 = transparent bei PNG, ansonsten weiß&lt;br&gt;<br /> ::00000000 = transparent bei PNG, ansonsten schwarz&lt;br&gt;<br /> <br /> ;&lt;code&gt;scalesteps&lt;/code&gt;<br /> :Schalter um das Optimierungsverhalten im In-Modus auszuschalten.<br /> <br /> ;&lt;code&gt;options&lt;/code&gt;<br /> :Mit diesem Attribut können Bild-Optionen für die Berechnung des Bildes übergeben werden. Z.Z. ist nur die Übergabe eines Focus-Point möglich<br /> :;Focus-Point<br /> ::&lt;source lang=&quot;javascript&quot;&gt;{ &quot;focuspoint&quot;: { &quot;x&quot;:0.062, &quot;y&quot;:0.527 } }&lt;/source&gt;Der Focus-Point definiert den Bereich eines Bildes, der als Mittelpunkt des Bildes angenommen werden soll, wenn über den padding-Modus 'fit' das Bild beim Verkleinern beschnitten wird.<br /> <br /> ;&lt;code&gt;locale&lt;/code&gt;<br /> :Dieses Attribut dient zur Auswahl der zu verwendende Sprache bei mehrsprachigen Variablen.<br /> <br /> ;&lt;code&gt;scope&lt;/code&gt;<br /> :[[Scope|Gültigkeitsbereich]], in dem die Variable definiert ist. Möglich sind &lt;code&gt;page&lt;/code&gt; und &lt;code&gt;request&lt;/code&gt;.<br /> <br /> ==Beispiele==<br /> <br /> ===Bild verkleinern===<br /> <br /> Template Quelltext<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;sp:scaleimage<br /> name=&quot;scaledImage&quot;<br /> object=&quot;myImage.systemlink&quot;<br /> width=&quot;40&quot;<br /> height=&quot;40&quot;<br /> padding=&quot;on&quot;<br /> background=&quot;AAAAAA&quot;/&gt;<br /> widht: &lt;sp:print name=&quot;scaledImage.widthToScale&quot;/&gt;<br /> height: &lt;sp:print name=&quot;scaledImage.heightToScale&quot;/&gt;<br /> url: &lt;sp:print name=&quot;scaledImage.url&quot;/&gt;<br /> &lt;/source&gt;<br /> <br /> Ausgabe<br /> &lt;source lang=&quot;text&quot;&gt;<br /> width: 40<br /> height: 40<br /> url: /test/test.html.media/myimage.jpg.scaled/40x40.pm1.bgAAAAAA.jpg<br /> &lt;/source&gt;<br /> <br /> <br /> &lt;noinclude&gt;<br /> [[Category:SP-Tags]]<br /> [[Category:Qualität_des_Codes_prüfen]]<br /> [[Category:Beispiel_überarbeiten_testen]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=Scaleimage_(SP-Tag)&diff=7702 2015-10-02T08:42:44Z

<p>Liebold: /* Attribute */</p> <hr /> <div>==Name==<br /> &lt;sp:scaleimage&gt; - Verkleinert Bilder<br /> <br /> ==Syntax==<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;sp:scaleimage<br /> name=&quot;variable&quot;<br /> scope=&quot;page&quot;<br /> object=&quot;${myImageLink.link}&quot;<br /> width=&quot;40&quot;<br /> height=&quot;40&quot;<br /> padding=&quot;on&quot;<br /> background=&quot;0000FF&quot;<br /> /&gt;<br /> &lt;/source&gt; <br /> <br /> ==Beschreibung==<br /> Bilder die im [[IES]] abgelegt wurden, können mit Hilfe dieses Tags verkleinert werden (z.B. für Thumbnails). Dieser Tag kann sowohl im Eingabe- als auch im Ausgabemodus verwendet werden. Mit dem object-Attribut wird das zu verkleinernde Bild angegeben. Mit den Attributen width und height wird die Größe des Bildes definiert. Wird nur die Breite oder nur die Höhe angegeben, ergibt sich der Wert aus dem proportionalen Seitenverhältnis des Bildes. Die Daten des klein gerechneten Bildes werden in einem [[ScaleImage]]-Objekt abgelegt, das über den im Attribut &lt;code&gt;name&lt;/code&gt; angegebenen Variablennamen erreichbar ist.<br /> <br /> Für die Skalierung von Bildern gelten folgende Regeln:<br /> * Ein Bild wird immer proportional verkleinert. Das Seitenverhältnis des Bildes bleibt stets erhalten.<br /> * Bilder werden nicht vergrößert<br /> <br /> Die Verkleinerung des Bildes kann in drei unterschiedlichen Modi erfolgen:<br /> <br /> ;kein Padding (padding=&quot;off&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Das Bild wird so verkleinert, dass es komplett in den angegebenen Rahmen passt. Hierbei ist es möglich, dass entweder die Höhe oder die Breite des verkleinerten Bildes kleiner als der definierte Wert ist. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 50x50 Pixel groß sein. Sind die definierten Ausmaße größer als das Original, so bleibt das Bild unverändert.<br /> <br /> ;Padding (padding=&quot;on&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Das Bild wird so verkleinert, das es komplett in den angegebenen Rahmen passt. Hierbei ist es möglich das entweder die Höhe oder die Breite des verkleinerten Bildes kleiner als des definierten Wertes ist. In diesem Fall wird das Bild rechts und links, bzw. oben und unten mit einem Padding aufgefüllt. Die Farbe für das Padding wird mit dem Attribut background angegeben. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 50x50 Pixel groß sein und erhält links und rechts einen 25 Pixel breiten Balken in der angegebene background-Farbe. Sind die definierten Ausmaße größer als das Original, wird das Bild mit der background-Farbe aufgefüllt, so dass in jedem Fall die definierte Größe erreicht wird.<br /> <br /> ;Fit-Padding (padding=&quot;fit&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Dabei wird das Bild soweit verkleinert, bis entweder die Höhe oder die Breite in den Rahmen passt. Dabei ist es möglich, dass entweder die linke- und rechte- oder ober- und unter-Seite über den Rahmen herausragen. Die überstehenden Seiten werden abgeschnitten um die angegebene Größe zu erreichen. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 100x100 Pixel groß sein. Anschließend werden noch oben und unten 25 Pixel abgeschnitten um die angegebene größe von 100x50 Pixel zu erreichen. Sind die definierten Ausmaße größer als das Original wird das Bild mit der background-Farbe aufgefüllt, so dass in jedem Fall die definierte Größe erreicht wird.<br /> :Über die Optionen kann ein Focus-Point angegeben werden, der den Bildmittelpunkt für den Zuschnitt definiert. In diesem Fall werden die Kanten nicht gleichmäßig abgeschnitten sondern so, dass der Focus-Point möglichst die Mitte des zugeschnittenen Bildes definiert.<br /> <br /> Im Padding und Fit-Padding Modus ist immer sichergestellt, dass die angegebene Bildgröße erreicht wird.<br /> <br /> Dieser Tag verhält sich im [[Template-Modus|In-]] und im [[Template-Modus|Out-Modus]] unterschiedlich.<br /> <br /> ;Out-Modus<br /> :Wird &lt;code&gt;sp:scaleimage&lt;/code&gt; im [[Template-Modus|Out-Modus]] betrieben, wird das verkleinerte Bild in einem Verzeichnis parallel zu dem Original abgelegt. Der Verzeichnisname besteht aus dem Dateinamen des originalen Bildes mit dem Zusatz ''.scaled'' (z.B. logo.jpg.scaled für ein Bild logo.jpg). Die Bilder werden während des Publizier-Vorgangs berechnet sowie jedes mal, wenn sich das Original geändert hat.<br /> <br /> ;In-Modus<br /> :Wird sp:scaleimage im [[Template-Modus|In-Modus]] betrieben, liegen die verkleinerten Bild zusammen mit dem Original in der BinDB des [[IES]]. Im In-Modus werden nicht alle angegebenen Bildgrößen berechnet, sondern nur bestimmte Größen, die in der [[BinDB]] definiert sind. In der BinDB sind z.B. die Größen 40,h40,w50,100 definiert. Dies bedeutet folgendes:<br /> :;40<br /> ::Bild wird mit einer Höhe und Breite von 40 Pixeln mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;h40<br /> ::Bild wird mit einer Höhe von 40 Pixel und einer Breite proportional zum Original mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;w50<br /> ::Bild wird mit einer Breite von 50 Pixel und einer Höhe proportional zum Original mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;100<br /> ::Bild wird mit einer Höhe und Breite von 100 Pixeln mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> <br /> :Wird nun ein Bild von 30x30 Pixel verlangt wird das '''40'''-Bild verwendet. Wird ein 300x300 Pixel Bild verlangt, wird das '''100'''-Bild verwendet. Der Sinn dabei ist, dass nicht eine sehr große Anzahl von Bilder berechnet und in der BinDB abgelegt werden soll. Die zurückgegebenen Bilder können auf das verlangte Maß vom Browser skaliert werden. Das Padding kann über CSS-Styles erfolgen.<br /> <br /> :Dieses Verhalten der 'Skalierungs-Schritte' kann über das Attribut &lt;code&gt;scaleSteps=&quot;false&quot;&lt;/code&gt; ausgeschaltet werden. Das ist aber nur in Ausnahmefällen empfehlenswert und kann sich negativ auf die Performanz des Systems auswirken.<br /> <br /> ==Attribute==<br /> {| class=&quot;prettytable sortable&quot;<br /> |- class=&quot;hintergrundfarbe1&quot;<br /> ! Name || Type || Required || Default || ab IES Version<br /> |-<br /> | &lt;code&gt;name&lt;/code&gt;<br /> | [[Variable]]<br /> | Ja<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;object&lt;/code&gt;<br /> | [[Attribute]]<br /> | Nein<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;width&lt;/code&gt;<br /> | [[Expression]]<br /> | Ja und / oder &lt;code&gt;height&lt;/code&gt;<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;height&lt;/code&gt;<br /> | [[Expression]]<br /> | Ja und / oder &lt;code&gt;width&lt;/code&gt;<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;padding&lt;/code&gt;<br /> | [[Text]]<br /> | Nein<br /> | off (Achtung: anderer Default-Wert als bei [[spt:imp]])<br /> | 2<br /> |-<br /> | &lt;code&gt;background&lt;/code&gt;<br /> | [[Text]]<br /> | Nein<br /> | FFFFFF<br /> | 2<br /> |-<br /> | &lt;code&gt;scalesteps&lt;/code&gt;<br /> | [[Condition]]<br /> | Nein<br /> | true, wirkt sich nur im In-Modus aus<br /> | 2<br /> |-<br /> | &lt;code&gt;options&lt;/code&gt;<br /> | [[String]] (Im JSON-Format)<br /> | Nein<br /> | None<br /> | 2.11<br /> |-<br /> | &lt;code&gt;locale&lt;/code&gt;<br /> | [[Locale]]<br /> | Nein<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;scope&lt;/code&gt;<br /> | [[Scope]]<br /> | Nein<br /> | request<br /> | 2<br /> |}<br /> <br /> ;&lt;code&gt;name&lt;/code&gt;<br /> :Name der Variable für den Zugriff auf das [[ScaleImage]]-Objekt.<br /> <br /> ;&lt;code&gt;object&lt;/code&gt;<br /> :Original-Bild.<br /> <br /> ;&lt;code&gt;width&lt;/code&gt;<br /> :Breite des zu berechnenden Bildes.<br /> <br /> ;&lt;code&gt;height&lt;/code&gt;<br /> :Höhe des zu berechnenden Bildes.<br /> <br /> ;&lt;code&gt;padding&lt;/code&gt;<br /> :Der Wert &quot;on&quot; erzeugt Rahmen zur Auffüllung der Flächen um das Bild. Damit ist das resultierende Bild immer so groß. wie durch die Auflösung gefordert.<br /> <br /> :Der Wert &quot;off&quot; erzeugt keinen Rahmen zur Auffüllung der Flächen um das Bild. Damit ist das resultierende Bild unter Umständen kleiner als die geforderte Auflösung.<br /> <br /> :Mit &quot;fit&quot; wird der größtmögliche Ausschnitt aus dem Originalbild bzw. aus dem durch excerpt gewählten Ausschnitt gesucht, bei dem das Seitenverhältnis der geforderten Auflösung entspricht. Es wird kein Rahmen erzeugt, sondern das Bild in einer Dimension gegebenenfalls gekürzt.<br /> <br /> :Aufgrund von Abwärtskompatibilität wird auch der Wert &quot;yes&quot; (entspricht &quot;on&quot;) und &quot;no&quot; (entspricht &quot;off&quot;) unterstützt.<br /> <br /> ;&lt;code&gt;background&lt;/code&gt;<br /> :Hintergrundfabe für das Padding Numerisch oder als als HEX-Wert im RGB oder RGBA-Format.<br /> :Transparente Farben funktionieren nur bei PNG-Bildern.<br /> &lt;source lang=&quot;text&quot;&gt;<br /> ffffff = weiß<br /> ffffff00 = transparent bei PNG, ansonsten weiß&lt;br&gt;<br /> 00000000 = transparent bei PNG, ansonsten schwarz&lt;br&gt;<br /> rgb(255,255,255,0) = transparent bei PNG, ansonsten weiß&lt;br&gt;<br /> rgb(255,255,255,128) = 50% transparent bei PNG, ansonsten weiß<br /> &lt;/source&gt;<br /> <br /> ;&lt;code&gt;scalesteps&lt;/code&gt;<br /> :Schalter um das Optimierungsverhalten im In-Modus auszuschalten.<br /> <br /> ;&lt;code&gt;options&lt;/code&gt;<br /> :Mit diesem Attribut können Bild-Optionen für die Berechnung des Bildes übergeben werden. Z.Z. ist nur die Übergabe eines Focus-Point möglich<br /> :;Focus-Point<br /> ::&lt;source lang=&quot;javascript&quot;&gt;{ &quot;focuspoint&quot;: { &quot;x&quot;:0.062, &quot;y&quot;:0.527 } }&lt;/source&gt;Der Focus-Point definiert den Bereich eines Bildes, der als Mittelpunkt des Bildes angenommen werden soll, wenn über den padding-Modus 'fit' das Bild beim Verkleinern beschnitten wird.<br /> <br /> ;&lt;code&gt;locale&lt;/code&gt;<br /> :Dieses Attribut dient zur Auswahl der zu verwendende Sprache bei mehrsprachigen Variablen.<br /> <br /> ;&lt;code&gt;scope&lt;/code&gt;<br /> :[[Scope|Gültigkeitsbereich]], in dem die Variable definiert ist. Möglich sind &lt;code&gt;page&lt;/code&gt; und &lt;code&gt;request&lt;/code&gt;.<br /> <br /> ==Beispiele==<br /> <br /> ===Bild verkleinern===<br /> <br /> Template Quelltext<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;sp:scaleimage<br /> name=&quot;scaledImage&quot;<br /> object=&quot;myImage.systemlink&quot;<br /> width=&quot;40&quot;<br /> height=&quot;40&quot;<br /> padding=&quot;on&quot;<br /> background=&quot;AAAAAA&quot;/&gt;<br /> widht: &lt;sp:print name=&quot;scaledImage.widthToScale&quot;/&gt;<br /> height: &lt;sp:print name=&quot;scaledImage.heightToScale&quot;/&gt;<br /> url: &lt;sp:print name=&quot;scaledImage.url&quot;/&gt;<br /> &lt;/source&gt;<br /> <br /> Ausgabe<br /> &lt;source lang=&quot;text&quot;&gt;<br /> width: 40<br /> height: 40<br /> url: /test/test.html.media/myimage.jpg.scaled/40x40.pm1.bgAAAAAA.jpg<br /> &lt;/source&gt;<br /> <br /> <br /> &lt;noinclude&gt;<br /> [[Category:SP-Tags]]<br /> [[Category:Qualität_des_Codes_prüfen]]<br /> [[Category:Beispiel_überarbeiten_testen]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=Scaleimage_(SP-Tag)&diff=7701 2015-10-02T08:42:04Z

<p>Liebold: /* Attribute */</p> <hr /> <div>==Name==<br /> &lt;sp:scaleimage&gt; - Verkleinert Bilder<br /> <br /> ==Syntax==<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;sp:scaleimage<br /> name=&quot;variable&quot;<br /> scope=&quot;page&quot;<br /> object=&quot;${myImageLink.link}&quot;<br /> width=&quot;40&quot;<br /> height=&quot;40&quot;<br /> padding=&quot;on&quot;<br /> background=&quot;0000FF&quot;<br /> /&gt;<br /> &lt;/source&gt; <br /> <br /> ==Beschreibung==<br /> Bilder die im [[IES]] abgelegt wurden, können mit Hilfe dieses Tags verkleinert werden (z.B. für Thumbnails). Dieser Tag kann sowohl im Eingabe- als auch im Ausgabemodus verwendet werden. Mit dem object-Attribut wird das zu verkleinernde Bild angegeben. Mit den Attributen width und height wird die Größe des Bildes definiert. Wird nur die Breite oder nur die Höhe angegeben, ergibt sich der Wert aus dem proportionalen Seitenverhältnis des Bildes. Die Daten des klein gerechneten Bildes werden in einem [[ScaleImage]]-Objekt abgelegt, das über den im Attribut &lt;code&gt;name&lt;/code&gt; angegebenen Variablennamen erreichbar ist.<br /> <br /> Für die Skalierung von Bildern gelten folgende Regeln:<br /> * Ein Bild wird immer proportional verkleinert. Das Seitenverhältnis des Bildes bleibt stets erhalten.<br /> * Bilder werden nicht vergrößert<br /> <br /> Die Verkleinerung des Bildes kann in drei unterschiedlichen Modi erfolgen:<br /> <br /> ;kein Padding (padding=&quot;off&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Das Bild wird so verkleinert, dass es komplett in den angegebenen Rahmen passt. Hierbei ist es möglich, dass entweder die Höhe oder die Breite des verkleinerten Bildes kleiner als der definierte Wert ist. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 50x50 Pixel groß sein. Sind die definierten Ausmaße größer als das Original, so bleibt das Bild unverändert.<br /> <br /> ;Padding (padding=&quot;on&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Das Bild wird so verkleinert, das es komplett in den angegebenen Rahmen passt. Hierbei ist es möglich das entweder die Höhe oder die Breite des verkleinerten Bildes kleiner als des definierten Wertes ist. In diesem Fall wird das Bild rechts und links, bzw. oben und unten mit einem Padding aufgefüllt. Die Farbe für das Padding wird mit dem Attribut background angegeben. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 50x50 Pixel groß sein und erhält links und rechts einen 25 Pixel breiten Balken in der angegebene background-Farbe. Sind die definierten Ausmaße größer als das Original, wird das Bild mit der background-Farbe aufgefüllt, so dass in jedem Fall die definierte Größe erreicht wird.<br /> <br /> ;Fit-Padding (padding=&quot;fit&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Dabei wird das Bild soweit verkleinert, bis entweder die Höhe oder die Breite in den Rahmen passt. Dabei ist es möglich, dass entweder die linke- und rechte- oder ober- und unter-Seite über den Rahmen herausragen. Die überstehenden Seiten werden abgeschnitten um die angegebene Größe zu erreichen. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 100x100 Pixel groß sein. Anschließend werden noch oben und unten 25 Pixel abgeschnitten um die angegebene größe von 100x50 Pixel zu erreichen. Sind die definierten Ausmaße größer als das Original wird das Bild mit der background-Farbe aufgefüllt, so dass in jedem Fall die definierte Größe erreicht wird.<br /> :Über die Optionen kann ein Focus-Point angegeben werden, der den Bildmittelpunkt für den Zuschnitt definiert. In diesem Fall werden die Kanten nicht gleichmäßig abgeschnitten sondern so, dass der Focus-Point möglichst die Mitte des zugeschnittenen Bildes definiert.<br /> <br /> Im Padding und Fit-Padding Modus ist immer sichergestellt, dass die angegebene Bildgröße erreicht wird.<br /> <br /> Dieser Tag verhält sich im [[Template-Modus|In-]] und im [[Template-Modus|Out-Modus]] unterschiedlich.<br /> <br /> ;Out-Modus<br /> :Wird &lt;code&gt;sp:scaleimage&lt;/code&gt; im [[Template-Modus|Out-Modus]] betrieben, wird das verkleinerte Bild in einem Verzeichnis parallel zu dem Original abgelegt. Der Verzeichnisname besteht aus dem Dateinamen des originalen Bildes mit dem Zusatz ''.scaled'' (z.B. logo.jpg.scaled für ein Bild logo.jpg). Die Bilder werden während des Publizier-Vorgangs berechnet sowie jedes mal, wenn sich das Original geändert hat.<br /> <br /> ;In-Modus<br /> :Wird sp:scaleimage im [[Template-Modus|In-Modus]] betrieben, liegen die verkleinerten Bild zusammen mit dem Original in der BinDB des [[IES]]. Im In-Modus werden nicht alle angegebenen Bildgrößen berechnet, sondern nur bestimmte Größen, die in der [[BinDB]] definiert sind. In der BinDB sind z.B. die Größen 40,h40,w50,100 definiert. Dies bedeutet folgendes:<br /> :;40<br /> ::Bild wird mit einer Höhe und Breite von 40 Pixeln mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;h40<br /> ::Bild wird mit einer Höhe von 40 Pixel und einer Breite proportional zum Original mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;w50<br /> ::Bild wird mit einer Breite von 50 Pixel und einer Höhe proportional zum Original mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;100<br /> ::Bild wird mit einer Höhe und Breite von 100 Pixeln mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> <br /> :Wird nun ein Bild von 30x30 Pixel verlangt wird das '''40'''-Bild verwendet. Wird ein 300x300 Pixel Bild verlangt, wird das '''100'''-Bild verwendet. Der Sinn dabei ist, dass nicht eine sehr große Anzahl von Bilder berechnet und in der BinDB abgelegt werden soll. Die zurückgegebenen Bilder können auf das verlangte Maß vom Browser skaliert werden. Das Padding kann über CSS-Styles erfolgen.<br /> <br /> :Dieses Verhalten der 'Skalierungs-Schritte' kann über das Attribut &lt;code&gt;scaleSteps=&quot;false&quot;&lt;/code&gt; ausgeschaltet werden. Das ist aber nur in Ausnahmefällen empfehlenswert und kann sich negativ auf die Performanz des Systems auswirken.<br /> <br /> ==Attribute==<br /> {| class=&quot;prettytable sortable&quot;<br /> |- class=&quot;hintergrundfarbe1&quot;<br /> ! Name || Type || Required || Default || ab IES Version<br /> |-<br /> | &lt;code&gt;name&lt;/code&gt;<br /> | [[Variable]]<br /> | Ja<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;object&lt;/code&gt;<br /> | [[Attribute]]<br /> | Nein<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;width&lt;/code&gt;<br /> | [[Expression]]<br /> | Ja und / oder &lt;code&gt;height&lt;/code&gt;<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;height&lt;/code&gt;<br /> | [[Expression]]<br /> | Ja und / oder &lt;code&gt;width&lt;/code&gt;<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;padding&lt;/code&gt;<br /> | [[Text]]<br /> | Nein<br /> | off (Achtung: anderer Default-Wert als bei [[spt:imp]])<br /> | 2<br /> |-<br /> | &lt;code&gt;background&lt;/code&gt;<br /> | [[Text]]<br /> | Nein<br /> | FFFFFF<br /> | 2<br /> |-<br /> | &lt;code&gt;scalesteps&lt;/code&gt;<br /> | [[Condition]]<br /> | Nein<br /> | true, wirkt sich nur im In-Modus aus<br /> | 2<br /> |-<br /> | &lt;code&gt;options&lt;/code&gt;<br /> | [[String]] (Im JSON-Format)<br /> | Nein<br /> | None<br /> | 2.11<br /> |-<br /> | &lt;code&gt;locale&lt;/code&gt;<br /> | [[Locale]]<br /> | Nein<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;scope&lt;/code&gt;<br /> | [[Scope]]<br /> | Nein<br /> | request<br /> | 2<br /> |}<br /> <br /> ;&lt;code&gt;name&lt;/code&gt;<br /> :Name der Variable für den Zugriff auf das [[ScaleImage]]-Objekt.<br /> <br /> ;&lt;code&gt;object&lt;/code&gt;<br /> :Original-Bild.<br /> <br /> ;&lt;code&gt;width&lt;/code&gt;<br /> :Breite des zu berechnenden Bildes.<br /> <br /> ;&lt;code&gt;height&lt;/code&gt;<br /> :Höhe des zu berechnenden Bildes.<br /> <br /> ;&lt;code&gt;padding&lt;/code&gt;<br /> :Der Wert &quot;on&quot; erzeugt Rahmen zur Auffüllung der Flächen um das Bild. Damit ist das resultierende Bild immer so groß. wie durch die Auflösung gefordert.<br /> <br /> :Der Wert &quot;off&quot; erzeugt keinen Rahmen zur Auffüllung der Flächen um das Bild. Damit ist das resultierende Bild unter Umständen kleiner als die geforderte Auflösung.<br /> <br /> :Mit &quot;fit&quot; wird der größtmögliche Ausschnitt aus dem Originalbild bzw. aus dem durch excerpt gewählten Ausschnitt gesucht, bei dem das Seitenverhältnis der geforderten Auflösung entspricht. Es wird kein Rahmen erzeugt, sondern das Bild in einer Dimension gegebenenfalls gekürzt.<br /> <br /> :Aufgrund von Abwärtskompatibilität wird auch der Wert &quot;yes&quot; (entspricht &quot;on&quot;) und &quot;no&quot; (entspricht &quot;off&quot;) unterstützt.<br /> <br /> ;&lt;code&gt;background&lt;/code&gt;<br /> :Hintergrundfabe für das Padding Numerisch oder als als HEX-Wert im RGB oder RGBA-Format.<br /> :Transparente Farben funktionieren nur bei PNG-Bildern.<br /> ::ttt<br /> &lt;source lang=&quot;text&quot;&gt;ffffff = weiß<br /> ffffff00 = transparent bei PNG, ansonsten weiß&lt;br&gt;<br /> 00000000 = transparent bei PNG, ansonsten schwarz&lt;br&gt;<br /> rgb(255,255,255,0) = transparent bei PNG, ansonsten weiß&lt;br&gt;<br /> rgb(255,255,255,128) = 50% transparent bei PNG, ansonsten weiß<br /> &lt;/source&gt;<br /> <br /> ;&lt;code&gt;scalesteps&lt;/code&gt;<br /> :Schalter um das Optimierungsverhalten im In-Modus auszuschalten.<br /> <br /> ;&lt;code&gt;options&lt;/code&gt;<br /> :Mit diesem Attribut können Bild-Optionen für die Berechnung des Bildes übergeben werden. Z.Z. ist nur die Übergabe eines Focus-Point möglich<br /> :;Focus-Point<br /> ::&lt;source lang=&quot;javascript&quot;&gt;{ &quot;focuspoint&quot;: { &quot;x&quot;:0.062, &quot;y&quot;:0.527 } }&lt;/source&gt;Der Focus-Point definiert den Bereich eines Bildes, der als Mittelpunkt des Bildes angenommen werden soll, wenn über den padding-Modus 'fit' das Bild beim Verkleinern beschnitten wird.<br /> <br /> ;&lt;code&gt;locale&lt;/code&gt;<br /> :Dieses Attribut dient zur Auswahl der zu verwendende Sprache bei mehrsprachigen Variablen.<br /> <br /> ;&lt;code&gt;scope&lt;/code&gt;<br /> :[[Scope|Gültigkeitsbereich]], in dem die Variable definiert ist. Möglich sind &lt;code&gt;page&lt;/code&gt; und &lt;code&gt;request&lt;/code&gt;.<br /> <br /> ==Beispiele==<br /> <br /> ===Bild verkleinern===<br /> <br /> Template Quelltext<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;sp:scaleimage<br /> name=&quot;scaledImage&quot;<br /> object=&quot;myImage.systemlink&quot;<br /> width=&quot;40&quot;<br /> height=&quot;40&quot;<br /> padding=&quot;on&quot;<br /> background=&quot;AAAAAA&quot;/&gt;<br /> widht: &lt;sp:print name=&quot;scaledImage.widthToScale&quot;/&gt;<br /> height: &lt;sp:print name=&quot;scaledImage.heightToScale&quot;/&gt;<br /> url: &lt;sp:print name=&quot;scaledImage.url&quot;/&gt;<br /> &lt;/source&gt;<br /> <br /> Ausgabe<br /> &lt;source lang=&quot;text&quot;&gt;<br /> width: 40<br /> height: 40<br /> url: /test/test.html.media/myimage.jpg.scaled/40x40.pm1.bgAAAAAA.jpg<br /> &lt;/source&gt;<br /> <br /> <br /> &lt;noinclude&gt;<br /> [[Category:SP-Tags]]<br /> [[Category:Qualität_des_Codes_prüfen]]<br /> [[Category:Beispiel_überarbeiten_testen]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=Scaleimage_(SP-Tag)&diff=7700 2015-10-02T08:41:32Z

<p>Liebold: /* Attribute */</p> <hr /> <div>==Name==<br /> &lt;sp:scaleimage&gt; - Verkleinert Bilder<br /> <br /> ==Syntax==<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;sp:scaleimage<br /> name=&quot;variable&quot;<br /> scope=&quot;page&quot;<br /> object=&quot;${myImageLink.link}&quot;<br /> width=&quot;40&quot;<br /> height=&quot;40&quot;<br /> padding=&quot;on&quot;<br /> background=&quot;0000FF&quot;<br /> /&gt;<br /> &lt;/source&gt; <br /> <br /> ==Beschreibung==<br /> Bilder die im [[IES]] abgelegt wurden, können mit Hilfe dieses Tags verkleinert werden (z.B. für Thumbnails). Dieser Tag kann sowohl im Eingabe- als auch im Ausgabemodus verwendet werden. Mit dem object-Attribut wird das zu verkleinernde Bild angegeben. Mit den Attributen width und height wird die Größe des Bildes definiert. Wird nur die Breite oder nur die Höhe angegeben, ergibt sich der Wert aus dem proportionalen Seitenverhältnis des Bildes. Die Daten des klein gerechneten Bildes werden in einem [[ScaleImage]]-Objekt abgelegt, das über den im Attribut &lt;code&gt;name&lt;/code&gt; angegebenen Variablennamen erreichbar ist.<br /> <br /> Für die Skalierung von Bildern gelten folgende Regeln:<br /> * Ein Bild wird immer proportional verkleinert. Das Seitenverhältnis des Bildes bleibt stets erhalten.<br /> * Bilder werden nicht vergrößert<br /> <br /> Die Verkleinerung des Bildes kann in drei unterschiedlichen Modi erfolgen:<br /> <br /> ;kein Padding (padding=&quot;off&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Das Bild wird so verkleinert, dass es komplett in den angegebenen Rahmen passt. Hierbei ist es möglich, dass entweder die Höhe oder die Breite des verkleinerten Bildes kleiner als der definierte Wert ist. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 50x50 Pixel groß sein. Sind die definierten Ausmaße größer als das Original, so bleibt das Bild unverändert.<br /> <br /> ;Padding (padding=&quot;on&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Das Bild wird so verkleinert, das es komplett in den angegebenen Rahmen passt. Hierbei ist es möglich das entweder die Höhe oder die Breite des verkleinerten Bildes kleiner als des definierten Wertes ist. In diesem Fall wird das Bild rechts und links, bzw. oben und unten mit einem Padding aufgefüllt. Die Farbe für das Padding wird mit dem Attribut background angegeben. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 50x50 Pixel groß sein und erhält links und rechts einen 25 Pixel breiten Balken in der angegebene background-Farbe. Sind die definierten Ausmaße größer als das Original, wird das Bild mit der background-Farbe aufgefüllt, so dass in jedem Fall die definierte Größe erreicht wird.<br /> <br /> ;Fit-Padding (padding=&quot;fit&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Dabei wird das Bild soweit verkleinert, bis entweder die Höhe oder die Breite in den Rahmen passt. Dabei ist es möglich, dass entweder die linke- und rechte- oder ober- und unter-Seite über den Rahmen herausragen. Die überstehenden Seiten werden abgeschnitten um die angegebene Größe zu erreichen. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 100x100 Pixel groß sein. Anschließend werden noch oben und unten 25 Pixel abgeschnitten um die angegebene größe von 100x50 Pixel zu erreichen. Sind die definierten Ausmaße größer als das Original wird das Bild mit der background-Farbe aufgefüllt, so dass in jedem Fall die definierte Größe erreicht wird.<br /> :Über die Optionen kann ein Focus-Point angegeben werden, der den Bildmittelpunkt für den Zuschnitt definiert. In diesem Fall werden die Kanten nicht gleichmäßig abgeschnitten sondern so, dass der Focus-Point möglichst die Mitte des zugeschnittenen Bildes definiert.<br /> <br /> Im Padding und Fit-Padding Modus ist immer sichergestellt, dass die angegebene Bildgröße erreicht wird.<br /> <br /> Dieser Tag verhält sich im [[Template-Modus|In-]] und im [[Template-Modus|Out-Modus]] unterschiedlich.<br /> <br /> ;Out-Modus<br /> :Wird &lt;code&gt;sp:scaleimage&lt;/code&gt; im [[Template-Modus|Out-Modus]] betrieben, wird das verkleinerte Bild in einem Verzeichnis parallel zu dem Original abgelegt. Der Verzeichnisname besteht aus dem Dateinamen des originalen Bildes mit dem Zusatz ''.scaled'' (z.B. logo.jpg.scaled für ein Bild logo.jpg). Die Bilder werden während des Publizier-Vorgangs berechnet sowie jedes mal, wenn sich das Original geändert hat.<br /> <br /> ;In-Modus<br /> :Wird sp:scaleimage im [[Template-Modus|In-Modus]] betrieben, liegen die verkleinerten Bild zusammen mit dem Original in der BinDB des [[IES]]. Im In-Modus werden nicht alle angegebenen Bildgrößen berechnet, sondern nur bestimmte Größen, die in der [[BinDB]] definiert sind. In der BinDB sind z.B. die Größen 40,h40,w50,100 definiert. Dies bedeutet folgendes:<br /> :;40<br /> ::Bild wird mit einer Höhe und Breite von 40 Pixeln mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;h40<br /> ::Bild wird mit einer Höhe von 40 Pixel und einer Breite proportional zum Original mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;w50<br /> ::Bild wird mit einer Breite von 50 Pixel und einer Höhe proportional zum Original mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;100<br /> ::Bild wird mit einer Höhe und Breite von 100 Pixeln mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> <br /> :Wird nun ein Bild von 30x30 Pixel verlangt wird das '''40'''-Bild verwendet. Wird ein 300x300 Pixel Bild verlangt, wird das '''100'''-Bild verwendet. Der Sinn dabei ist, dass nicht eine sehr große Anzahl von Bilder berechnet und in der BinDB abgelegt werden soll. Die zurückgegebenen Bilder können auf das verlangte Maß vom Browser skaliert werden. Das Padding kann über CSS-Styles erfolgen.<br /> <br /> :Dieses Verhalten der 'Skalierungs-Schritte' kann über das Attribut &lt;code&gt;scaleSteps=&quot;false&quot;&lt;/code&gt; ausgeschaltet werden. Das ist aber nur in Ausnahmefällen empfehlenswert und kann sich negativ auf die Performanz des Systems auswirken.<br /> <br /> ==Attribute==<br /> {| class=&quot;prettytable sortable&quot;<br /> |- class=&quot;hintergrundfarbe1&quot;<br /> ! Name || Type || Required || Default || ab IES Version<br /> |-<br /> | &lt;code&gt;name&lt;/code&gt;<br /> | [[Variable]]<br /> | Ja<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;object&lt;/code&gt;<br /> | [[Attribute]]<br /> | Nein<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;width&lt;/code&gt;<br /> | [[Expression]]<br /> | Ja und / oder &lt;code&gt;height&lt;/code&gt;<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;height&lt;/code&gt;<br /> | [[Expression]]<br /> | Ja und / oder &lt;code&gt;width&lt;/code&gt;<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;padding&lt;/code&gt;<br /> | [[Text]]<br /> | Nein<br /> | off (Achtung: anderer Default-Wert als bei [[spt:imp]])<br /> | 2<br /> |-<br /> | &lt;code&gt;background&lt;/code&gt;<br /> | [[Text]]<br /> | Nein<br /> | FFFFFF<br /> | 2<br /> |-<br /> | &lt;code&gt;scalesteps&lt;/code&gt;<br /> | [[Condition]]<br /> | Nein<br /> | true, wirkt sich nur im In-Modus aus<br /> | 2<br /> |-<br /> | &lt;code&gt;options&lt;/code&gt;<br /> | [[String]] (Im JSON-Format)<br /> | Nein<br /> | None<br /> | 2.11<br /> |-<br /> | &lt;code&gt;locale&lt;/code&gt;<br /> | [[Locale]]<br /> | Nein<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;scope&lt;/code&gt;<br /> | [[Scope]]<br /> | Nein<br /> | request<br /> | 2<br /> |}<br /> <br /> ;&lt;code&gt;name&lt;/code&gt;<br /> :Name der Variable für den Zugriff auf das [[ScaleImage]]-Objekt.<br /> <br /> ;&lt;code&gt;object&lt;/code&gt;<br /> :Original-Bild.<br /> <br /> ;&lt;code&gt;width&lt;/code&gt;<br /> :Breite des zu berechnenden Bildes.<br /> <br /> ;&lt;code&gt;height&lt;/code&gt;<br /> :Höhe des zu berechnenden Bildes.<br /> <br /> ;&lt;code&gt;padding&lt;/code&gt;<br /> :Der Wert &quot;on&quot; erzeugt Rahmen zur Auffüllung der Flächen um das Bild. Damit ist das resultierende Bild immer so groß. wie durch die Auflösung gefordert.<br /> <br /> :Der Wert &quot;off&quot; erzeugt keinen Rahmen zur Auffüllung der Flächen um das Bild. Damit ist das resultierende Bild unter Umständen kleiner als die geforderte Auflösung.<br /> <br /> :Mit &quot;fit&quot; wird der größtmögliche Ausschnitt aus dem Originalbild bzw. aus dem durch excerpt gewählten Ausschnitt gesucht, bei dem das Seitenverhältnis der geforderten Auflösung entspricht. Es wird kein Rahmen erzeugt, sondern das Bild in einer Dimension gegebenenfalls gekürzt.<br /> <br /> :Aufgrund von Abwärtskompatibilität wird auch der Wert &quot;yes&quot; (entspricht &quot;on&quot;) und &quot;no&quot; (entspricht &quot;off&quot;) unterstützt.<br /> <br /> ;&lt;code&gt;background&lt;/code&gt;<br /> :Hintergrundfabe für das Padding Numerisch oder als als HEX-Wert im RGB oder RGBA-Format.<br /> :Transparente Farben funktionieren nur bei PNG-Bildern.<br /> ::&lt;source lang=&quot;text&quot;&gt;ffffff = weiß&lt;br&gt;ffffff00 = transparent bei PNG, ansonsten weiß&lt;br&gt;<br /> 00000000 = transparent bei PNG, ansonsten schwarz&lt;br&gt;<br /> rgb(255,255,255,0) = transparent bei PNG, ansonsten weiß&lt;br&gt;<br /> rgb(255,255,255,128) = 50% transparent bei PNG, ansonsten weiß<br /> &lt;/source&gt;<br /> <br /> ;&lt;code&gt;scalesteps&lt;/code&gt;<br /> :Schalter um das Optimierungsverhalten im In-Modus auszuschalten.<br /> <br /> ;&lt;code&gt;options&lt;/code&gt;<br /> :Mit diesem Attribut können Bild-Optionen für die Berechnung des Bildes übergeben werden. Z.Z. ist nur die Übergabe eines Focus-Point möglich<br /> :;Focus-Point<br /> ::&lt;source lang=&quot;javascript&quot;&gt;{ &quot;focuspoint&quot;: { &quot;x&quot;:0.062, &quot;y&quot;:0.527 } }&lt;/source&gt;Der Focus-Point definiert den Bereich eines Bildes, der als Mittelpunkt des Bildes angenommen werden soll, wenn über den padding-Modus 'fit' das Bild beim Verkleinern beschnitten wird.<br /> <br /> ;&lt;code&gt;locale&lt;/code&gt;<br /> :Dieses Attribut dient zur Auswahl der zu verwendende Sprache bei mehrsprachigen Variablen.<br /> <br /> ;&lt;code&gt;scope&lt;/code&gt;<br /> :[[Scope|Gültigkeitsbereich]], in dem die Variable definiert ist. Möglich sind &lt;code&gt;page&lt;/code&gt; und &lt;code&gt;request&lt;/code&gt;.<br /> <br /> ==Beispiele==<br /> <br /> ===Bild verkleinern===<br /> <br /> Template Quelltext<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;sp:scaleimage<br /> name=&quot;scaledImage&quot;<br /> object=&quot;myImage.systemlink&quot;<br /> width=&quot;40&quot;<br /> height=&quot;40&quot;<br /> padding=&quot;on&quot;<br /> background=&quot;AAAAAA&quot;/&gt;<br /> widht: &lt;sp:print name=&quot;scaledImage.widthToScale&quot;/&gt;<br /> height: &lt;sp:print name=&quot;scaledImage.heightToScale&quot;/&gt;<br /> url: &lt;sp:print name=&quot;scaledImage.url&quot;/&gt;<br /> &lt;/source&gt;<br /> <br /> Ausgabe<br /> &lt;source lang=&quot;text&quot;&gt;<br /> width: 40<br /> height: 40<br /> url: /test/test.html.media/myimage.jpg.scaled/40x40.pm1.bgAAAAAA.jpg<br /> &lt;/source&gt;<br /> <br /> <br /> &lt;noinclude&gt;<br /> [[Category:SP-Tags]]<br /> [[Category:Qualität_des_Codes_prüfen]]<br /> [[Category:Beispiel_überarbeiten_testen]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=Scaleimage_(SP-Tag)&diff=7699 2015-10-02T08:40:43Z

<p>Liebold: /* Attribute */</p> <hr /> <div>==Name==<br /> &lt;sp:scaleimage&gt; - Verkleinert Bilder<br /> <br /> ==Syntax==<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;sp:scaleimage<br /> name=&quot;variable&quot;<br /> scope=&quot;page&quot;<br /> object=&quot;${myImageLink.link}&quot;<br /> width=&quot;40&quot;<br /> height=&quot;40&quot;<br /> padding=&quot;on&quot;<br /> background=&quot;0000FF&quot;<br /> /&gt;<br /> &lt;/source&gt; <br /> <br /> ==Beschreibung==<br /> Bilder die im [[IES]] abgelegt wurden, können mit Hilfe dieses Tags verkleinert werden (z.B. für Thumbnails). Dieser Tag kann sowohl im Eingabe- als auch im Ausgabemodus verwendet werden. Mit dem object-Attribut wird das zu verkleinernde Bild angegeben. Mit den Attributen width und height wird die Größe des Bildes definiert. Wird nur die Breite oder nur die Höhe angegeben, ergibt sich der Wert aus dem proportionalen Seitenverhältnis des Bildes. Die Daten des klein gerechneten Bildes werden in einem [[ScaleImage]]-Objekt abgelegt, das über den im Attribut &lt;code&gt;name&lt;/code&gt; angegebenen Variablennamen erreichbar ist.<br /> <br /> Für die Skalierung von Bildern gelten folgende Regeln:<br /> * Ein Bild wird immer proportional verkleinert. Das Seitenverhältnis des Bildes bleibt stets erhalten.<br /> * Bilder werden nicht vergrößert<br /> <br /> Die Verkleinerung des Bildes kann in drei unterschiedlichen Modi erfolgen:<br /> <br /> ;kein Padding (padding=&quot;off&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Das Bild wird so verkleinert, dass es komplett in den angegebenen Rahmen passt. Hierbei ist es möglich, dass entweder die Höhe oder die Breite des verkleinerten Bildes kleiner als der definierte Wert ist. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 50x50 Pixel groß sein. Sind die definierten Ausmaße größer als das Original, so bleibt das Bild unverändert.<br /> <br /> ;Padding (padding=&quot;on&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Das Bild wird so verkleinert, das es komplett in den angegebenen Rahmen passt. Hierbei ist es möglich das entweder die Höhe oder die Breite des verkleinerten Bildes kleiner als des definierten Wertes ist. In diesem Fall wird das Bild rechts und links, bzw. oben und unten mit einem Padding aufgefüllt. Die Farbe für das Padding wird mit dem Attribut background angegeben. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 50x50 Pixel groß sein und erhält links und rechts einen 25 Pixel breiten Balken in der angegebene background-Farbe. Sind die definierten Ausmaße größer als das Original, wird das Bild mit der background-Farbe aufgefüllt, so dass in jedem Fall die definierte Größe erreicht wird.<br /> <br /> ;Fit-Padding (padding=&quot;fit&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Dabei wird das Bild soweit verkleinert, bis entweder die Höhe oder die Breite in den Rahmen passt. Dabei ist es möglich, dass entweder die linke- und rechte- oder ober- und unter-Seite über den Rahmen herausragen. Die überstehenden Seiten werden abgeschnitten um die angegebene Größe zu erreichen. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 100x100 Pixel groß sein. Anschließend werden noch oben und unten 25 Pixel abgeschnitten um die angegebene größe von 100x50 Pixel zu erreichen. Sind die definierten Ausmaße größer als das Original wird das Bild mit der background-Farbe aufgefüllt, so dass in jedem Fall die definierte Größe erreicht wird.<br /> :Über die Optionen kann ein Focus-Point angegeben werden, der den Bildmittelpunkt für den Zuschnitt definiert. In diesem Fall werden die Kanten nicht gleichmäßig abgeschnitten sondern so, dass der Focus-Point möglichst die Mitte des zugeschnittenen Bildes definiert.<br /> <br /> Im Padding und Fit-Padding Modus ist immer sichergestellt, dass die angegebene Bildgröße erreicht wird.<br /> <br /> Dieser Tag verhält sich im [[Template-Modus|In-]] und im [[Template-Modus|Out-Modus]] unterschiedlich.<br /> <br /> ;Out-Modus<br /> :Wird &lt;code&gt;sp:scaleimage&lt;/code&gt; im [[Template-Modus|Out-Modus]] betrieben, wird das verkleinerte Bild in einem Verzeichnis parallel zu dem Original abgelegt. Der Verzeichnisname besteht aus dem Dateinamen des originalen Bildes mit dem Zusatz ''.scaled'' (z.B. logo.jpg.scaled für ein Bild logo.jpg). Die Bilder werden während des Publizier-Vorgangs berechnet sowie jedes mal, wenn sich das Original geändert hat.<br /> <br /> ;In-Modus<br /> :Wird sp:scaleimage im [[Template-Modus|In-Modus]] betrieben, liegen die verkleinerten Bild zusammen mit dem Original in der BinDB des [[IES]]. Im In-Modus werden nicht alle angegebenen Bildgrößen berechnet, sondern nur bestimmte Größen, die in der [[BinDB]] definiert sind. In der BinDB sind z.B. die Größen 40,h40,w50,100 definiert. Dies bedeutet folgendes:<br /> :;40<br /> ::Bild wird mit einer Höhe und Breite von 40 Pixeln mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;h40<br /> ::Bild wird mit einer Höhe von 40 Pixel und einer Breite proportional zum Original mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;w50<br /> ::Bild wird mit einer Breite von 50 Pixel und einer Höhe proportional zum Original mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;100<br /> ::Bild wird mit einer Höhe und Breite von 100 Pixeln mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> <br /> :Wird nun ein Bild von 30x30 Pixel verlangt wird das '''40'''-Bild verwendet. Wird ein 300x300 Pixel Bild verlangt, wird das '''100'''-Bild verwendet. Der Sinn dabei ist, dass nicht eine sehr große Anzahl von Bilder berechnet und in der BinDB abgelegt werden soll. Die zurückgegebenen Bilder können auf das verlangte Maß vom Browser skaliert werden. Das Padding kann über CSS-Styles erfolgen.<br /> <br /> :Dieses Verhalten der 'Skalierungs-Schritte' kann über das Attribut &lt;code&gt;scaleSteps=&quot;false&quot;&lt;/code&gt; ausgeschaltet werden. Das ist aber nur in Ausnahmefällen empfehlenswert und kann sich negativ auf die Performanz des Systems auswirken.<br /> <br /> ==Attribute==<br /> {| class=&quot;prettytable sortable&quot;<br /> |- class=&quot;hintergrundfarbe1&quot;<br /> ! Name || Type || Required || Default || ab IES Version<br /> |-<br /> | &lt;code&gt;name&lt;/code&gt;<br /> | [[Variable]]<br /> | Ja<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;object&lt;/code&gt;<br /> | [[Attribute]]<br /> | Nein<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;width&lt;/code&gt;<br /> | [[Expression]]<br /> | Ja und / oder &lt;code&gt;height&lt;/code&gt;<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;height&lt;/code&gt;<br /> | [[Expression]]<br /> | Ja und / oder &lt;code&gt;width&lt;/code&gt;<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;padding&lt;/code&gt;<br /> | [[Text]]<br /> | Nein<br /> | off (Achtung: anderer Default-Wert als bei [[spt:imp]])<br /> | 2<br /> |-<br /> | &lt;code&gt;background&lt;/code&gt;<br /> | [[Text]]<br /> | Nein<br /> | FFFFFF<br /> | 2<br /> |-<br /> | &lt;code&gt;scalesteps&lt;/code&gt;<br /> | [[Condition]]<br /> | Nein<br /> | true, wirkt sich nur im In-Modus aus<br /> | 2<br /> |-<br /> | &lt;code&gt;options&lt;/code&gt;<br /> | [[String]] (Im JSON-Format)<br /> | Nein<br /> | None<br /> | 2.11<br /> |-<br /> | &lt;code&gt;locale&lt;/code&gt;<br /> | [[Locale]]<br /> | Nein<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;scope&lt;/code&gt;<br /> | [[Scope]]<br /> | Nein<br /> | request<br /> | 2<br /> |}<br /> <br /> ;&lt;code&gt;name&lt;/code&gt;<br /> :Name der Variable für den Zugriff auf das [[ScaleImage]]-Objekt.<br /> <br /> ;&lt;code&gt;object&lt;/code&gt;<br /> :Original-Bild.<br /> <br /> ;&lt;code&gt;width&lt;/code&gt;<br /> :Breite des zu berechnenden Bildes.<br /> <br /> ;&lt;code&gt;height&lt;/code&gt;<br /> :Höhe des zu berechnenden Bildes.<br /> <br /> ;&lt;code&gt;padding&lt;/code&gt;<br /> :Der Wert &quot;on&quot; erzeugt Rahmen zur Auffüllung der Flächen um das Bild. Damit ist das resultierende Bild immer so groß. wie durch die Auflösung gefordert.<br /> <br /> :Der Wert &quot;off&quot; erzeugt keinen Rahmen zur Auffüllung der Flächen um das Bild. Damit ist das resultierende Bild unter Umständen kleiner als die geforderte Auflösung.<br /> <br /> :Mit &quot;fit&quot; wird der größtmögliche Ausschnitt aus dem Originalbild bzw. aus dem durch excerpt gewählten Ausschnitt gesucht, bei dem das Seitenverhältnis der geforderten Auflösung entspricht. Es wird kein Rahmen erzeugt, sondern das Bild in einer Dimension gegebenenfalls gekürzt.<br /> <br /> :Aufgrund von Abwärtskompatibilität wird auch der Wert &quot;yes&quot; (entspricht &quot;on&quot;) und &quot;no&quot; (entspricht &quot;off&quot;) unterstützt.<br /> <br /> ;&lt;code&gt;background&lt;/code&gt;<br /> :Hintergrundfabe für das Padding Numerisch oder als als HEX-Wert im RGB oder RGBA-Format.<br /> :Transparente Farben funktionieren nur bei PNG-Bildern.<br /> ::&lt;source lang=&quot;text&quot;&gt;ffffff = weiß&lt;br&gt;ffffff00 = transparent bei PNG, ansonsten weiß&lt;br&gt;<br /> 00000000 = transparent bei PNG, ansonsten schwarz&lt;br&gt;<br /> rgb(255,255,255,0) = transparent bei PNG, ansonsten weiß&lt;br&gt;<br /> rgb(255,255,255,128) = 50% transparent bei PNG, ansonsten weiß<br /> &lt;/souce&gt;<br /> <br /> ;&lt;code&gt;scalesteps&lt;/code&gt;<br /> :Schalter um das Optimierungsverhalten im In-Modus auszuschalten.<br /> <br /> ;&lt;code&gt;options&lt;/code&gt;<br /> :Mit diesem Attribut können Bild-Optionen für die Berechnung des Bildes übergeben werden. Z.Z. ist nur die Übergabe eines Focus-Point möglich<br /> :;Focus-Point<br /> ::&lt;source lang=&quot;javascript&quot;&gt;{ &quot;focuspoint&quot;: { &quot;x&quot;:0.062, &quot;y&quot;:0.527 } }&lt;/source&gt;Der Focus-Point definiert den Bereich eines Bildes, der als Mittelpunkt des Bildes angenommen werden soll, wenn über den padding-Modus 'fit' das Bild beim Verkleinern beschnitten wird.<br /> <br /> ;&lt;code&gt;locale&lt;/code&gt;<br /> :Dieses Attribut dient zur Auswahl der zu verwendende Sprache bei mehrsprachigen Variablen.<br /> <br /> ;&lt;code&gt;scope&lt;/code&gt;<br /> :[[Scope|Gültigkeitsbereich]], in dem die Variable definiert ist. Möglich sind &lt;code&gt;page&lt;/code&gt; und &lt;code&gt;request&lt;/code&gt;.<br /> <br /> ==Beispiele==<br /> <br /> ===Bild verkleinern===<br /> <br /> Template Quelltext<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;sp:scaleimage<br /> name=&quot;scaledImage&quot;<br /> object=&quot;myImage.systemlink&quot;<br /> width=&quot;40&quot;<br /> height=&quot;40&quot;<br /> padding=&quot;on&quot;<br /> background=&quot;AAAAAA&quot;/&gt;<br /> widht: &lt;sp:print name=&quot;scaledImage.widthToScale&quot;/&gt;<br /> height: &lt;sp:print name=&quot;scaledImage.heightToScale&quot;/&gt;<br /> url: &lt;sp:print name=&quot;scaledImage.url&quot;/&gt;<br /> &lt;/source&gt;<br /> <br /> Ausgabe<br /> &lt;source lang=&quot;text&quot;&gt;<br /> width: 40<br /> height: 40<br /> url: /test/test.html.media/myimage.jpg.scaled/40x40.pm1.bgAAAAAA.jpg<br /> &lt;/source&gt;<br /> <br /> <br /> &lt;noinclude&gt;<br /> [[Category:SP-Tags]]<br /> [[Category:Qualität_des_Codes_prüfen]]<br /> [[Category:Beispiel_überarbeiten_testen]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=Scaleimage_(SP-Tag)&diff=7698 2015-10-02T08:39:53Z

<p>Liebold: /* Attribute */</p> <hr /> <div>==Name==<br /> &lt;sp:scaleimage&gt; - Verkleinert Bilder<br /> <br /> ==Syntax==<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;sp:scaleimage<br /> name=&quot;variable&quot;<br /> scope=&quot;page&quot;<br /> object=&quot;${myImageLink.link}&quot;<br /> width=&quot;40&quot;<br /> height=&quot;40&quot;<br /> padding=&quot;on&quot;<br /> background=&quot;0000FF&quot;<br /> /&gt;<br /> &lt;/source&gt; <br /> <br /> ==Beschreibung==<br /> Bilder die im [[IES]] abgelegt wurden, können mit Hilfe dieses Tags verkleinert werden (z.B. für Thumbnails). Dieser Tag kann sowohl im Eingabe- als auch im Ausgabemodus verwendet werden. Mit dem object-Attribut wird das zu verkleinernde Bild angegeben. Mit den Attributen width und height wird die Größe des Bildes definiert. Wird nur die Breite oder nur die Höhe angegeben, ergibt sich der Wert aus dem proportionalen Seitenverhältnis des Bildes. Die Daten des klein gerechneten Bildes werden in einem [[ScaleImage]]-Objekt abgelegt, das über den im Attribut &lt;code&gt;name&lt;/code&gt; angegebenen Variablennamen erreichbar ist.<br /> <br /> Für die Skalierung von Bildern gelten folgende Regeln:<br /> * Ein Bild wird immer proportional verkleinert. Das Seitenverhältnis des Bildes bleibt stets erhalten.<br /> * Bilder werden nicht vergrößert<br /> <br /> Die Verkleinerung des Bildes kann in drei unterschiedlichen Modi erfolgen:<br /> <br /> ;kein Padding (padding=&quot;off&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Das Bild wird so verkleinert, dass es komplett in den angegebenen Rahmen passt. Hierbei ist es möglich, dass entweder die Höhe oder die Breite des verkleinerten Bildes kleiner als der definierte Wert ist. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 50x50 Pixel groß sein. Sind die definierten Ausmaße größer als das Original, so bleibt das Bild unverändert.<br /> <br /> ;Padding (padding=&quot;on&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Das Bild wird so verkleinert, das es komplett in den angegebenen Rahmen passt. Hierbei ist es möglich das entweder die Höhe oder die Breite des verkleinerten Bildes kleiner als des definierten Wertes ist. In diesem Fall wird das Bild rechts und links, bzw. oben und unten mit einem Padding aufgefüllt. Die Farbe für das Padding wird mit dem Attribut background angegeben. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 50x50 Pixel groß sein und erhält links und rechts einen 25 Pixel breiten Balken in der angegebene background-Farbe. Sind die definierten Ausmaße größer als das Original, wird das Bild mit der background-Farbe aufgefüllt, so dass in jedem Fall die definierte Größe erreicht wird.<br /> <br /> ;Fit-Padding (padding=&quot;fit&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Dabei wird das Bild soweit verkleinert, bis entweder die Höhe oder die Breite in den Rahmen passt. Dabei ist es möglich, dass entweder die linke- und rechte- oder ober- und unter-Seite über den Rahmen herausragen. Die überstehenden Seiten werden abgeschnitten um die angegebene Größe zu erreichen. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 100x100 Pixel groß sein. Anschließend werden noch oben und unten 25 Pixel abgeschnitten um die angegebene größe von 100x50 Pixel zu erreichen. Sind die definierten Ausmaße größer als das Original wird das Bild mit der background-Farbe aufgefüllt, so dass in jedem Fall die definierte Größe erreicht wird.<br /> :Über die Optionen kann ein Focus-Point angegeben werden, der den Bildmittelpunkt für den Zuschnitt definiert. In diesem Fall werden die Kanten nicht gleichmäßig abgeschnitten sondern so, dass der Focus-Point möglichst die Mitte des zugeschnittenen Bildes definiert.<br /> <br /> Im Padding und Fit-Padding Modus ist immer sichergestellt, dass die angegebene Bildgröße erreicht wird.<br /> <br /> Dieser Tag verhält sich im [[Template-Modus|In-]] und im [[Template-Modus|Out-Modus]] unterschiedlich.<br /> <br /> ;Out-Modus<br /> :Wird &lt;code&gt;sp:scaleimage&lt;/code&gt; im [[Template-Modus|Out-Modus]] betrieben, wird das verkleinerte Bild in einem Verzeichnis parallel zu dem Original abgelegt. Der Verzeichnisname besteht aus dem Dateinamen des originalen Bildes mit dem Zusatz ''.scaled'' (z.B. logo.jpg.scaled für ein Bild logo.jpg). Die Bilder werden während des Publizier-Vorgangs berechnet sowie jedes mal, wenn sich das Original geändert hat.<br /> <br /> ;In-Modus<br /> :Wird sp:scaleimage im [[Template-Modus|In-Modus]] betrieben, liegen die verkleinerten Bild zusammen mit dem Original in der BinDB des [[IES]]. Im In-Modus werden nicht alle angegebenen Bildgrößen berechnet, sondern nur bestimmte Größen, die in der [[BinDB]] definiert sind. In der BinDB sind z.B. die Größen 40,h40,w50,100 definiert. Dies bedeutet folgendes:<br /> :;40<br /> ::Bild wird mit einer Höhe und Breite von 40 Pixeln mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;h40<br /> ::Bild wird mit einer Höhe von 40 Pixel und einer Breite proportional zum Original mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;w50<br /> ::Bild wird mit einer Breite von 50 Pixel und einer Höhe proportional zum Original mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;100<br /> ::Bild wird mit einer Höhe und Breite von 100 Pixeln mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> <br /> :Wird nun ein Bild von 30x30 Pixel verlangt wird das '''40'''-Bild verwendet. Wird ein 300x300 Pixel Bild verlangt, wird das '''100'''-Bild verwendet. Der Sinn dabei ist, dass nicht eine sehr große Anzahl von Bilder berechnet und in der BinDB abgelegt werden soll. Die zurückgegebenen Bilder können auf das verlangte Maß vom Browser skaliert werden. Das Padding kann über CSS-Styles erfolgen.<br /> <br /> :Dieses Verhalten der 'Skalierungs-Schritte' kann über das Attribut &lt;code&gt;scaleSteps=&quot;false&quot;&lt;/code&gt; ausgeschaltet werden. Das ist aber nur in Ausnahmefällen empfehlenswert und kann sich negativ auf die Performanz des Systems auswirken.<br /> <br /> ==Attribute==<br /> {| class=&quot;prettytable sortable&quot;<br /> |- class=&quot;hintergrundfarbe1&quot;<br /> ! Name || Type || Required || Default || ab IES Version<br /> |-<br /> | &lt;code&gt;name&lt;/code&gt;<br /> | [[Variable]]<br /> | Ja<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;object&lt;/code&gt;<br /> | [[Attribute]]<br /> | Nein<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;width&lt;/code&gt;<br /> | [[Expression]]<br /> | Ja und / oder &lt;code&gt;height&lt;/code&gt;<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;height&lt;/code&gt;<br /> | [[Expression]]<br /> | Ja und / oder &lt;code&gt;width&lt;/code&gt;<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;padding&lt;/code&gt;<br /> | [[Text]]<br /> | Nein<br /> | off (Achtung: anderer Default-Wert als bei [[spt:imp]])<br /> | 2<br /> |-<br /> | &lt;code&gt;background&lt;/code&gt;<br /> | [[Text]]<br /> | Nein<br /> | FFFFFF<br /> | 2<br /> |-<br /> | &lt;code&gt;scalesteps&lt;/code&gt;<br /> | [[Condition]]<br /> | Nein<br /> | true, wirkt sich nur im In-Modus aus<br /> | 2<br /> |-<br /> | &lt;code&gt;options&lt;/code&gt;<br /> | [[String]] (Im JSON-Format)<br /> | Nein<br /> | None<br /> | 2.11<br /> |-<br /> | &lt;code&gt;locale&lt;/code&gt;<br /> | [[Locale]]<br /> | Nein<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;scope&lt;/code&gt;<br /> | [[Scope]]<br /> | Nein<br /> | request<br /> | 2<br /> |}<br /> <br /> ;&lt;code&gt;name&lt;/code&gt;<br /> :Name der Variable für den Zugriff auf das [[ScaleImage]]-Objekt.<br /> <br /> ;&lt;code&gt;object&lt;/code&gt;<br /> :Original-Bild.<br /> <br /> ;&lt;code&gt;width&lt;/code&gt;<br /> :Breite des zu berechnenden Bildes.<br /> <br /> ;&lt;code&gt;height&lt;/code&gt;<br /> :Höhe des zu berechnenden Bildes.<br /> <br /> ;&lt;code&gt;padding&lt;/code&gt;<br /> :Der Wert &quot;on&quot; erzeugt Rahmen zur Auffüllung der Flächen um das Bild. Damit ist das resultierende Bild immer so groß. wie durch die Auflösung gefordert.<br /> <br /> :Der Wert &quot;off&quot; erzeugt keinen Rahmen zur Auffüllung der Flächen um das Bild. Damit ist das resultierende Bild unter Umständen kleiner als die geforderte Auflösung.<br /> <br /> :Mit &quot;fit&quot; wird der größtmögliche Ausschnitt aus dem Originalbild bzw. aus dem durch excerpt gewählten Ausschnitt gesucht, bei dem das Seitenverhältnis der geforderten Auflösung entspricht. Es wird kein Rahmen erzeugt, sondern das Bild in einer Dimension gegebenenfalls gekürzt.<br /> <br /> :Aufgrund von Abwärtskompatibilität wird auch der Wert &quot;yes&quot; (entspricht &quot;on&quot;) und &quot;no&quot; (entspricht &quot;off&quot;) unterstützt.<br /> <br /> ;&lt;code&gt;background&lt;/code&gt;<br /> :Hintergrundfabe für das Padding Numerisch oder als als HEX-Wert im RGB oder RGBA-Format.<br /> :Transparente Farben funktionieren nur bei PNG-Bildern.<br /> ::&lt;source lang=&quot;text&quot;&gt;ffffff = weiß&lt;br&gt;ffffff00 = transparent bei PNG, ansonsten weiß&lt;br&gt;00000000 = transparent bei PNG, ansonsten schwarz&lt;br&gt;rgb(255,255,255,0) = transparent bei PNG, ansonsten weiß&lt;br&gt;rgb(255,255,255,128) = 50% transparent bei PNG, ansonsten weiß&lt;/souce&gt;<br /> <br /> ;&lt;code&gt;scalesteps&lt;/code&gt;<br /> :Schalter um das Optimierungsverhalten im In-Modus auszuschalten.<br /> <br /> ;&lt;code&gt;options&lt;/code&gt;<br /> :Mit diesem Attribut können Bild-Optionen für die Berechnung des Bildes übergeben werden. Z.Z. ist nur die Übergabe eines Focus-Point möglich<br /> :;Focus-Point<br /> ::&lt;source lang=&quot;javascript&quot;&gt;{ &quot;focuspoint&quot;: { &quot;x&quot;:0.062, &quot;y&quot;:0.527 } }&lt;/source&gt;Der Focus-Point definiert den Bereich eines Bildes, der als Mittelpunkt des Bildes angenommen werden soll, wenn über den padding-Modus 'fit' das Bild beim Verkleinern beschnitten wird.<br /> <br /> ;&lt;code&gt;locale&lt;/code&gt;<br /> :Dieses Attribut dient zur Auswahl der zu verwendende Sprache bei mehrsprachigen Variablen.<br /> <br /> ;&lt;code&gt;scope&lt;/code&gt;<br /> :[[Scope|Gültigkeitsbereich]], in dem die Variable definiert ist. Möglich sind &lt;code&gt;page&lt;/code&gt; und &lt;code&gt;request&lt;/code&gt;.<br /> <br /> ==Beispiele==<br /> <br /> ===Bild verkleinern===<br /> <br /> Template Quelltext<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;sp:scaleimage<br /> name=&quot;scaledImage&quot;<br /> object=&quot;myImage.systemlink&quot;<br /> width=&quot;40&quot;<br /> height=&quot;40&quot;<br /> padding=&quot;on&quot;<br /> background=&quot;AAAAAA&quot;/&gt;<br /> widht: &lt;sp:print name=&quot;scaledImage.widthToScale&quot;/&gt;<br /> height: &lt;sp:print name=&quot;scaledImage.heightToScale&quot;/&gt;<br /> url: &lt;sp:print name=&quot;scaledImage.url&quot;/&gt;<br /> &lt;/source&gt;<br /> <br /> Ausgabe<br /> &lt;source lang=&quot;text&quot;&gt;<br /> width: 40<br /> height: 40<br /> url: /test/test.html.media/myimage.jpg.scaled/40x40.pm1.bgAAAAAA.jpg<br /> &lt;/source&gt;<br /> <br /> <br /> &lt;noinclude&gt;<br /> [[Category:SP-Tags]]<br /> [[Category:Qualität_des_Codes_prüfen]]<br /> [[Category:Beispiel_überarbeiten_testen]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=Scaleimage_(SP-Tag)&diff=7697 2015-10-02T08:37:44Z

<p>Liebold: /* Attribute */</p> <hr /> <div>==Name==<br /> &lt;sp:scaleimage&gt; - Verkleinert Bilder<br /> <br /> ==Syntax==<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;sp:scaleimage<br /> name=&quot;variable&quot;<br /> scope=&quot;page&quot;<br /> object=&quot;${myImageLink.link}&quot;<br /> width=&quot;40&quot;<br /> height=&quot;40&quot;<br /> padding=&quot;on&quot;<br /> background=&quot;0000FF&quot;<br /> /&gt;<br /> &lt;/source&gt; <br /> <br /> ==Beschreibung==<br /> Bilder die im [[IES]] abgelegt wurden, können mit Hilfe dieses Tags verkleinert werden (z.B. für Thumbnails). Dieser Tag kann sowohl im Eingabe- als auch im Ausgabemodus verwendet werden. Mit dem object-Attribut wird das zu verkleinernde Bild angegeben. Mit den Attributen width und height wird die Größe des Bildes definiert. Wird nur die Breite oder nur die Höhe angegeben, ergibt sich der Wert aus dem proportionalen Seitenverhältnis des Bildes. Die Daten des klein gerechneten Bildes werden in einem [[ScaleImage]]-Objekt abgelegt, das über den im Attribut &lt;code&gt;name&lt;/code&gt; angegebenen Variablennamen erreichbar ist.<br /> <br /> Für die Skalierung von Bildern gelten folgende Regeln:<br /> * Ein Bild wird immer proportional verkleinert. Das Seitenverhältnis des Bildes bleibt stets erhalten.<br /> * Bilder werden nicht vergrößert<br /> <br /> Die Verkleinerung des Bildes kann in drei unterschiedlichen Modi erfolgen:<br /> <br /> ;kein Padding (padding=&quot;off&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Das Bild wird so verkleinert, dass es komplett in den angegebenen Rahmen passt. Hierbei ist es möglich, dass entweder die Höhe oder die Breite des verkleinerten Bildes kleiner als der definierte Wert ist. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 50x50 Pixel groß sein. Sind die definierten Ausmaße größer als das Original, so bleibt das Bild unverändert.<br /> <br /> ;Padding (padding=&quot;on&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Das Bild wird so verkleinert, das es komplett in den angegebenen Rahmen passt. Hierbei ist es möglich das entweder die Höhe oder die Breite des verkleinerten Bildes kleiner als des definierten Wertes ist. In diesem Fall wird das Bild rechts und links, bzw. oben und unten mit einem Padding aufgefüllt. Die Farbe für das Padding wird mit dem Attribut background angegeben. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 50x50 Pixel groß sein und erhält links und rechts einen 25 Pixel breiten Balken in der angegebene background-Farbe. Sind die definierten Ausmaße größer als das Original, wird das Bild mit der background-Farbe aufgefüllt, so dass in jedem Fall die definierte Größe erreicht wird.<br /> <br /> ;Fit-Padding (padding=&quot;fit&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Dabei wird das Bild soweit verkleinert, bis entweder die Höhe oder die Breite in den Rahmen passt. Dabei ist es möglich, dass entweder die linke- und rechte- oder ober- und unter-Seite über den Rahmen herausragen. Die überstehenden Seiten werden abgeschnitten um die angegebene Größe zu erreichen. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 100x100 Pixel groß sein. Anschließend werden noch oben und unten 25 Pixel abgeschnitten um die angegebene größe von 100x50 Pixel zu erreichen. Sind die definierten Ausmaße größer als das Original wird das Bild mit der background-Farbe aufgefüllt, so dass in jedem Fall die definierte Größe erreicht wird.<br /> :Über die Optionen kann ein Focus-Point angegeben werden, der den Bildmittelpunkt für den Zuschnitt definiert. In diesem Fall werden die Kanten nicht gleichmäßig abgeschnitten sondern so, dass der Focus-Point möglichst die Mitte des zugeschnittenen Bildes definiert.<br /> <br /> Im Padding und Fit-Padding Modus ist immer sichergestellt, dass die angegebene Bildgröße erreicht wird.<br /> <br /> Dieser Tag verhält sich im [[Template-Modus|In-]] und im [[Template-Modus|Out-Modus]] unterschiedlich.<br /> <br /> ;Out-Modus<br /> :Wird &lt;code&gt;sp:scaleimage&lt;/code&gt; im [[Template-Modus|Out-Modus]] betrieben, wird das verkleinerte Bild in einem Verzeichnis parallel zu dem Original abgelegt. Der Verzeichnisname besteht aus dem Dateinamen des originalen Bildes mit dem Zusatz ''.scaled'' (z.B. logo.jpg.scaled für ein Bild logo.jpg). Die Bilder werden während des Publizier-Vorgangs berechnet sowie jedes mal, wenn sich das Original geändert hat.<br /> <br /> ;In-Modus<br /> :Wird sp:scaleimage im [[Template-Modus|In-Modus]] betrieben, liegen die verkleinerten Bild zusammen mit dem Original in der BinDB des [[IES]]. Im In-Modus werden nicht alle angegebenen Bildgrößen berechnet, sondern nur bestimmte Größen, die in der [[BinDB]] definiert sind. In der BinDB sind z.B. die Größen 40,h40,w50,100 definiert. Dies bedeutet folgendes:<br /> :;40<br /> ::Bild wird mit einer Höhe und Breite von 40 Pixeln mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;h40<br /> ::Bild wird mit einer Höhe von 40 Pixel und einer Breite proportional zum Original mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;w50<br /> ::Bild wird mit einer Breite von 50 Pixel und einer Höhe proportional zum Original mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;100<br /> ::Bild wird mit einer Höhe und Breite von 100 Pixeln mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> <br /> :Wird nun ein Bild von 30x30 Pixel verlangt wird das '''40'''-Bild verwendet. Wird ein 300x300 Pixel Bild verlangt, wird das '''100'''-Bild verwendet. Der Sinn dabei ist, dass nicht eine sehr große Anzahl von Bilder berechnet und in der BinDB abgelegt werden soll. Die zurückgegebenen Bilder können auf das verlangte Maß vom Browser skaliert werden. Das Padding kann über CSS-Styles erfolgen.<br /> <br /> :Dieses Verhalten der 'Skalierungs-Schritte' kann über das Attribut &lt;code&gt;scaleSteps=&quot;false&quot;&lt;/code&gt; ausgeschaltet werden. Das ist aber nur in Ausnahmefällen empfehlenswert und kann sich negativ auf die Performanz des Systems auswirken.<br /> <br /> ==Attribute==<br /> {| class=&quot;prettytable sortable&quot;<br /> |- class=&quot;hintergrundfarbe1&quot;<br /> ! Name || Type || Required || Default || ab IES Version<br /> |-<br /> | &lt;code&gt;name&lt;/code&gt;<br /> | [[Variable]]<br /> | Ja<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;object&lt;/code&gt;<br /> | [[Attribute]]<br /> | Nein<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;width&lt;/code&gt;<br /> | [[Expression]]<br /> | Ja und / oder &lt;code&gt;height&lt;/code&gt;<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;height&lt;/code&gt;<br /> | [[Expression]]<br /> | Ja und / oder &lt;code&gt;width&lt;/code&gt;<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;padding&lt;/code&gt;<br /> | [[Text]]<br /> | Nein<br /> | off (Achtung: anderer Default-Wert als bei [[spt:imp]])<br /> | 2<br /> |-<br /> | &lt;code&gt;background&lt;/code&gt;<br /> | [[Text]]<br /> | Nein<br /> | FFFFFF<br /> | 2<br /> |-<br /> | &lt;code&gt;scalesteps&lt;/code&gt;<br /> | [[Condition]]<br /> | Nein<br /> | true, wirkt sich nur im In-Modus aus<br /> | 2<br /> |-<br /> | &lt;code&gt;options&lt;/code&gt;<br /> | [[String]] (Im JSON-Format)<br /> | Nein<br /> | None<br /> | 2.11<br /> |-<br /> | &lt;code&gt;locale&lt;/code&gt;<br /> | [[Locale]]<br /> | Nein<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;scope&lt;/code&gt;<br /> | [[Scope]]<br /> | Nein<br /> | request<br /> | 2<br /> |}<br /> <br /> ;&lt;code&gt;name&lt;/code&gt;<br /> :Name der Variable für den Zugriff auf das [[ScaleImage]]-Objekt.<br /> <br /> ;&lt;code&gt;object&lt;/code&gt;<br /> :Original-Bild.<br /> <br /> ;&lt;code&gt;width&lt;/code&gt;<br /> :Breite des zu berechnenden Bildes.<br /> <br /> ;&lt;code&gt;height&lt;/code&gt;<br /> :Höhe des zu berechnenden Bildes.<br /> <br /> ;&lt;code&gt;padding&lt;/code&gt;<br /> :Der Wert &quot;on&quot; erzeugt Rahmen zur Auffüllung der Flächen um das Bild. Damit ist das resultierende Bild immer so groß. wie durch die Auflösung gefordert.<br /> <br /> :Der Wert &quot;off&quot; erzeugt keinen Rahmen zur Auffüllung der Flächen um das Bild. Damit ist das resultierende Bild unter Umständen kleiner als die geforderte Auflösung.<br /> <br /> :Mit &quot;fit&quot; wird der größtmögliche Ausschnitt aus dem Originalbild bzw. aus dem durch excerpt gewählten Ausschnitt gesucht, bei dem das Seitenverhältnis der geforderten Auflösung entspricht. Es wird kein Rahmen erzeugt, sondern das Bild in einer Dimension gegebenenfalls gekürzt.<br /> <br /> :Aufgrund von Abwärtskompatibilität wird auch der Wert &quot;yes&quot; (entspricht &quot;on&quot;) und &quot;no&quot; (entspricht &quot;off&quot;) unterstützt.<br /> <br /> ;&lt;code&gt;background&lt;/code&gt;<br /> :Hintergrundfabe für das Padding Numerisch oder als als HEX-Wert im RGB oder RGBA-Format.<br /> :Transparente Farben funktionieren nur bei PNG-Bildern.<br /> ::ffffff = weiß<br /> ::ffffff00 = transparent bei PNG, ansonsten weiß<br /> ::00000000 = transparent bei PNG, ansonsten schwarz<br /> ::rgb(255,255,255,0) = transparent bei PNG, ansonsten weiß<br /> ::rgb(255,255,255,128)= 50% transparent bei PNG, ansonsten weiß<br /> <br /> ;&lt;code&gt;scalesteps&lt;/code&gt;<br /> :Schalter um das Optimierungsverhalten im In-Modus auszuschalten.<br /> <br /> ;&lt;code&gt;options&lt;/code&gt;<br /> :Mit diesem Attribut können Bild-Optionen für die Berechnung des Bildes übergeben werden. Z.Z. ist nur die Übergabe eines Focus-Point möglich<br /> :;Focus-Point<br /> ::&lt;source lang=&quot;javascript&quot;&gt;{ &quot;focuspoint&quot;: { &quot;x&quot;:0.062, &quot;y&quot;:0.527 } }&lt;/source&gt;Der Focus-Point definiert den Bereich eines Bildes, der als Mittelpunkt des Bildes angenommen werden soll, wenn über den padding-Modus 'fit' das Bild beim Verkleinern beschnitten wird.<br /> <br /> ;&lt;code&gt;locale&lt;/code&gt;<br /> :Dieses Attribut dient zur Auswahl der zu verwendende Sprache bei mehrsprachigen Variablen.<br /> <br /> ;&lt;code&gt;scope&lt;/code&gt;<br /> :[[Scope|Gültigkeitsbereich]], in dem die Variable definiert ist. Möglich sind &lt;code&gt;page&lt;/code&gt; und &lt;code&gt;request&lt;/code&gt;.<br /> <br /> ==Beispiele==<br /> <br /> ===Bild verkleinern===<br /> <br /> Template Quelltext<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;sp:scaleimage<br /> name=&quot;scaledImage&quot;<br /> object=&quot;myImage.systemlink&quot;<br /> width=&quot;40&quot;<br /> height=&quot;40&quot;<br /> padding=&quot;on&quot;<br /> background=&quot;AAAAAA&quot;/&gt;<br /> widht: &lt;sp:print name=&quot;scaledImage.widthToScale&quot;/&gt;<br /> height: &lt;sp:print name=&quot;scaledImage.heightToScale&quot;/&gt;<br /> url: &lt;sp:print name=&quot;scaledImage.url&quot;/&gt;<br /> &lt;/source&gt;<br /> <br /> Ausgabe<br /> &lt;source lang=&quot;text&quot;&gt;<br /> width: 40<br /> height: 40<br /> url: /test/test.html.media/myimage.jpg.scaled/40x40.pm1.bgAAAAAA.jpg<br /> &lt;/source&gt;<br /> <br /> <br /> &lt;noinclude&gt;<br /> [[Category:SP-Tags]]<br /> [[Category:Qualität_des_Codes_prüfen]]<br /> [[Category:Beispiel_überarbeiten_testen]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=Scaleimage_(SP-Tag)&diff=7696 2015-10-02T08:37:06Z

<p>Liebold: /* Attribute */</p> <hr /> <div>==Name==<br /> &lt;sp:scaleimage&gt; - Verkleinert Bilder<br /> <br /> ==Syntax==<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;sp:scaleimage<br /> name=&quot;variable&quot;<br /> scope=&quot;page&quot;<br /> object=&quot;${myImageLink.link}&quot;<br /> width=&quot;40&quot;<br /> height=&quot;40&quot;<br /> padding=&quot;on&quot;<br /> background=&quot;0000FF&quot;<br /> /&gt;<br /> &lt;/source&gt; <br /> <br /> ==Beschreibung==<br /> Bilder die im [[IES]] abgelegt wurden, können mit Hilfe dieses Tags verkleinert werden (z.B. für Thumbnails). Dieser Tag kann sowohl im Eingabe- als auch im Ausgabemodus verwendet werden. Mit dem object-Attribut wird das zu verkleinernde Bild angegeben. Mit den Attributen width und height wird die Größe des Bildes definiert. Wird nur die Breite oder nur die Höhe angegeben, ergibt sich der Wert aus dem proportionalen Seitenverhältnis des Bildes. Die Daten des klein gerechneten Bildes werden in einem [[ScaleImage]]-Objekt abgelegt, das über den im Attribut &lt;code&gt;name&lt;/code&gt; angegebenen Variablennamen erreichbar ist.<br /> <br /> Für die Skalierung von Bildern gelten folgende Regeln:<br /> * Ein Bild wird immer proportional verkleinert. Das Seitenverhältnis des Bildes bleibt stets erhalten.<br /> * Bilder werden nicht vergrößert<br /> <br /> Die Verkleinerung des Bildes kann in drei unterschiedlichen Modi erfolgen:<br /> <br /> ;kein Padding (padding=&quot;off&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Das Bild wird so verkleinert, dass es komplett in den angegebenen Rahmen passt. Hierbei ist es möglich, dass entweder die Höhe oder die Breite des verkleinerten Bildes kleiner als der definierte Wert ist. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 50x50 Pixel groß sein. Sind die definierten Ausmaße größer als das Original, so bleibt das Bild unverändert.<br /> <br /> ;Padding (padding=&quot;on&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Das Bild wird so verkleinert, das es komplett in den angegebenen Rahmen passt. Hierbei ist es möglich das entweder die Höhe oder die Breite des verkleinerten Bildes kleiner als des definierten Wertes ist. In diesem Fall wird das Bild rechts und links, bzw. oben und unten mit einem Padding aufgefüllt. Die Farbe für das Padding wird mit dem Attribut background angegeben. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 50x50 Pixel groß sein und erhält links und rechts einen 25 Pixel breiten Balken in der angegebene background-Farbe. Sind die definierten Ausmaße größer als das Original, wird das Bild mit der background-Farbe aufgefüllt, so dass in jedem Fall die definierte Größe erreicht wird.<br /> <br /> ;Fit-Padding (padding=&quot;fit&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Dabei wird das Bild soweit verkleinert, bis entweder die Höhe oder die Breite in den Rahmen passt. Dabei ist es möglich, dass entweder die linke- und rechte- oder ober- und unter-Seite über den Rahmen herausragen. Die überstehenden Seiten werden abgeschnitten um die angegebene Größe zu erreichen. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 100x100 Pixel groß sein. Anschließend werden noch oben und unten 25 Pixel abgeschnitten um die angegebene größe von 100x50 Pixel zu erreichen. Sind die definierten Ausmaße größer als das Original wird das Bild mit der background-Farbe aufgefüllt, so dass in jedem Fall die definierte Größe erreicht wird.<br /> :Über die Optionen kann ein Focus-Point angegeben werden, der den Bildmittelpunkt für den Zuschnitt definiert. In diesem Fall werden die Kanten nicht gleichmäßig abgeschnitten sondern so, dass der Focus-Point möglichst die Mitte des zugeschnittenen Bildes definiert.<br /> <br /> Im Padding und Fit-Padding Modus ist immer sichergestellt, dass die angegebene Bildgröße erreicht wird.<br /> <br /> Dieser Tag verhält sich im [[Template-Modus|In-]] und im [[Template-Modus|Out-Modus]] unterschiedlich.<br /> <br /> ;Out-Modus<br /> :Wird &lt;code&gt;sp:scaleimage&lt;/code&gt; im [[Template-Modus|Out-Modus]] betrieben, wird das verkleinerte Bild in einem Verzeichnis parallel zu dem Original abgelegt. Der Verzeichnisname besteht aus dem Dateinamen des originalen Bildes mit dem Zusatz ''.scaled'' (z.B. logo.jpg.scaled für ein Bild logo.jpg). Die Bilder werden während des Publizier-Vorgangs berechnet sowie jedes mal, wenn sich das Original geändert hat.<br /> <br /> ;In-Modus<br /> :Wird sp:scaleimage im [[Template-Modus|In-Modus]] betrieben, liegen die verkleinerten Bild zusammen mit dem Original in der BinDB des [[IES]]. Im In-Modus werden nicht alle angegebenen Bildgrößen berechnet, sondern nur bestimmte Größen, die in der [[BinDB]] definiert sind. In der BinDB sind z.B. die Größen 40,h40,w50,100 definiert. Dies bedeutet folgendes:<br /> :;40<br /> ::Bild wird mit einer Höhe und Breite von 40 Pixeln mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;h40<br /> ::Bild wird mit einer Höhe von 40 Pixel und einer Breite proportional zum Original mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;w50<br /> ::Bild wird mit einer Breite von 50 Pixel und einer Höhe proportional zum Original mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;100<br /> ::Bild wird mit einer Höhe und Breite von 100 Pixeln mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> <br /> :Wird nun ein Bild von 30x30 Pixel verlangt wird das '''40'''-Bild verwendet. Wird ein 300x300 Pixel Bild verlangt, wird das '''100'''-Bild verwendet. Der Sinn dabei ist, dass nicht eine sehr große Anzahl von Bilder berechnet und in der BinDB abgelegt werden soll. Die zurückgegebenen Bilder können auf das verlangte Maß vom Browser skaliert werden. Das Padding kann über CSS-Styles erfolgen.<br /> <br /> :Dieses Verhalten der 'Skalierungs-Schritte' kann über das Attribut &lt;code&gt;scaleSteps=&quot;false&quot;&lt;/code&gt; ausgeschaltet werden. Das ist aber nur in Ausnahmefällen empfehlenswert und kann sich negativ auf die Performanz des Systems auswirken.<br /> <br /> ==Attribute==<br /> {| class=&quot;prettytable sortable&quot;<br /> |- class=&quot;hintergrundfarbe1&quot;<br /> ! Name || Type || Required || Default || ab IES Version<br /> |-<br /> | &lt;code&gt;name&lt;/code&gt;<br /> | [[Variable]]<br /> | Ja<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;object&lt;/code&gt;<br /> | [[Attribute]]<br /> | Nein<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;width&lt;/code&gt;<br /> | [[Expression]]<br /> | Ja und / oder &lt;code&gt;height&lt;/code&gt;<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;height&lt;/code&gt;<br /> | [[Expression]]<br /> | Ja und / oder &lt;code&gt;width&lt;/code&gt;<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;padding&lt;/code&gt;<br /> | [[Text]]<br /> | Nein<br /> | off (Achtung: anderer Default-Wert als bei [[spt:imp]])<br /> | 2<br /> |-<br /> | &lt;code&gt;background&lt;/code&gt;<br /> | [[Text]]<br /> | Nein<br /> | FFFFFF<br /> | 2<br /> |-<br /> | &lt;code&gt;scalesteps&lt;/code&gt;<br /> | [[Condition]]<br /> | Nein<br /> | true, wirkt sich nur im In-Modus aus<br /> | 2<br /> |-<br /> | &lt;code&gt;options&lt;/code&gt;<br /> | [[String]] (Im JSON-Format)<br /> | Nein<br /> | None<br /> | 2.11<br /> |-<br /> | &lt;code&gt;locale&lt;/code&gt;<br /> | [[Locale]]<br /> | Nein<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;scope&lt;/code&gt;<br /> | [[Scope]]<br /> | Nein<br /> | request<br /> | 2<br /> |}<br /> <br /> ;&lt;code&gt;name&lt;/code&gt;<br /> :Name der Variable für den Zugriff auf das [[ScaleImage]]-Objekt.<br /> <br /> ;&lt;code&gt;object&lt;/code&gt;<br /> :Original-Bild.<br /> <br /> ;&lt;code&gt;width&lt;/code&gt;<br /> :Breite des zu berechnenden Bildes.<br /> <br /> ;&lt;code&gt;height&lt;/code&gt;<br /> :Höhe des zu berechnenden Bildes.<br /> <br /> ;&lt;code&gt;padding&lt;/code&gt;<br /> :Der Wert &quot;on&quot; erzeugt Rahmen zur Auffüllung der Flächen um das Bild. Damit ist das resultierende Bild immer so groß. wie durch die Auflösung gefordert.<br /> <br /> :Der Wert &quot;off&quot; erzeugt keinen Rahmen zur Auffüllung der Flächen um das Bild. Damit ist das resultierende Bild unter Umständen kleiner als die geforderte Auflösung.<br /> <br /> :Mit &quot;fit&quot; wird der größtmögliche Ausschnitt aus dem Originalbild bzw. aus dem durch excerpt gewählten Ausschnitt gesucht, bei dem das Seitenverhältnis der geforderten Auflösung entspricht. Es wird kein Rahmen erzeugt, sondern das Bild in einer Dimension gegebenenfalls gekürzt.<br /> <br /> :Aufgrund von Abwärtskompatibilität wird auch der Wert &quot;yes&quot; (entspricht &quot;on&quot;) und &quot;no&quot; (entspricht &quot;off&quot;) unterstützt.<br /> <br /> ;&lt;code&gt;background&lt;/code&gt;<br /> :Hintergrundfabe für das Padding Numerisch oder als als HEX-Wert im RGB oder RGBA-Format.<br /> :Transparente Farben funktionieren nur bei PNG-Bildern.<br /> ::&lt;source lang=&quot;javascript&quot;&gt;<br /> ::ffffff = weiß<br /> ::ffffff00 = transparent bei PNG, ansonsten weiß<br /> ::00000000 = transparent bei PNG, ansonsten schwarz<br /> ::rgb(255,255,255,0) = transparent bei PNG, ansonsten weiß<br /> ::rgb(255,255,255,128)= 50% transparent bei PNG, ansonsten weiß<br /> ::&lt;/source&gt;<br /> <br /> ;&lt;code&gt;scalesteps&lt;/code&gt;<br /> :Schalter um das Optimierungsverhalten im In-Modus auszuschalten.<br /> <br /> ;&lt;code&gt;options&lt;/code&gt;<br /> :Mit diesem Attribut können Bild-Optionen für die Berechnung des Bildes übergeben werden. Z.Z. ist nur die Übergabe eines Focus-Point möglich<br /> :;Focus-Point<br /> ::&lt;source lang=&quot;javascript&quot;&gt;{ &quot;focuspoint&quot;: { &quot;x&quot;:0.062, &quot;y&quot;:0.527 } }&lt;/source&gt;Der Focus-Point definiert den Bereich eines Bildes, der als Mittelpunkt des Bildes angenommen werden soll, wenn über den padding-Modus 'fit' das Bild beim Verkleinern beschnitten wird.<br /> <br /> ;&lt;code&gt;locale&lt;/code&gt;<br /> :Dieses Attribut dient zur Auswahl der zu verwendende Sprache bei mehrsprachigen Variablen.<br /> <br /> ;&lt;code&gt;scope&lt;/code&gt;<br /> :[[Scope|Gültigkeitsbereich]], in dem die Variable definiert ist. Möglich sind &lt;code&gt;page&lt;/code&gt; und &lt;code&gt;request&lt;/code&gt;.<br /> <br /> ==Beispiele==<br /> <br /> ===Bild verkleinern===<br /> <br /> Template Quelltext<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;sp:scaleimage<br /> name=&quot;scaledImage&quot;<br /> object=&quot;myImage.systemlink&quot;<br /> width=&quot;40&quot;<br /> height=&quot;40&quot;<br /> padding=&quot;on&quot;<br /> background=&quot;AAAAAA&quot;/&gt;<br /> widht: &lt;sp:print name=&quot;scaledImage.widthToScale&quot;/&gt;<br /> height: &lt;sp:print name=&quot;scaledImage.heightToScale&quot;/&gt;<br /> url: &lt;sp:print name=&quot;scaledImage.url&quot;/&gt;<br /> &lt;/source&gt;<br /> <br /> Ausgabe<br /> &lt;source lang=&quot;text&quot;&gt;<br /> width: 40<br /> height: 40<br /> url: /test/test.html.media/myimage.jpg.scaled/40x40.pm1.bgAAAAAA.jpg<br /> &lt;/source&gt;<br /> <br /> <br /> &lt;noinclude&gt;<br /> [[Category:SP-Tags]]<br /> [[Category:Qualität_des_Codes_prüfen]]<br /> [[Category:Beispiel_überarbeiten_testen]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=Scaleimage_(SP-Tag)&diff=7695 2015-10-02T08:34:17Z

<p>Liebold: /* Attribute */</p> <hr /> <div>==Name==<br /> &lt;sp:scaleimage&gt; - Verkleinert Bilder<br /> <br /> ==Syntax==<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;sp:scaleimage<br /> name=&quot;variable&quot;<br /> scope=&quot;page&quot;<br /> object=&quot;${myImageLink.link}&quot;<br /> width=&quot;40&quot;<br /> height=&quot;40&quot;<br /> padding=&quot;on&quot;<br /> background=&quot;0000FF&quot;<br /> /&gt;<br /> &lt;/source&gt; <br /> <br /> ==Beschreibung==<br /> Bilder die im [[IES]] abgelegt wurden, können mit Hilfe dieses Tags verkleinert werden (z.B. für Thumbnails). Dieser Tag kann sowohl im Eingabe- als auch im Ausgabemodus verwendet werden. Mit dem object-Attribut wird das zu verkleinernde Bild angegeben. Mit den Attributen width und height wird die Größe des Bildes definiert. Wird nur die Breite oder nur die Höhe angegeben, ergibt sich der Wert aus dem proportionalen Seitenverhältnis des Bildes. Die Daten des klein gerechneten Bildes werden in einem [[ScaleImage]]-Objekt abgelegt, das über den im Attribut &lt;code&gt;name&lt;/code&gt; angegebenen Variablennamen erreichbar ist.<br /> <br /> Für die Skalierung von Bildern gelten folgende Regeln:<br /> * Ein Bild wird immer proportional verkleinert. Das Seitenverhältnis des Bildes bleibt stets erhalten.<br /> * Bilder werden nicht vergrößert<br /> <br /> Die Verkleinerung des Bildes kann in drei unterschiedlichen Modi erfolgen:<br /> <br /> ;kein Padding (padding=&quot;off&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Das Bild wird so verkleinert, dass es komplett in den angegebenen Rahmen passt. Hierbei ist es möglich, dass entweder die Höhe oder die Breite des verkleinerten Bildes kleiner als der definierte Wert ist. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 50x50 Pixel groß sein. Sind die definierten Ausmaße größer als das Original, so bleibt das Bild unverändert.<br /> <br /> ;Padding (padding=&quot;on&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Das Bild wird so verkleinert, das es komplett in den angegebenen Rahmen passt. Hierbei ist es möglich das entweder die Höhe oder die Breite des verkleinerten Bildes kleiner als des definierten Wertes ist. In diesem Fall wird das Bild rechts und links, bzw. oben und unten mit einem Padding aufgefüllt. Die Farbe für das Padding wird mit dem Attribut background angegeben. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 50x50 Pixel groß sein und erhält links und rechts einen 25 Pixel breiten Balken in der angegebene background-Farbe. Sind die definierten Ausmaße größer als das Original, wird das Bild mit der background-Farbe aufgefüllt, so dass in jedem Fall die definierte Größe erreicht wird.<br /> <br /> ;Fit-Padding (padding=&quot;fit&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Dabei wird das Bild soweit verkleinert, bis entweder die Höhe oder die Breite in den Rahmen passt. Dabei ist es möglich, dass entweder die linke- und rechte- oder ober- und unter-Seite über den Rahmen herausragen. Die überstehenden Seiten werden abgeschnitten um die angegebene Größe zu erreichen. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 100x100 Pixel groß sein. Anschließend werden noch oben und unten 25 Pixel abgeschnitten um die angegebene größe von 100x50 Pixel zu erreichen. Sind die definierten Ausmaße größer als das Original wird das Bild mit der background-Farbe aufgefüllt, so dass in jedem Fall die definierte Größe erreicht wird.<br /> :Über die Optionen kann ein Focus-Point angegeben werden, der den Bildmittelpunkt für den Zuschnitt definiert. In diesem Fall werden die Kanten nicht gleichmäßig abgeschnitten sondern so, dass der Focus-Point möglichst die Mitte des zugeschnittenen Bildes definiert.<br /> <br /> Im Padding und Fit-Padding Modus ist immer sichergestellt, dass die angegebene Bildgröße erreicht wird.<br /> <br /> Dieser Tag verhält sich im [[Template-Modus|In-]] und im [[Template-Modus|Out-Modus]] unterschiedlich.<br /> <br /> ;Out-Modus<br /> :Wird &lt;code&gt;sp:scaleimage&lt;/code&gt; im [[Template-Modus|Out-Modus]] betrieben, wird das verkleinerte Bild in einem Verzeichnis parallel zu dem Original abgelegt. Der Verzeichnisname besteht aus dem Dateinamen des originalen Bildes mit dem Zusatz ''.scaled'' (z.B. logo.jpg.scaled für ein Bild logo.jpg). Die Bilder werden während des Publizier-Vorgangs berechnet sowie jedes mal, wenn sich das Original geändert hat.<br /> <br /> ;In-Modus<br /> :Wird sp:scaleimage im [[Template-Modus|In-Modus]] betrieben, liegen die verkleinerten Bild zusammen mit dem Original in der BinDB des [[IES]]. Im In-Modus werden nicht alle angegebenen Bildgrößen berechnet, sondern nur bestimmte Größen, die in der [[BinDB]] definiert sind. In der BinDB sind z.B. die Größen 40,h40,w50,100 definiert. Dies bedeutet folgendes:<br /> :;40<br /> ::Bild wird mit einer Höhe und Breite von 40 Pixeln mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;h40<br /> ::Bild wird mit einer Höhe von 40 Pixel und einer Breite proportional zum Original mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;w50<br /> ::Bild wird mit einer Breite von 50 Pixel und einer Höhe proportional zum Original mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;100<br /> ::Bild wird mit einer Höhe und Breite von 100 Pixeln mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> <br /> :Wird nun ein Bild von 30x30 Pixel verlangt wird das '''40'''-Bild verwendet. Wird ein 300x300 Pixel Bild verlangt, wird das '''100'''-Bild verwendet. Der Sinn dabei ist, dass nicht eine sehr große Anzahl von Bilder berechnet und in der BinDB abgelegt werden soll. Die zurückgegebenen Bilder können auf das verlangte Maß vom Browser skaliert werden. Das Padding kann über CSS-Styles erfolgen.<br /> <br /> :Dieses Verhalten der 'Skalierungs-Schritte' kann über das Attribut &lt;code&gt;scaleSteps=&quot;false&quot;&lt;/code&gt; ausgeschaltet werden. Das ist aber nur in Ausnahmefällen empfehlenswert und kann sich negativ auf die Performanz des Systems auswirken.<br /> <br /> ==Attribute==<br /> {| class=&quot;prettytable sortable&quot;<br /> |- class=&quot;hintergrundfarbe1&quot;<br /> ! Name || Type || Required || Default || ab IES Version<br /> |-<br /> | &lt;code&gt;name&lt;/code&gt;<br /> | [[Variable]]<br /> | Ja<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;object&lt;/code&gt;<br /> | [[Attribute]]<br /> | Nein<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;width&lt;/code&gt;<br /> | [[Expression]]<br /> | Ja und / oder &lt;code&gt;height&lt;/code&gt;<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;height&lt;/code&gt;<br /> | [[Expression]]<br /> | Ja und / oder &lt;code&gt;width&lt;/code&gt;<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;padding&lt;/code&gt;<br /> | [[Text]]<br /> | Nein<br /> | off (Achtung: anderer Default-Wert als bei [[spt:imp]])<br /> | 2<br /> |-<br /> | &lt;code&gt;background&lt;/code&gt;<br /> | [[Text]]<br /> | Nein<br /> | FFFFFF<br /> | 2<br /> |-<br /> | &lt;code&gt;scalesteps&lt;/code&gt;<br /> | [[Condition]]<br /> | Nein<br /> | true, wirkt sich nur im In-Modus aus<br /> | 2<br /> |-<br /> | &lt;code&gt;options&lt;/code&gt;<br /> | [[String]] (Im JSON-Format)<br /> | Nein<br /> | None<br /> | 2.11<br /> |-<br /> | &lt;code&gt;locale&lt;/code&gt;<br /> | [[Locale]]<br /> | Nein<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;scope&lt;/code&gt;<br /> | [[Scope]]<br /> | Nein<br /> | request<br /> | 2<br /> |}<br /> <br /> ;&lt;code&gt;name&lt;/code&gt;<br /> :Name der Variable für den Zugriff auf das [[ScaleImage]]-Objekt.<br /> <br /> ;&lt;code&gt;object&lt;/code&gt;<br /> :Original-Bild.<br /> <br /> ;&lt;code&gt;width&lt;/code&gt;<br /> :Breite des zu berechnenden Bildes.<br /> <br /> ;&lt;code&gt;height&lt;/code&gt;<br /> :Höhe des zu berechnenden Bildes.<br /> <br /> ;&lt;code&gt;padding&lt;/code&gt;<br /> :Der Wert &quot;on&quot; erzeugt Rahmen zur Auffüllung der Flächen um das Bild. Damit ist das resultierende Bild immer so groß. wie durch die Auflösung gefordert.<br /> <br /> :Der Wert &quot;off&quot; erzeugt keinen Rahmen zur Auffüllung der Flächen um das Bild. Damit ist das resultierende Bild unter Umständen kleiner als die geforderte Auflösung.<br /> <br /> :Mit &quot;fit&quot; wird der größtmögliche Ausschnitt aus dem Originalbild bzw. aus dem durch excerpt gewählten Ausschnitt gesucht, bei dem das Seitenverhältnis der geforderten Auflösung entspricht. Es wird kein Rahmen erzeugt, sondern das Bild in einer Dimension gegebenenfalls gekürzt.<br /> <br /> :Aufgrund von Abwärtskompatibilität wird auch der Wert &quot;yes&quot; (entspricht &quot;on&quot;) und &quot;no&quot; (entspricht &quot;off&quot;) unterstützt.<br /> <br /> ;&lt;code&gt;background&lt;/code&gt;<br /> :Hintergrundfabe für das Padding Numerisch oder als als HEX-Wert im RGB oder RGBA-Format.<br /> :Transparente Farben funktionieren nur bei PNG-Bildern.<br /> ::&lt;source lang=&quot;javascript&quot;&gt;<br /> ffffff = weiß<br /> ffffff00 = transparent bei PNG, ansonsten weiß<br /> 00000000 = transparent bei PNG, ansonsten schwarz<br /> rgb(255,255,255,0) = transparent bei PNG, ansonsten weiß<br /> rgb(255,255,255,128)= 50% transparent bei PNG, ansonsten weiß<br /> &lt;/source&gt;<br /> <br /> ;&lt;code&gt;scalesteps&lt;/code&gt;<br /> :Schalter um das Optimierungsverhalten im In-Modus auszuschalten.<br /> <br /> ;&lt;code&gt;options&lt;/code&gt;<br /> :Mit diesem Attribut können Bild-Optionen für die Berechnung des Bildes übergeben werden. Z.Z. ist nur die Übergabe eines Focus-Point möglich<br /> :;Focus-Point<br /> ::&lt;source lang=&quot;javascript&quot;&gt;{ &quot;focuspoint&quot;: { &quot;x&quot;:0.062, &quot;y&quot;:0.527 } }&lt;/source&gt;Der Focus-Point definiert den Bereich eines Bildes, der als Mittelpunkt des Bildes angenommen werden soll, wenn über den padding-Modus 'fit' das Bild beim Verkleinern beschnitten wird.<br /> <br /> ;&lt;code&gt;locale&lt;/code&gt;<br /> :Dieses Attribut dient zur Auswahl der zu verwendende Sprache bei mehrsprachigen Variablen.<br /> <br /> ;&lt;code&gt;scope&lt;/code&gt;<br /> :[[Scope|Gültigkeitsbereich]], in dem die Variable definiert ist. Möglich sind &lt;code&gt;page&lt;/code&gt; und &lt;code&gt;request&lt;/code&gt;.<br /> <br /> ==Beispiele==<br /> <br /> ===Bild verkleinern===<br /> <br /> Template Quelltext<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;sp:scaleimage<br /> name=&quot;scaledImage&quot;<br /> object=&quot;myImage.systemlink&quot;<br /> width=&quot;40&quot;<br /> height=&quot;40&quot;<br /> padding=&quot;on&quot;<br /> background=&quot;AAAAAA&quot;/&gt;<br /> widht: &lt;sp:print name=&quot;scaledImage.widthToScale&quot;/&gt;<br /> height: &lt;sp:print name=&quot;scaledImage.heightToScale&quot;/&gt;<br /> url: &lt;sp:print name=&quot;scaledImage.url&quot;/&gt;<br /> &lt;/source&gt;<br /> <br /> Ausgabe<br /> &lt;source lang=&quot;text&quot;&gt;<br /> width: 40<br /> height: 40<br /> url: /test/test.html.media/myimage.jpg.scaled/40x40.pm1.bgAAAAAA.jpg<br /> &lt;/source&gt;<br /> <br /> <br /> &lt;noinclude&gt;<br /> [[Category:SP-Tags]]<br /> [[Category:Qualität_des_Codes_prüfen]]<br /> [[Category:Beispiel_überarbeiten_testen]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=Scaleimage_(SP-Tag)&diff=7694 2015-10-02T08:32:40Z

<p>Liebold: /* Attribute */</p> <hr /> <div>==Name==<br /> &lt;sp:scaleimage&gt; - Verkleinert Bilder<br /> <br /> ==Syntax==<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;sp:scaleimage<br /> name=&quot;variable&quot;<br /> scope=&quot;page&quot;<br /> object=&quot;${myImageLink.link}&quot;<br /> width=&quot;40&quot;<br /> height=&quot;40&quot;<br /> padding=&quot;on&quot;<br /> background=&quot;0000FF&quot;<br /> /&gt;<br /> &lt;/source&gt; <br /> <br /> ==Beschreibung==<br /> Bilder die im [[IES]] abgelegt wurden, können mit Hilfe dieses Tags verkleinert werden (z.B. für Thumbnails). Dieser Tag kann sowohl im Eingabe- als auch im Ausgabemodus verwendet werden. Mit dem object-Attribut wird das zu verkleinernde Bild angegeben. Mit den Attributen width und height wird die Größe des Bildes definiert. Wird nur die Breite oder nur die Höhe angegeben, ergibt sich der Wert aus dem proportionalen Seitenverhältnis des Bildes. Die Daten des klein gerechneten Bildes werden in einem [[ScaleImage]]-Objekt abgelegt, das über den im Attribut &lt;code&gt;name&lt;/code&gt; angegebenen Variablennamen erreichbar ist.<br /> <br /> Für die Skalierung von Bildern gelten folgende Regeln:<br /> * Ein Bild wird immer proportional verkleinert. Das Seitenverhältnis des Bildes bleibt stets erhalten.<br /> * Bilder werden nicht vergrößert<br /> <br /> Die Verkleinerung des Bildes kann in drei unterschiedlichen Modi erfolgen:<br /> <br /> ;kein Padding (padding=&quot;off&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Das Bild wird so verkleinert, dass es komplett in den angegebenen Rahmen passt. Hierbei ist es möglich, dass entweder die Höhe oder die Breite des verkleinerten Bildes kleiner als der definierte Wert ist. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 50x50 Pixel groß sein. Sind die definierten Ausmaße größer als das Original, so bleibt das Bild unverändert.<br /> <br /> ;Padding (padding=&quot;on&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Das Bild wird so verkleinert, das es komplett in den angegebenen Rahmen passt. Hierbei ist es möglich das entweder die Höhe oder die Breite des verkleinerten Bildes kleiner als des definierten Wertes ist. In diesem Fall wird das Bild rechts und links, bzw. oben und unten mit einem Padding aufgefüllt. Die Farbe für das Padding wird mit dem Attribut background angegeben. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 50x50 Pixel groß sein und erhält links und rechts einen 25 Pixel breiten Balken in der angegebene background-Farbe. Sind die definierten Ausmaße größer als das Original, wird das Bild mit der background-Farbe aufgefüllt, so dass in jedem Fall die definierte Größe erreicht wird.<br /> <br /> ;Fit-Padding (padding=&quot;fit&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Dabei wird das Bild soweit verkleinert, bis entweder die Höhe oder die Breite in den Rahmen passt. Dabei ist es möglich, dass entweder die linke- und rechte- oder ober- und unter-Seite über den Rahmen herausragen. Die überstehenden Seiten werden abgeschnitten um die angegebene Größe zu erreichen. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 100x100 Pixel groß sein. Anschließend werden noch oben und unten 25 Pixel abgeschnitten um die angegebene größe von 100x50 Pixel zu erreichen. Sind die definierten Ausmaße größer als das Original wird das Bild mit der background-Farbe aufgefüllt, so dass in jedem Fall die definierte Größe erreicht wird.<br /> :Über die Optionen kann ein Focus-Point angegeben werden, der den Bildmittelpunkt für den Zuschnitt definiert. In diesem Fall werden die Kanten nicht gleichmäßig abgeschnitten sondern so, dass der Focus-Point möglichst die Mitte des zugeschnittenen Bildes definiert.<br /> <br /> Im Padding und Fit-Padding Modus ist immer sichergestellt, dass die angegebene Bildgröße erreicht wird.<br /> <br /> Dieser Tag verhält sich im [[Template-Modus|In-]] und im [[Template-Modus|Out-Modus]] unterschiedlich.<br /> <br /> ;Out-Modus<br /> :Wird &lt;code&gt;sp:scaleimage&lt;/code&gt; im [[Template-Modus|Out-Modus]] betrieben, wird das verkleinerte Bild in einem Verzeichnis parallel zu dem Original abgelegt. Der Verzeichnisname besteht aus dem Dateinamen des originalen Bildes mit dem Zusatz ''.scaled'' (z.B. logo.jpg.scaled für ein Bild logo.jpg). Die Bilder werden während des Publizier-Vorgangs berechnet sowie jedes mal, wenn sich das Original geändert hat.<br /> <br /> ;In-Modus<br /> :Wird sp:scaleimage im [[Template-Modus|In-Modus]] betrieben, liegen die verkleinerten Bild zusammen mit dem Original in der BinDB des [[IES]]. Im In-Modus werden nicht alle angegebenen Bildgrößen berechnet, sondern nur bestimmte Größen, die in der [[BinDB]] definiert sind. In der BinDB sind z.B. die Größen 40,h40,w50,100 definiert. Dies bedeutet folgendes:<br /> :;40<br /> ::Bild wird mit einer Höhe und Breite von 40 Pixeln mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;h40<br /> ::Bild wird mit einer Höhe von 40 Pixel und einer Breite proportional zum Original mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;w50<br /> ::Bild wird mit einer Breite von 50 Pixel und einer Höhe proportional zum Original mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;100<br /> ::Bild wird mit einer Höhe und Breite von 100 Pixeln mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> <br /> :Wird nun ein Bild von 30x30 Pixel verlangt wird das '''40'''-Bild verwendet. Wird ein 300x300 Pixel Bild verlangt, wird das '''100'''-Bild verwendet. Der Sinn dabei ist, dass nicht eine sehr große Anzahl von Bilder berechnet und in der BinDB abgelegt werden soll. Die zurückgegebenen Bilder können auf das verlangte Maß vom Browser skaliert werden. Das Padding kann über CSS-Styles erfolgen.<br /> <br /> :Dieses Verhalten der 'Skalierungs-Schritte' kann über das Attribut &lt;code&gt;scaleSteps=&quot;false&quot;&lt;/code&gt; ausgeschaltet werden. Das ist aber nur in Ausnahmefällen empfehlenswert und kann sich negativ auf die Performanz des Systems auswirken.<br /> <br /> ==Attribute==<br /> {| class=&quot;prettytable sortable&quot;<br /> |- class=&quot;hintergrundfarbe1&quot;<br /> ! Name || Type || Required || Default || ab IES Version<br /> |-<br /> | &lt;code&gt;name&lt;/code&gt;<br /> | [[Variable]]<br /> | Ja<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;object&lt;/code&gt;<br /> | [[Attribute]]<br /> | Nein<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;width&lt;/code&gt;<br /> | [[Expression]]<br /> | Ja und / oder &lt;code&gt;height&lt;/code&gt;<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;height&lt;/code&gt;<br /> | [[Expression]]<br /> | Ja und / oder &lt;code&gt;width&lt;/code&gt;<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;padding&lt;/code&gt;<br /> | [[Text]]<br /> | Nein<br /> | off (Achtung: anderer Default-Wert als bei [[spt:imp]])<br /> | 2<br /> |-<br /> | &lt;code&gt;background&lt;/code&gt;<br /> | [[Text]]<br /> | Nein<br /> | FFFFFF<br /> | 2<br /> |-<br /> | &lt;code&gt;scalesteps&lt;/code&gt;<br /> | [[Condition]]<br /> | Nein<br /> | true, wirkt sich nur im In-Modus aus<br /> | 2<br /> |-<br /> | &lt;code&gt;options&lt;/code&gt;<br /> | [[String]] (Im JSON-Format)<br /> | Nein<br /> | None<br /> | 2.11<br /> |-<br /> | &lt;code&gt;locale&lt;/code&gt;<br /> | [[Locale]]<br /> | Nein<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;scope&lt;/code&gt;<br /> | [[Scope]]<br /> | Nein<br /> | request<br /> | 2<br /> |}<br /> <br /> ;&lt;code&gt;name&lt;/code&gt;<br /> :Name der Variable für den Zugriff auf das [[ScaleImage]]-Objekt.<br /> <br /> ;&lt;code&gt;object&lt;/code&gt;<br /> :Original-Bild.<br /> <br /> ;&lt;code&gt;width&lt;/code&gt;<br /> :Breite des zu berechnenden Bildes.<br /> <br /> ;&lt;code&gt;height&lt;/code&gt;<br /> :Höhe des zu berechnenden Bildes.<br /> <br /> ;&lt;code&gt;padding&lt;/code&gt;<br /> :Der Wert &quot;on&quot; erzeugt Rahmen zur Auffüllung der Flächen um das Bild. Damit ist das resultierende Bild immer so groß. wie durch die Auflösung gefordert.<br /> <br /> :Der Wert &quot;off&quot; erzeugt keinen Rahmen zur Auffüllung der Flächen um das Bild. Damit ist das resultierende Bild unter Umständen kleiner als die geforderte Auflösung.<br /> <br /> :Mit &quot;fit&quot; wird der größtmögliche Ausschnitt aus dem Originalbild bzw. aus dem durch excerpt gewählten Ausschnitt gesucht, bei dem das Seitenverhältnis der geforderten Auflösung entspricht. Es wird kein Rahmen erzeugt, sondern das Bild in einer Dimension gegebenenfalls gekürzt.<br /> <br /> :Aufgrund von Abwärtskompatibilität wird auch der Wert &quot;yes&quot; (entspricht &quot;on&quot;) und &quot;no&quot; (entspricht &quot;off&quot;) unterstützt.<br /> <br /> ;&lt;code&gt;background&lt;/code&gt;<br /> :Hintergrundfabe für das Padding Numerisch oder als als HEX-Wert im RGB oder RGBA-Format.<br /> :Transparente Farben funktionieren nur bei PNG-Bildern.<br /> ::&lt;source lang=&quot;javascript&quot;&gt;ffffff = weiß<br /> ffffff00 = transparent bei PNG, ansonsten weiß<br /> 00000000 = transparent bei PNG, ansonsten schwarz<br /> rgb(255,255,255,0) = transparent bei PNG, ansonsten weiß<br /> rgb(255,255,255,128)= 50% transparent bei PNG, ansonsten weiß&lt;/source&gt;<br /> <br /> ;&lt;code&gt;scalesteps&lt;/code&gt;<br /> :Schalter um das Optimierungsverhalten im In-Modus auszuschalten.<br /> <br /> ;&lt;code&gt;options&lt;/code&gt;<br /> :Mit diesem Attribut können Bild-Optionen für die Berechnung des Bildes übergeben werden. Z.Z. ist nur die Übergabe eines Focus-Point möglich<br /> :;Focus-Point<br /> ::&lt;source lang=&quot;javascript&quot;&gt;{ &quot;focuspoint&quot;: { &quot;x&quot;:0.062, &quot;y&quot;:0.527 } }&lt;/source&gt;Der Focus-Point definiert den Bereich eines Bildes, der als Mittelpunkt des Bildes angenommen werden soll, wenn über den padding-Modus 'fit' das Bild beim Verkleinern beschnitten wird.<br /> <br /> ;&lt;code&gt;locale&lt;/code&gt;<br /> :Dieses Attribut dient zur Auswahl der zu verwendende Sprache bei mehrsprachigen Variablen.<br /> <br /> ;&lt;code&gt;scope&lt;/code&gt;<br /> :[[Scope|Gültigkeitsbereich]], in dem die Variable definiert ist. Möglich sind &lt;code&gt;page&lt;/code&gt; und &lt;code&gt;request&lt;/code&gt;.<br /> <br /> ==Beispiele==<br /> <br /> ===Bild verkleinern===<br /> <br /> Template Quelltext<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;sp:scaleimage<br /> name=&quot;scaledImage&quot;<br /> object=&quot;myImage.systemlink&quot;<br /> width=&quot;40&quot;<br /> height=&quot;40&quot;<br /> padding=&quot;on&quot;<br /> background=&quot;AAAAAA&quot;/&gt;<br /> widht: &lt;sp:print name=&quot;scaledImage.widthToScale&quot;/&gt;<br /> height: &lt;sp:print name=&quot;scaledImage.heightToScale&quot;/&gt;<br /> url: &lt;sp:print name=&quot;scaledImage.url&quot;/&gt;<br /> &lt;/source&gt;<br /> <br /> Ausgabe<br /> &lt;source lang=&quot;text&quot;&gt;<br /> width: 40<br /> height: 40<br /> url: /test/test.html.media/myimage.jpg.scaled/40x40.pm1.bgAAAAAA.jpg<br /> &lt;/source&gt;<br /> <br /> <br /> &lt;noinclude&gt;<br /> [[Category:SP-Tags]]<br /> [[Category:Qualität_des_Codes_prüfen]]<br /> [[Category:Beispiel_überarbeiten_testen]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=Scaleimage_(SP-Tag)&diff=7693 2015-10-02T08:24:38Z

<p>Liebold: /* Attribute */</p> <hr /> <div>==Name==<br /> &lt;sp:scaleimage&gt; - Verkleinert Bilder<br /> <br /> ==Syntax==<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;sp:scaleimage<br /> name=&quot;variable&quot;<br /> scope=&quot;page&quot;<br /> object=&quot;${myImageLink.link}&quot;<br /> width=&quot;40&quot;<br /> height=&quot;40&quot;<br /> padding=&quot;on&quot;<br /> background=&quot;0000FF&quot;<br /> /&gt;<br /> &lt;/source&gt; <br /> <br /> ==Beschreibung==<br /> Bilder die im [[IES]] abgelegt wurden, können mit Hilfe dieses Tags verkleinert werden (z.B. für Thumbnails). Dieser Tag kann sowohl im Eingabe- als auch im Ausgabemodus verwendet werden. Mit dem object-Attribut wird das zu verkleinernde Bild angegeben. Mit den Attributen width und height wird die Größe des Bildes definiert. Wird nur die Breite oder nur die Höhe angegeben, ergibt sich der Wert aus dem proportionalen Seitenverhältnis des Bildes. Die Daten des klein gerechneten Bildes werden in einem [[ScaleImage]]-Objekt abgelegt, das über den im Attribut &lt;code&gt;name&lt;/code&gt; angegebenen Variablennamen erreichbar ist.<br /> <br /> Für die Skalierung von Bildern gelten folgende Regeln:<br /> * Ein Bild wird immer proportional verkleinert. Das Seitenverhältnis des Bildes bleibt stets erhalten.<br /> * Bilder werden nicht vergrößert<br /> <br /> Die Verkleinerung des Bildes kann in drei unterschiedlichen Modi erfolgen:<br /> <br /> ;kein Padding (padding=&quot;off&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Das Bild wird so verkleinert, dass es komplett in den angegebenen Rahmen passt. Hierbei ist es möglich, dass entweder die Höhe oder die Breite des verkleinerten Bildes kleiner als der definierte Wert ist. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 50x50 Pixel groß sein. Sind die definierten Ausmaße größer als das Original, so bleibt das Bild unverändert.<br /> <br /> ;Padding (padding=&quot;on&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Das Bild wird so verkleinert, das es komplett in den angegebenen Rahmen passt. Hierbei ist es möglich das entweder die Höhe oder die Breite des verkleinerten Bildes kleiner als des definierten Wertes ist. In diesem Fall wird das Bild rechts und links, bzw. oben und unten mit einem Padding aufgefüllt. Die Farbe für das Padding wird mit dem Attribut background angegeben. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 50x50 Pixel groß sein und erhält links und rechts einen 25 Pixel breiten Balken in der angegebene background-Farbe. Sind die definierten Ausmaße größer als das Original, wird das Bild mit der background-Farbe aufgefüllt, so dass in jedem Fall die definierte Größe erreicht wird.<br /> <br /> ;Fit-Padding (padding=&quot;fit&quot;)<br /> :Mit den Attributen &lt;code&gt;width&lt;/code&gt; und &lt;code&gt;height&lt;/code&gt; wird die Größe für ein Bild definiert. Dabei wird das Bild soweit verkleinert, bis entweder die Höhe oder die Breite in den Rahmen passt. Dabei ist es möglich, dass entweder die linke- und rechte- oder ober- und unter-Seite über den Rahmen herausragen. Die überstehenden Seiten werden abgeschnitten um die angegebene Größe zu erreichen. Soll z.B. ein 500x500 Pixel großes Bild auf 100x50 Pixel verkleinert werden, wird das verkleinerte Bild 100x100 Pixel groß sein. Anschließend werden noch oben und unten 25 Pixel abgeschnitten um die angegebene größe von 100x50 Pixel zu erreichen. Sind die definierten Ausmaße größer als das Original wird das Bild mit der background-Farbe aufgefüllt, so dass in jedem Fall die definierte Größe erreicht wird.<br /> :Über die Optionen kann ein Focus-Point angegeben werden, der den Bildmittelpunkt für den Zuschnitt definiert. In diesem Fall werden die Kanten nicht gleichmäßig abgeschnitten sondern so, dass der Focus-Point möglichst die Mitte des zugeschnittenen Bildes definiert.<br /> <br /> Im Padding und Fit-Padding Modus ist immer sichergestellt, dass die angegebene Bildgröße erreicht wird.<br /> <br /> Dieser Tag verhält sich im [[Template-Modus|In-]] und im [[Template-Modus|Out-Modus]] unterschiedlich.<br /> <br /> ;Out-Modus<br /> :Wird &lt;code&gt;sp:scaleimage&lt;/code&gt; im [[Template-Modus|Out-Modus]] betrieben, wird das verkleinerte Bild in einem Verzeichnis parallel zu dem Original abgelegt. Der Verzeichnisname besteht aus dem Dateinamen des originalen Bildes mit dem Zusatz ''.scaled'' (z.B. logo.jpg.scaled für ein Bild logo.jpg). Die Bilder werden während des Publizier-Vorgangs berechnet sowie jedes mal, wenn sich das Original geändert hat.<br /> <br /> ;In-Modus<br /> :Wird sp:scaleimage im [[Template-Modus|In-Modus]] betrieben, liegen die verkleinerten Bild zusammen mit dem Original in der BinDB des [[IES]]. Im In-Modus werden nicht alle angegebenen Bildgrößen berechnet, sondern nur bestimmte Größen, die in der [[BinDB]] definiert sind. In der BinDB sind z.B. die Größen 40,h40,w50,100 definiert. Dies bedeutet folgendes:<br /> :;40<br /> ::Bild wird mit einer Höhe und Breite von 40 Pixeln mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;h40<br /> ::Bild wird mit einer Höhe von 40 Pixel und einer Breite proportional zum Original mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;w50<br /> ::Bild wird mit einer Breite von 50 Pixel und einer Höhe proportional zum Original mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> :;100<br /> ::Bild wird mit einer Höhe und Breite von 100 Pixeln mit &lt;code&gt;padding=&quot;off&quot;&lt;/code&gt; berechnet<br /> <br /> :Wird nun ein Bild von 30x30 Pixel verlangt wird das '''40'''-Bild verwendet. Wird ein 300x300 Pixel Bild verlangt, wird das '''100'''-Bild verwendet. Der Sinn dabei ist, dass nicht eine sehr große Anzahl von Bilder berechnet und in der BinDB abgelegt werden soll. Die zurückgegebenen Bilder können auf das verlangte Maß vom Browser skaliert werden. Das Padding kann über CSS-Styles erfolgen.<br /> <br /> :Dieses Verhalten der 'Skalierungs-Schritte' kann über das Attribut &lt;code&gt;scaleSteps=&quot;false&quot;&lt;/code&gt; ausgeschaltet werden. Das ist aber nur in Ausnahmefällen empfehlenswert und kann sich negativ auf die Performanz des Systems auswirken.<br /> <br /> ==Attribute==<br /> {| class=&quot;prettytable sortable&quot;<br /> |- class=&quot;hintergrundfarbe1&quot;<br /> ! Name || Type || Required || Default || ab IES Version<br /> |-<br /> | &lt;code&gt;name&lt;/code&gt;<br /> | [[Variable]]<br /> | Ja<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;object&lt;/code&gt;<br /> | [[Attribute]]<br /> | Nein<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;width&lt;/code&gt;<br /> | [[Expression]]<br /> | Ja und / oder &lt;code&gt;height&lt;/code&gt;<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;height&lt;/code&gt;<br /> | [[Expression]]<br /> | Ja und / oder &lt;code&gt;width&lt;/code&gt;<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;padding&lt;/code&gt;<br /> | [[Text]]<br /> | Nein<br /> | off (Achtung: anderer Default-Wert als bei [[spt:imp]])<br /> | 2<br /> |-<br /> | &lt;code&gt;background&lt;/code&gt;<br /> | [[Text]]<br /> | Nein<br /> | FFFFFF<br /> | 2<br /> |-<br /> | &lt;code&gt;scalesteps&lt;/code&gt;<br /> | [[Condition]]<br /> | Nein<br /> | true, wirkt sich nur im In-Modus aus<br /> | 2<br /> |-<br /> | &lt;code&gt;options&lt;/code&gt;<br /> | [[String]] (Im JSON-Format)<br /> | Nein<br /> | None<br /> | 2.11<br /> |-<br /> | &lt;code&gt;locale&lt;/code&gt;<br /> | [[Locale]]<br /> | Nein<br /> | None<br /> | 2<br /> |-<br /> | &lt;code&gt;scope&lt;/code&gt;<br /> | [[Scope]]<br /> | Nein<br /> | request<br /> | 2<br /> |}<br /> <br /> ;&lt;code&gt;name&lt;/code&gt;<br /> :Name der Variable für den Zugriff auf das [[ScaleImage]]-Objekt.<br /> <br /> ;&lt;code&gt;object&lt;/code&gt;<br /> :Original-Bild.<br /> <br /> ;&lt;code&gt;width&lt;/code&gt;<br /> :Breite des zu berechnenden Bildes.<br /> <br /> ;&lt;code&gt;height&lt;/code&gt;<br /> :Höhe des zu berechnenden Bildes.<br /> <br /> ;&lt;code&gt;padding&lt;/code&gt;<br /> :Der Wert &quot;on&quot; erzeugt Rahmen zur Auffüllung der Flächen um das Bild. Damit ist das resultierende Bild immer so groß. wie durch die Auflösung gefordert.<br /> <br /> :Der Wert &quot;off&quot; erzeugt keinen Rahmen zur Auffüllung der Flächen um das Bild. Damit ist das resultierende Bild unter Umständen kleiner als die geforderte Auflösung.<br /> <br /> :Mit &quot;fit&quot; wird der größtmögliche Ausschnitt aus dem Originalbild bzw. aus dem durch excerpt gewählten Ausschnitt gesucht, bei dem das Seitenverhältnis der geforderten Auflösung entspricht. Es wird kein Rahmen erzeugt, sondern das Bild in einer Dimension gegebenenfalls gekürzt.<br /> <br /> :Aufgrund von Abwärtskompatibilität wird auch der Wert &quot;yes&quot; (entspricht &quot;on&quot;) und &quot;no&quot; (entspricht &quot;off&quot;) unterstützt.<br /> <br /> ;&lt;code&gt;background&lt;/code&gt;<br /> :Hintergrundfabe für das Padding als HEX-Wert im RGB oder RGBA-Format (ffffff00 = transparent). RGBA funktioniert nur bei PNG-Bildern.<br /> <br /> ;&lt;code&gt;scalesteps&lt;/code&gt;<br /> :Schalter um das Optimierungsverhalten im In-Modus auszuschalten.<br /> <br /> ;&lt;code&gt;options&lt;/code&gt;<br /> :Mit diesem Attribut können Bild-Optionen für die Berechnung des Bildes übergeben werden. Z.Z. ist nur die Übergabe eines Focus-Point möglich<br /> :;Focus-Point<br /> ::&lt;source lang=&quot;javascript&quot;&gt;{ &quot;focuspoint&quot;: { &quot;x&quot;:0.062, &quot;y&quot;:0.527 } }&lt;/source&gt;Der Focus-Point definiert den Bereich eines Bildes, der als Mittelpunkt des Bildes angenommen werden soll, wenn über den padding-Modus 'fit' das Bild beim Verkleinern beschnitten wird.<br /> <br /> ;&lt;code&gt;locale&lt;/code&gt;<br /> :Dieses Attribut dient zur Auswahl der zu verwendende Sprache bei mehrsprachigen Variablen.<br /> <br /> ;&lt;code&gt;scope&lt;/code&gt;<br /> :[[Scope|Gültigkeitsbereich]], in dem die Variable definiert ist. Möglich sind &lt;code&gt;page&lt;/code&gt; und &lt;code&gt;request&lt;/code&gt;.<br /> <br /> ==Beispiele==<br /> <br /> ===Bild verkleinern===<br /> <br /> Template Quelltext<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;sp:scaleimage<br /> name=&quot;scaledImage&quot;<br /> object=&quot;myImage.systemlink&quot;<br /> width=&quot;40&quot;<br /> height=&quot;40&quot;<br /> padding=&quot;on&quot;<br /> background=&quot;AAAAAA&quot;/&gt;<br /> widht: &lt;sp:print name=&quot;scaledImage.widthToScale&quot;/&gt;<br /> height: &lt;sp:print name=&quot;scaledImage.heightToScale&quot;/&gt;<br /> url: &lt;sp:print name=&quot;scaledImage.url&quot;/&gt;<br /> &lt;/source&gt;<br /> <br /> Ausgabe<br /> &lt;source lang=&quot;text&quot;&gt;<br /> width: 40<br /> height: 40<br /> url: /test/test.html.media/myimage.jpg.scaled/40x40.pm1.bgAAAAAA.jpg<br /> &lt;/source&gt;<br /> <br /> <br /> &lt;noinclude&gt;<br /> [[Category:SP-Tags]]<br /> [[Category:Qualität_des_Codes_prüfen]]<br /> [[Category:Beispiel_überarbeiten_testen]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=Templates&diff=6923 2014-08-21T12:45:53Z

<p>Liebold: /* Markup für aktuelle InfoSite6 kompatible Templates */</p> <hr /> <div>Hinweise zur Erstellung von Templates für InfoSite.<br /> <br /> ==Markup für aktuelle InfoSite 6 kompatible Templates==<br /> Hinweise hier:<br /> [[Templateerstellung]]<br /> <br /> &lt;noinclude&gt;<br /> [[Category:SPML]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=Installationsanleitung_InfoSite_6&diff=6905 2014-08-14T09:35:18Z

<p>Liebold: /* Allgemein (modulübergreifend) */</p> <hr /> <div>&lt;div class=&quot;note&quot;&gt;<br /> Bitte sprechen Sie uns vor der Inbetriebnahme von InfoSite 6 an. Wir teilen Ihnen dann die idealen Konfigurationen für Ihr System mit.<br /> &lt;/div&gt;<br /> <br /> ===Allgemein===<br /> Bei der Installation / dem Update eines IES für InfoSite 6 sind folgende initiale Arbeiten auszuführen bzw. folgende Punkte zu beachten:<br /> <br /> *InfoSite sollte dringend mit SSL betrieben werden. Es ist darauf zu achten, dass ein echtes, valides Zertifikat verwendet wird, da sonst z.B. das Caching von Bildern im Chrome-Browser nicht funktioniert.<br /> *Der Volltext-Index für die ältere Mandanten muss initial einmal neu aufgebaut werden (im IES-Admin über &quot;Dienste&quot;)<br /> *Der Apache sollte ausreichend Child-Prozesse erzeugen können. Pro Redakteur, der in InfoSite 6 arbeitet, wird neben den regulären Requests noch ein sog. Long-Polling-Request auf den Server gemacht. Dadurch wird je ein Child-Prozess des Apache gebunden. <br /> <br /> ===Konfiguration===<br /> ====Konfiguration am Mandanten====<br /> =====In InfoSite=====<br /> *Legen Sie in InfoSite einen neue Artikelpool mit folgendem Anker an<br /> !{ies.infp.infosite}<br /> :Dieser dient zukünftig als ''Root''-Pool für alle in Artikel, die in InfoSite bearbeitet werden können. CityGov-Artikel beispielsweise liegen in :einem Pool parallel zu diesem.<br /> <br /> :Verschieben Sie daher alle Artikelpools in diesen neuen Pool (&quot;Artikel&quot;, &quot;IES&quot;, &quot;Administration&quot;, etc.).<br /> <br /> *Optionale Pool-Eigenschaften können in einem Template mit dem folgenden Anker implementiert werden:<br /> !{infosite6.informationPoolProperties}<br /> <br /> =====Allgemein (modulübergreifend)=====<br /> *Konfiguration der Sitemaps in den Attributen des Mandanten über z.B. folgende JSON-Daten:<br /> &lt;source lang=&quot;text&quot;&gt;<br /> sitemaps=[<br /> {<br /> text:'Homepage',<br /> displayfield:'sp_title',<br /> linkfield:'sp_parent',<br /> obj:'infe.g12.homepage'<br /> },{<br /> text:'Intranet',<br /> displayfield:'sp_title',<br /> linkfield:'sp_parent_intranet',<br /> obj:'infe.g12.intranet'<br /> }<br /> ]<br /> &lt;/source&gt;<br /> <br /> :Die Konfiguration muss jedoch ''inline'' erfolgend, da die Attribute nicht JSON, sondern Properties erwarten:<br /> &lt;source lang=&quot;text&quot;&gt;<br /> sitemaps=[{text:'Homepage',displayfield:'sp_title',linkfield:'sp_parent',obj:'infe.g12.homepage'},{text:'Intranet',displayfield:'sp_title',linkfield:'sp_parent_intranet',obj:'infe.g12.intranet'}]<br /> &lt;/source&gt;<br /> <br /> *Optionale Weiterleitung auf eine i!-Link-Einstiegsseite (ehem. ilink-login.html)<br /> &lt;source lang=&quot;text&quot;&gt;<br /> ilinkRedirect=/ilink-login.html<br /> &lt;/source&gt;<br /> <br /> =====InfoSite 6=====<br /> *'''Synchrones Laden einzelner Bearbeitungs-Steps eines Artikels aktivieren:'''&lt;br /&gt; Grundsätzlich werden in InfoSite 6 alle Steps eines Artikels direkt, asynchron geladen und dargestellt. Werden nun aber Templates verwendet, bei denen einzelne Steps und Eingaben aufeinander aufbauen, so müssen die einzelnen Steps synchron, analog zu InfoSite 5, erst beim Aufruf geladen werden. Default ist &quot;false&quot;:&lt;source lang=&quot;text&quot;&gt;infosite6.synchronousSteps=false&lt;/source&gt;<br /> <br /> *'''Artikel-Pools, die initial geöffnet werden sollen:'''&lt;br /&gt; &lt;source lang=&quot;text&quot;&gt;infosite6.expanded=['infp.g12.editorial','infp.g12.media']&lt;/source&gt;<br /> <br /> *'''Initiale Zielsprache (ehem. GUISecondLanguage):'''&lt;br /&gt;&lt;source lang=&quot;text&quot;&gt;infosite6.defaultLanguage=default&lt;/source&gt;<br /> <br /> *'''Debug-Option für Administratoren aktivieren:'''&lt;br /&gt; Debugging wird nun im Nutzerprofil gespeichert. Um den Debug-Modus zu aktivieren muss ein Aufruf auf InfoSite6 mit dem Parameter ''debug=true'' erfolgen:&lt;source lang=&quot;text&quot;&gt;.../ies/infosite6/index.jsp?debug=true&lt;/source&gt;Nach diesem Aufruf wird die Debug-Option persistent im Nutzerprofil gespeichert. Um den Debug-Modus wieder zu deaktivieren muss ein Aufruf auf InfoSite6 mit dem Parameter ''debug=false'' erfolgen: &lt;source lang=&quot;text&quot;&gt;.../ies/infosite6/index.jsp?debug=false&lt;/source&gt;<br /> <br /> *'''Zielgruppen für Benachrichtigungen:'''&lt;br /&gt;In InfoSite 6 besteht die Möglichkeit Nachrichten an Nutzer oder Nutzergruppen zu senden. Für den Redakteur stehen alle Nutzer und Nutzergruppen ab einem konfigurierten Einstiegspool zur Verfügung. Für den Workflow an Artikeln können eigene Nutzergruppen definiert werden. Alle Nutzer dieser Gruppen werden über eine weiteren Einstiegspool dem Redakteur angezeigt:&lt;source lang=&quot;text&quot;&gt;infosite6.userGroupMessaging=Anker des gewünschten Pools&lt;/source&gt;&lt;source lang=&quot;text&quot;&gt;infosite6.userGroupWorkflow=Anker des gewünschten Pools&lt;/source&gt;<br /> <br /> ====Konfiguration am Publisher====<br /> *Publisher, deren Status in den Listen dargestellt werden sollen, müssen durch folgendes Attribut in der Konfiguration gesetzt werden:<br /> &lt;source lang=&quot;text&quot;&gt;<br /> infosite6.showInGrid=true<br /> &lt;/source&gt;<br /> <br /> ====Optionale Konfiguration====<br /> Weiterhin sind folgende optionale Setzungen über die Attribute der IES-API (Eigenschaften des Moduls) möglich<br /> *Warnung bei unsicherer Verbindung (kein SSL) deaktivieren (Davon sollte i.d.R. kein Gebrauch gemacht werden, da bei allen Requests stets die IES-Session übertragen wird):<br /> &lt;source lang=&quot;text&quot;&gt;<br /> ignoreSSL=true<br /> &lt;/source&gt;<br /> <br /> :Auch sollte ein serverseitiger JavaScript-Logger für Fehlermeldungen aktiviert werden:<br /> Name: &quot;JavaScript.IES.Infosite6&quot;<br /> LogLevel: &quot;TRACE&quot;<br /> <br /> ===Weitere Hinweise===<br /> In Templates kann wie folgt abgefragt werden, ob diese innerhalb von InfoSite 6 ausgeführt werden:<br /> &lt;source lang=&quot;text&quot;&gt;<br /> &lt;sp:if name=&quot;system.modules.infosite6&quot;&gt;infosite6&lt;/sp:if&gt;<br /> &lt;/source&gt;<br /> <br /> <br /> &lt;noinclude&gt;<br /> [[Kategorie:InfoSite6]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=Ilink_(SPT-Tag)&diff=6904 2014-08-14T09:33:54Z

<p>Liebold: /* Einfacher Artikel mit i-Link */</p> <hr /> <div>==Name==<br /> &lt;spt:ilink&gt; - Erzeugt einen Link auf das CMS<br /> <br /> ==Syntax==<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;spt:ilink value=&quot;&quot;/&gt;<br /> &lt;/source&gt; <br /> <br /> ==Beschreibung==<br /> Der &lt;code&gt;spt:ilink&lt;/code&gt;-Tag generiert einen Link auf die Bearbeitung des entsprechenden Artikels. Diese Links sind klassisch in der Website nur für Redakteure sichtbar und erlauben das Öffnen des aktuellen Artikels in der Bearbeitung von InfoSite direkt aus der Website heraus.<br /> <br /> Seit InfoSite 6 ist auch die Verwendung des i!-Links für interne Links auf andere Artikel innerhalb des CMS möglich.<br /> <br /> ==Attribute==<br /> {| class=&quot;prettytable&quot;<br /> |- class=&quot;hintergrundfarbe1&quot;<br /> ! Name || Type || Required || Default || ab IES Version<br /> |-<br /> | &lt;code&gt;value&lt;/code&gt;<br /> | [[Text]]<br /> | Nein<br /> | None<br /> | 1<br /> |-<br /> | &lt;code&gt;information&lt;/code&gt;<br /> | [[Attribute]]<br /> | Nein<br /> | None<br /> | 1<br /> |-<br /> | &lt;code&gt;step&lt;/code&gt;<br /> | [[Number]]<br /> | Nein<br /> | None<br /> | 2.0.1<br /> |}<br /> <br /> ;&lt;code&gt;value&lt;/code&gt;<br /> :Code für den generierten i-Link.<br /> <br /> ;&lt;code&gt;information&lt;/code&gt;<br /> :Optionale Angabe eines Artikels, auf den der Link zeigen soll (z.B. für Listen).<br /> <br /> ;&lt;code&gt;step&lt;/code&gt;<br /> :Bei Templates, die mit mehreren Steps aufgebaut sind ist hiermit der Sprung an eine definierte Stelle möglich. Die Angabe erfolgt relativ zum Step &quot;Verwaltung&quot;.<br /> <br /> ==Beispiele==<br /> <br /> ===Einfacher Artikel mit i!-Link===<br /> <br /> Template Quelltext<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;sp:io type=&quot;in&quot;&gt;<br /> &lt;sp:text name=&quot;headline&quot;/&gt;<br /> &lt;/sp:io&gt;<br /> <br /> &lt;%-- einfacher Seiten-i-Link --%&gt;<br /> &lt;sp:io type=&quot;out&quot;&gt;<br /> &lt;sp:print name=&quot;headline&quot;/&gt;<br /> &lt;/sp:io&gt;<br /> <br /> &lt;spt:ilink value=&quot;Artikel bearbeiten&quot;&quot;/&gt;<br /> <br /> &lt;%-- Loop pro Treffer ein i-Link --%&gt;<br /> &lt;sp:io type=&quot;out&quot;&gt;<br /> &lt;sp:loop collection=&quot;collection&quot; item=&quot;it&quot;&gt;<br /> &lt;ul class=&quot;linkIntern&quot;&gt;<br /> &lt;li&gt;<br /> &lt;a href=&quot;&lt;sp:print name=&quot;it.id.url&quot;/&gt;&quot;&gt;&lt;sp:print name=&quot;it.sp_title&quot;/&gt;&lt;/a&gt;<br /> &lt;div id=&quot;ilinkInline&quot;&gt;<br /> &lt;spt:ilink <br /> value=&quot;&lt;img src=\&quot;/img/ilink.gif\&quot; <br /> class=\&quot;ilink\&quot; <br /> width=\&quot;16\&quot; <br /> height=\&quot;16\&quot; <br /> alt=\&quot;Seite bearbeiten ...\&quot;&gt;&quot; <br /> information=&quot;${it.id}&quot;/&gt;<br /> &lt;/div&gt;<br /> &lt;/li&gt;<br /> &lt;/ul&gt;<br /> &lt;/sp:loop&gt;<br /> &lt;/sp:io&gt;<br /> &lt;/source&gt;<br /> <br /> <br /> <br /> &lt;noinclude&gt;<br /> [[Category:SPT-Tags]]<br /> [[Category:Qualität_des_Inhalts_prüfen]]<br /> [[Category:Qualität_des_Codes_prüfen]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=Ilink_(SPT-Tag)&diff=6903 2014-08-14T09:33:38Z

<p>Liebold: /* Beschreibung */</p> <hr /> <div>==Name==<br /> &lt;spt:ilink&gt; - Erzeugt einen Link auf das CMS<br /> <br /> ==Syntax==<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;spt:ilink value=&quot;&quot;/&gt;<br /> &lt;/source&gt; <br /> <br /> ==Beschreibung==<br /> Der &lt;code&gt;spt:ilink&lt;/code&gt;-Tag generiert einen Link auf die Bearbeitung des entsprechenden Artikels. Diese Links sind klassisch in der Website nur für Redakteure sichtbar und erlauben das Öffnen des aktuellen Artikels in der Bearbeitung von InfoSite direkt aus der Website heraus.<br /> <br /> Seit InfoSite 6 ist auch die Verwendung des i!-Links für interne Links auf andere Artikel innerhalb des CMS möglich.<br /> <br /> ==Attribute==<br /> {| class=&quot;prettytable&quot;<br /> |- class=&quot;hintergrundfarbe1&quot;<br /> ! Name || Type || Required || Default || ab IES Version<br /> |-<br /> | &lt;code&gt;value&lt;/code&gt;<br /> | [[Text]]<br /> | Nein<br /> | None<br /> | 1<br /> |-<br /> | &lt;code&gt;information&lt;/code&gt;<br /> | [[Attribute]]<br /> | Nein<br /> | None<br /> | 1<br /> |-<br /> | &lt;code&gt;step&lt;/code&gt;<br /> | [[Number]]<br /> | Nein<br /> | None<br /> | 2.0.1<br /> |}<br /> <br /> ;&lt;code&gt;value&lt;/code&gt;<br /> :Code für den generierten i-Link.<br /> <br /> ;&lt;code&gt;information&lt;/code&gt;<br /> :Optionale Angabe eines Artikels, auf den der Link zeigen soll (z.B. für Listen).<br /> <br /> ;&lt;code&gt;step&lt;/code&gt;<br /> :Bei Templates, die mit mehreren Steps aufgebaut sind ist hiermit der Sprung an eine definierte Stelle möglich. Die Angabe erfolgt relativ zum Step &quot;Verwaltung&quot;.<br /> <br /> ==Beispiele==<br /> <br /> ===Einfacher Artikel mit i-Link===<br /> <br /> Template Quelltext<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;sp:io type=&quot;in&quot;&gt;<br /> &lt;sp:text name=&quot;headline&quot;/&gt;<br /> &lt;/sp:io&gt;<br /> <br /> &lt;%-- einfacher Seiten-i-Link --%&gt;<br /> &lt;sp:io type=&quot;out&quot;&gt;<br /> &lt;sp:print name=&quot;headline&quot;/&gt;<br /> &lt;/sp:io&gt;<br /> <br /> &lt;spt:ilink value=&quot;Artikel bearbeiten&quot;&quot;/&gt;<br /> <br /> &lt;%-- Loop pro Treffer ein i-Link --%&gt;<br /> &lt;sp:io type=&quot;out&quot;&gt;<br /> &lt;sp:loop collection=&quot;collection&quot; item=&quot;it&quot;&gt;<br /> &lt;ul class=&quot;linkIntern&quot;&gt;<br /> &lt;li&gt;<br /> &lt;a href=&quot;&lt;sp:print name=&quot;it.id.url&quot;/&gt;&quot;&gt;&lt;sp:print name=&quot;it.sp_title&quot;/&gt;&lt;/a&gt;<br /> &lt;div id=&quot;ilinkInline&quot;&gt;<br /> &lt;spt:ilink <br /> value=&quot;&lt;img src=\&quot;/img/ilink.gif\&quot; <br /> class=\&quot;ilink\&quot; <br /> width=\&quot;16\&quot; <br /> height=\&quot;16\&quot; <br /> alt=\&quot;Seite bearbeiten ...\&quot;&gt;&quot; <br /> information=&quot;${it.id}&quot;/&gt;<br /> &lt;/div&gt;<br /> &lt;/li&gt;<br /> &lt;/ul&gt;<br /> &lt;/sp:loop&gt;<br /> &lt;/sp:io&gt;<br /> &lt;/source&gt;<br /> <br /> <br /> <br /> &lt;noinclude&gt;<br /> [[Category:SPT-Tags]]<br /> [[Category:Qualität_des_Inhalts_prüfen]]<br /> [[Category:Qualität_des_Codes_prüfen]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=Systemvoraussetzungen&diff=6639 2014-03-17T23:54:12Z

<p>Liebold: /* Mailserver */</p> <hr /> <div>Aktuelle Systemvoraussetzungen für Neuinstallationen und den Betrieb des [[IES]].<br /> <br /> ===Betriebssysteme===<br /> Wir unterstützen nur 64bit-Betriebssysteme.<br /> &lt;div class=&quot;note&quot;&gt;<br /> 32-bit-Systeme werde nicht unterstützt.<br /> &lt;/div&gt;<br /> <br /> ====Linux====<br /> * CentOS Linux ab Version 6 (http://www.centos.org)<br /> * Ubuntu Linux ab Version 12 (http://www.ubuntu.com)<br /> * Red Hat Linux ab Version 6 (http://www.redhat.com)<br /> * Debian Linux ab Version 6 (http://www.debian.org)<br /> * Suse Linux Enterprise Server ab Version 11 (http://www.suse.com)<br /> * OpenSUSE ab Version 13 (bzw. http://www.opensuse.org/)<br /> &lt;div class=&quot;note&quot;&gt;<br /> Achtung: &quot;SUSE Linux Enterprise Server&quot;-Nutzer. Grundsätzlich ist unsere Software auf SLES lauffähig; aufgrund von nicht in Standardrepositories vorhandenen Softwaren (u.a. ImageMagick, MySQL &gt; 5.0, Xvfb) ist die Installation und Konfiguration nur von versierten Administratoren vorzunehmen. Gerne bieten wir hier exklusive Installationsschulung oder -unterstützung an. &lt;strong&gt;Die Funktion zur Umwandlung einer Webseite in eine PDF-Datei steht unter SUSE NICHT bereit. Die dafür notwendige Software wird von SUSE NICHT zur Verfügung gestellt; das Herunterladen der Webseite als PDF funktioniert auf einem SUSE-System nicht.&lt;/strong&gt;<br /> &lt;/div&gt;<br /> <br /> =====Abhängigkeiten=====<br /> * ImageMagick (http://www.imagemagick.org/) ab Version 6<br /> * curl, grep, egrep, netstat, ps, tail, useradd, groupadd, chown, sum, awk, head, nm, bc<br /> Die hier genannten Abhängigkeiten sind durch die aufgeführten Distributionen erfüllbar und werden teilweise bereits automatisch installiert.<br /> <br /> (''Hinweis:'' Je nach Linux-Distribution sind einzelne Tools zum Beispiel in Paketen wie &lt;code&gt;net-tools&lt;/code&gt;, &lt;code&gt;coreutils&lt;/code&gt;, &lt;code&gt;binutils&lt;/code&gt;, &lt;code&gt;passwd&lt;/code&gt; und anderen organisiert.)<br /> <br /> ====Windows====<br /> * '''Windows Server''' Version 2008 R2 (64bit) (http://www.microsoft.com)<br /> * Windows 7 und Windows 8 werden als Betriebssysteme nicht unterstützt.<br /> <br /> &lt;div class=&quot;note&quot;&gt;<br /> Die Verwendung von Windows als Betriebssystem für den Webserver wird von Sitepark NICHT empfohlen. PHP kann auch unter einem 64bit-Windows nur mit 32bit-Integer-Zahlen arbeiten; alle PHP-Anwendungen, die mit von Java übergebenen Zeitstempeln im Millisekundenbereich rechnen, sind nicht korrekt lauffähig.<br /> &lt;/div&gt;<br /> <br /> =====Abhängigkeiten=====<br /> * ImageMagick (http://www.imagemagick.org/) ab Version 6<br /> * mTail (http://ophilipp.free.fr/op_tail.htm) (Zur Wartung und Administration)<br /> * 7-Zip (http://www.7-zip.org/) (Zip-Funktionen des Windows-Explorers reichen nicht aus) (Zur Wartung und Administration)<br /> * Process Explorer (http://technet.microsoft.com/de-de/sysinternals/bb896653) (Zur Wartung und Administration)<br /> * Process Monitor (http://technet.microsoft.com/de-de/sysinternals/bb896645) (Zur Wartung und Administration)<br /> <br /> <br /> ===Hardware===<br /> Die Leistungsstärke der Hardware ist in Abhängigkeit zum zu realisierenden Projekt individuell unterschiedlich. Die hier angegebenen Anforderungen und Empfehlungen sind als Richtwerte zu verstehen.<br /> <br /> Relevante Kenngrößen sind die CPU-Leistungsfähigkeit, die RAM-Größe, die Zugriffsgeschwindigkeit auf die Speichergeräte (Festplatten) und die Netzwerkanbindung.<br /> <br /> Der IES hält während des Betriebs im optimalen Fall alle von ihm verwaltetet Daten im Arbeitsspeicher, ebenso sollte die MySQL-Datenbank komplett dort liegen. Auslagerungen auf die Festplatte bremsen das System unnötig aus. Der IES schreibt datenbankunabhängige echte Webseiten auf die Festplatte. Diese Dateien werden vom Webserver ausgeliefert; dabei findet kein Datenbankzugriff mehr statt. Ein schnelles Schreiben der Daten für den Webserver (Festplatten-Schreib-Geschwindigkeit) ist ebenso notwendig wie ein schnelles Lesen der Daten für die Auslieferung. Wenn das Dateisystem für den die Seiten ausliefernden Webserver über das Netzwerk verfügbar gemacht wird, ist die Netzwerkgeschwindigkeit ebenfalls für ein performantes Gesamtsystem sehr wichtig.<br /> &lt;div class=&quot;note&quot;&gt;<br /> Die Anforderungen können sich während des Betriebs des IES je nach Anwendungsszenario und Veränderungen in der Datenmenge oder Nutzermenge verändern. Mehr Daten benötigen mehr Speicherplatz (RAM und Festplatte), höhere Nutzungsfrequenzen benötigen schnellere bzw. breitere Netzwerk-Anbindungen und CPU-Leistungsfähigkeit. Wir empfehlen den Betrieb in einer virtuellen Umgebung, damit Sie flexibel auf Änderungen der Anforderungen reagieren können.<br /> &lt;/div&gt;<br /> <br /> ====Minimal-Anforderung====<br /> Prozessor P4 1GHZ 64bit, 2 GB Hauptspeicher PLUS die 1,2fache Menge der Größe der MySQL-Datenbank, 18 GB HDD, Netzwerk<br /> <br /> ===Empfehlung===<br /> Mehrprozessorsystem (z.B. QuadCore) ~3GHz 64Bit, 8 GB RAM PLUS die 2fache Menge der Größe der MySQL-Datenbank, RAID-10-System mit 100 GB HDD, Gbit-Netzwerk<br /> <br /> Die Schreib- und Lesezugriffe auf die Festplatte sollten für ein performantes Arbeiten folgende Werte (im Durchschnitt) nicht unterschreiten: &lt;strong&gt;Lesen 300MB/sek, Schreiben 120MB/sek&lt;/strong&gt;.<br /> <br /> ===Java===<br /> ====JDK - Java Development Kit====<br /> Für den Betrieb des IES wird ein Java-Development-Kit inkl. Java-Compiler benötigt. Aktuell unterstützen wir die Pakete:<br /> * JDK (Java SDK) von Oracle ab der Version 1.7<br /> * OpenJDK 7 oder neuer<br /> * IBM-Java 7 JDK<br /> &lt;div class=&quot;note&quot;&gt;<br /> Eine Java Runtime Environment (JRE)-Version reicht nicht aus.<br /> &lt;/div&gt;<br /> <br /> ===Webserver===<br /> ====Apache 2====<br /> Weitere Informationen finden Sie unter http://www.apache.org<br /> <br /> Empfohlene Module für die Integration des IES in den Apache:<br /> mod_proxy<br /> mod_proxy_balancer<br /> mod_proxy_http<br /> mod_rewrite<br /> mod_ssl<br /> mod_headers <br /> <br /> Informationen zur Konfiguration finden Sie unter [[Integration des IES in den Apache]].<br /> <br /> Für die Auslieferung von Webseiten wird PHP benötigt; der Webserver benötigt dann verschiedene PHP-Erweiterungen [[Installationsanleitung PHP]].<br /> <br /> ===Datenbank===<br /> ====MySQL====<br /> Weitere Informationen finden Sie unter http://www.mysql.com<br /> <br /> MySQL ab der Version 5. Engine: INNODB<br /> <br /> Zur Konfiguration finden Sie unter [[Hinweise zu MySQL]] wichtige Informationen.<br /> <br /> ===Mailserver===<br /> Wird ein MailPublisher verwendet empfehlen wir aus unterschiedlichen Gründen die Installation eines lokalen Mailservers (Sendmail, Postfix, QMail, etc.) auch wenn in dem entsprechendem Netzwerk ein separater Mailserver konfiguriert wurde.<br /> <br /> Gründe für den Einsatz eines lokalen Mailservers:<br /> # Die Publikation von Artikeln über den Mail-Publisher ist wesentlich schneller, da keine Netzwerk-Kommunikation notwendig ist. Gerade beim Versand von Newslettern an sehr viele Adressaten ist hier ein signifikanter Performanzvorteil zu erkennen.<br /> # Bei Problemen im lokalen Netzwerk bzw. der temp. Überlastung des Mailservers werden keine E-Mails verschickt. Ein späterer Versand würde nicht erfolgen, da der IES nicht ''spooled''. Dies ist Aufgabe eines Mailservers und würde durch einen lokalen Mailserver auf ideale Weise erfüllt.<br /> <br /> Die Konfiguration des lokalen Mailservers sollte daher bereits bei der Installation des IES erfolgen. Der IES ist grundsätzlich für die lokale E-Mail-Auslieferung konfiguriert.<br /> <br /> &lt;noinclude&gt;<br /> [[Kategorie:Installation| 100]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=Systemvoraussetzungen&diff=6638 2014-03-17T23:53:26Z

<p>Liebold: /* Mailserver */</p> <hr /> <div>Aktuelle Systemvoraussetzungen für Neuinstallationen und den Betrieb des [[IES]].<br /> <br /> ===Betriebssysteme===<br /> Wir unterstützen nur 64bit-Betriebssysteme.<br /> &lt;div class=&quot;note&quot;&gt;<br /> 32-bit-Systeme werde nicht unterstützt.<br /> &lt;/div&gt;<br /> <br /> ====Linux====<br /> * CentOS Linux ab Version 6 (http://www.centos.org)<br /> * Ubuntu Linux ab Version 12 (http://www.ubuntu.com)<br /> * Red Hat Linux ab Version 6 (http://www.redhat.com)<br /> * Debian Linux ab Version 6 (http://www.debian.org)<br /> * Suse Linux Enterprise Server ab Version 11 (http://www.suse.com)<br /> * OpenSUSE ab Version 13 (bzw. http://www.opensuse.org/)<br /> &lt;div class=&quot;note&quot;&gt;<br /> Achtung: &quot;SUSE Linux Enterprise Server&quot;-Nutzer. Grundsätzlich ist unsere Software auf SLES lauffähig; aufgrund von nicht in Standardrepositories vorhandenen Softwaren (u.a. ImageMagick, MySQL &gt; 5.0, Xvfb) ist die Installation und Konfiguration nur von versierten Administratoren vorzunehmen. Gerne bieten wir hier exklusive Installationsschulung oder -unterstützung an. &lt;strong&gt;Die Funktion zur Umwandlung einer Webseite in eine PDF-Datei steht unter SUSE NICHT bereit. Die dafür notwendige Software wird von SUSE NICHT zur Verfügung gestellt; das Herunterladen der Webseite als PDF funktioniert auf einem SUSE-System nicht.&lt;/strong&gt;<br /> &lt;/div&gt;<br /> <br /> =====Abhängigkeiten=====<br /> * ImageMagick (http://www.imagemagick.org/) ab Version 6<br /> * curl, grep, egrep, netstat, ps, tail, useradd, groupadd, chown, sum, awk, head, nm, bc<br /> Die hier genannten Abhängigkeiten sind durch die aufgeführten Distributionen erfüllbar und werden teilweise bereits automatisch installiert.<br /> <br /> (''Hinweis:'' Je nach Linux-Distribution sind einzelne Tools zum Beispiel in Paketen wie &lt;code&gt;net-tools&lt;/code&gt;, &lt;code&gt;coreutils&lt;/code&gt;, &lt;code&gt;binutils&lt;/code&gt;, &lt;code&gt;passwd&lt;/code&gt; und anderen organisiert.)<br /> <br /> ====Windows====<br /> * '''Windows Server''' Version 2008 R2 (64bit) (http://www.microsoft.com)<br /> * Windows 7 und Windows 8 werden als Betriebssysteme nicht unterstützt.<br /> <br /> &lt;div class=&quot;note&quot;&gt;<br /> Die Verwendung von Windows als Betriebssystem für den Webserver wird von Sitepark NICHT empfohlen. PHP kann auch unter einem 64bit-Windows nur mit 32bit-Integer-Zahlen arbeiten; alle PHP-Anwendungen, die mit von Java übergebenen Zeitstempeln im Millisekundenbereich rechnen, sind nicht korrekt lauffähig.<br /> &lt;/div&gt;<br /> <br /> =====Abhängigkeiten=====<br /> * ImageMagick (http://www.imagemagick.org/) ab Version 6<br /> * mTail (http://ophilipp.free.fr/op_tail.htm) (Zur Wartung und Administration)<br /> * 7-Zip (http://www.7-zip.org/) (Zip-Funktionen des Windows-Explorers reichen nicht aus) (Zur Wartung und Administration)<br /> * Process Explorer (http://technet.microsoft.com/de-de/sysinternals/bb896653) (Zur Wartung und Administration)<br /> * Process Monitor (http://technet.microsoft.com/de-de/sysinternals/bb896645) (Zur Wartung und Administration)<br /> <br /> <br /> ===Hardware===<br /> Die Leistungsstärke der Hardware ist in Abhängigkeit zum zu realisierenden Projekt individuell unterschiedlich. Die hier angegebenen Anforderungen und Empfehlungen sind als Richtwerte zu verstehen.<br /> <br /> Relevante Kenngrößen sind die CPU-Leistungsfähigkeit, die RAM-Größe, die Zugriffsgeschwindigkeit auf die Speichergeräte (Festplatten) und die Netzwerkanbindung.<br /> <br /> Der IES hält während des Betriebs im optimalen Fall alle von ihm verwaltetet Daten im Arbeitsspeicher, ebenso sollte die MySQL-Datenbank komplett dort liegen. Auslagerungen auf die Festplatte bremsen das System unnötig aus. Der IES schreibt datenbankunabhängige echte Webseiten auf die Festplatte. Diese Dateien werden vom Webserver ausgeliefert; dabei findet kein Datenbankzugriff mehr statt. Ein schnelles Schreiben der Daten für den Webserver (Festplatten-Schreib-Geschwindigkeit) ist ebenso notwendig wie ein schnelles Lesen der Daten für die Auslieferung. Wenn das Dateisystem für den die Seiten ausliefernden Webserver über das Netzwerk verfügbar gemacht wird, ist die Netzwerkgeschwindigkeit ebenfalls für ein performantes Gesamtsystem sehr wichtig.<br /> &lt;div class=&quot;note&quot;&gt;<br /> Die Anforderungen können sich während des Betriebs des IES je nach Anwendungsszenario und Veränderungen in der Datenmenge oder Nutzermenge verändern. Mehr Daten benötigen mehr Speicherplatz (RAM und Festplatte), höhere Nutzungsfrequenzen benötigen schnellere bzw. breitere Netzwerk-Anbindungen und CPU-Leistungsfähigkeit. Wir empfehlen den Betrieb in einer virtuellen Umgebung, damit Sie flexibel auf Änderungen der Anforderungen reagieren können.<br /> &lt;/div&gt;<br /> <br /> ====Minimal-Anforderung====<br /> Prozessor P4 1GHZ 64bit, 2 GB Hauptspeicher PLUS die 1,2fache Menge der Größe der MySQL-Datenbank, 18 GB HDD, Netzwerk<br /> <br /> ===Empfehlung===<br /> Mehrprozessorsystem (z.B. QuadCore) ~3GHz 64Bit, 8 GB RAM PLUS die 2fache Menge der Größe der MySQL-Datenbank, RAID-10-System mit 100 GB HDD, Gbit-Netzwerk<br /> <br /> Die Schreib- und Lesezugriffe auf die Festplatte sollten für ein performantes Arbeiten folgende Werte (im Durchschnitt) nicht unterschreiten: &lt;strong&gt;Lesen 300MB/sek, Schreiben 120MB/sek&lt;/strong&gt;.<br /> <br /> ===Java===<br /> ====JDK - Java Development Kit====<br /> Für den Betrieb des IES wird ein Java-Development-Kit inkl. Java-Compiler benötigt. Aktuell unterstützen wir die Pakete:<br /> * JDK (Java SDK) von Oracle ab der Version 1.7<br /> * OpenJDK 7 oder neuer<br /> * IBM-Java 7 JDK<br /> &lt;div class=&quot;note&quot;&gt;<br /> Eine Java Runtime Environment (JRE)-Version reicht nicht aus.<br /> &lt;/div&gt;<br /> <br /> ===Webserver===<br /> ====Apache 2====<br /> Weitere Informationen finden Sie unter http://www.apache.org<br /> <br /> Empfohlene Module für die Integration des IES in den Apache:<br /> mod_proxy<br /> mod_proxy_balancer<br /> mod_proxy_http<br /> mod_rewrite<br /> mod_ssl<br /> mod_headers <br /> <br /> Informationen zur Konfiguration finden Sie unter [[Integration des IES in den Apache]].<br /> <br /> Für die Auslieferung von Webseiten wird PHP benötigt; der Webserver benötigt dann verschiedene PHP-Erweiterungen [[Installationsanleitung PHP]].<br /> <br /> ===Datenbank===<br /> ====MySQL====<br /> Weitere Informationen finden Sie unter http://www.mysql.com<br /> <br /> MySQL ab der Version 5. Engine: INNODB<br /> <br /> Zur Konfiguration finden Sie unter [[Hinweise zu MySQL]] wichtige Informationen.<br /> <br /> ===Mailserver===<br /> Wird ein MailPublisher verwendet empfehlen wir aus unterschiedlichen Gründen die Installation eines lokalen Mailservers (Sendmail, Postfix, QMail, etc.) auch wenn in dem entsprechendem Netzwerk ein separater Mailserver konfiguriert wurde.<br /> <br /> Gründe für den Einsatz eines lokalen Mailservers:<br /> # Die Publikation von Artikeln über den Mail-Publisher ist wesentlich schneller, da keine Netzwerk-Kommunikation notwendig ist. Gerade beim Versand von Newslettern an sehr viele Adressaten ist hier ein signifikanter Performanzvorteil zu erkennen.<br /> # Bei Problemen im lokalen Netzwerk bzw. der temp. Überlastung des Mailservers werden keine E-Mails verschickt. Ein späterer Versand würde nicht erfolgen, da der IES nicht ''spooled''. Dies ist Aufgabe eines Mailservers und würde durch einen lokaler Mailserver auf ideale Weise erfüllt.<br /> <br /> Die Konfiguration des lokalen Mailservers sollte daher bereits bei der Installation des IES erfolgen. Der IES ist grundsätzlich für die lokale E-Mail-Auslieferung konfiguriert.<br /> <br /> &lt;noinclude&gt;<br /> [[Kategorie:Installation| 100]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=Systemvoraussetzungen&diff=6637 2014-03-17T23:51:39Z

<p>Liebold: /* Linux */</p> <hr /> <div>Aktuelle Systemvoraussetzungen für Neuinstallationen und den Betrieb des [[IES]].<br /> <br /> ===Betriebssysteme===<br /> Wir unterstützen nur 64bit-Betriebssysteme.<br /> &lt;div class=&quot;note&quot;&gt;<br /> 32-bit-Systeme werde nicht unterstützt.<br /> &lt;/div&gt;<br /> <br /> ====Linux====<br /> * CentOS Linux ab Version 6 (http://www.centos.org)<br /> * Ubuntu Linux ab Version 12 (http://www.ubuntu.com)<br /> * Red Hat Linux ab Version 6 (http://www.redhat.com)<br /> * Debian Linux ab Version 6 (http://www.debian.org)<br /> * Suse Linux Enterprise Server ab Version 11 (http://www.suse.com)<br /> * OpenSUSE ab Version 13 (bzw. http://www.opensuse.org/)<br /> &lt;div class=&quot;note&quot;&gt;<br /> Achtung: &quot;SUSE Linux Enterprise Server&quot;-Nutzer. Grundsätzlich ist unsere Software auf SLES lauffähig; aufgrund von nicht in Standardrepositories vorhandenen Softwaren (u.a. ImageMagick, MySQL &gt; 5.0, Xvfb) ist die Installation und Konfiguration nur von versierten Administratoren vorzunehmen. Gerne bieten wir hier exklusive Installationsschulung oder -unterstützung an. &lt;strong&gt;Die Funktion zur Umwandlung einer Webseite in eine PDF-Datei steht unter SUSE NICHT bereit. Die dafür notwendige Software wird von SUSE NICHT zur Verfügung gestellt; das Herunterladen der Webseite als PDF funktioniert auf einem SUSE-System nicht.&lt;/strong&gt;<br /> &lt;/div&gt;<br /> <br /> =====Abhängigkeiten=====<br /> * ImageMagick (http://www.imagemagick.org/) ab Version 6<br /> * curl, grep, egrep, netstat, ps, tail, useradd, groupadd, chown, sum, awk, head, nm, bc<br /> Die hier genannten Abhängigkeiten sind durch die aufgeführten Distributionen erfüllbar und werden teilweise bereits automatisch installiert.<br /> <br /> (''Hinweis:'' Je nach Linux-Distribution sind einzelne Tools zum Beispiel in Paketen wie &lt;code&gt;net-tools&lt;/code&gt;, &lt;code&gt;coreutils&lt;/code&gt;, &lt;code&gt;binutils&lt;/code&gt;, &lt;code&gt;passwd&lt;/code&gt; und anderen organisiert.)<br /> <br /> ====Windows====<br /> * '''Windows Server''' Version 2008 R2 (64bit) (http://www.microsoft.com)<br /> * Windows 7 und Windows 8 werden als Betriebssysteme nicht unterstützt.<br /> <br /> &lt;div class=&quot;note&quot;&gt;<br /> Die Verwendung von Windows als Betriebssystem für den Webserver wird von Sitepark NICHT empfohlen. PHP kann auch unter einem 64bit-Windows nur mit 32bit-Integer-Zahlen arbeiten; alle PHP-Anwendungen, die mit von Java übergebenen Zeitstempeln im Millisekundenbereich rechnen, sind nicht korrekt lauffähig.<br /> &lt;/div&gt;<br /> <br /> =====Abhängigkeiten=====<br /> * ImageMagick (http://www.imagemagick.org/) ab Version 6<br /> * mTail (http://ophilipp.free.fr/op_tail.htm) (Zur Wartung und Administration)<br /> * 7-Zip (http://www.7-zip.org/) (Zip-Funktionen des Windows-Explorers reichen nicht aus) (Zur Wartung und Administration)<br /> * Process Explorer (http://technet.microsoft.com/de-de/sysinternals/bb896653) (Zur Wartung und Administration)<br /> * Process Monitor (http://technet.microsoft.com/de-de/sysinternals/bb896645) (Zur Wartung und Administration)<br /> <br /> <br /> ===Hardware===<br /> Die Leistungsstärke der Hardware ist in Abhängigkeit zum zu realisierenden Projekt individuell unterschiedlich. Die hier angegebenen Anforderungen und Empfehlungen sind als Richtwerte zu verstehen.<br /> <br /> Relevante Kenngrößen sind die CPU-Leistungsfähigkeit, die RAM-Größe, die Zugriffsgeschwindigkeit auf die Speichergeräte (Festplatten) und die Netzwerkanbindung.<br /> <br /> Der IES hält während des Betriebs im optimalen Fall alle von ihm verwaltetet Daten im Arbeitsspeicher, ebenso sollte die MySQL-Datenbank komplett dort liegen. Auslagerungen auf die Festplatte bremsen das System unnötig aus. Der IES schreibt datenbankunabhängige echte Webseiten auf die Festplatte. Diese Dateien werden vom Webserver ausgeliefert; dabei findet kein Datenbankzugriff mehr statt. Ein schnelles Schreiben der Daten für den Webserver (Festplatten-Schreib-Geschwindigkeit) ist ebenso notwendig wie ein schnelles Lesen der Daten für die Auslieferung. Wenn das Dateisystem für den die Seiten ausliefernden Webserver über das Netzwerk verfügbar gemacht wird, ist die Netzwerkgeschwindigkeit ebenfalls für ein performantes Gesamtsystem sehr wichtig.<br /> &lt;div class=&quot;note&quot;&gt;<br /> Die Anforderungen können sich während des Betriebs des IES je nach Anwendungsszenario und Veränderungen in der Datenmenge oder Nutzermenge verändern. Mehr Daten benötigen mehr Speicherplatz (RAM und Festplatte), höhere Nutzungsfrequenzen benötigen schnellere bzw. breitere Netzwerk-Anbindungen und CPU-Leistungsfähigkeit. Wir empfehlen den Betrieb in einer virtuellen Umgebung, damit Sie flexibel auf Änderungen der Anforderungen reagieren können.<br /> &lt;/div&gt;<br /> <br /> ====Minimal-Anforderung====<br /> Prozessor P4 1GHZ 64bit, 2 GB Hauptspeicher PLUS die 1,2fache Menge der Größe der MySQL-Datenbank, 18 GB HDD, Netzwerk<br /> <br /> ===Empfehlung===<br /> Mehrprozessorsystem (z.B. QuadCore) ~3GHz 64Bit, 8 GB RAM PLUS die 2fache Menge der Größe der MySQL-Datenbank, RAID-10-System mit 100 GB HDD, Gbit-Netzwerk<br /> <br /> Die Schreib- und Lesezugriffe auf die Festplatte sollten für ein performantes Arbeiten folgende Werte (im Durchschnitt) nicht unterschreiten: &lt;strong&gt;Lesen 300MB/sek, Schreiben 120MB/sek&lt;/strong&gt;.<br /> <br /> ===Java===<br /> ====JDK - Java Development Kit====<br /> Für den Betrieb des IES wird ein Java-Development-Kit inkl. Java-Compiler benötigt. Aktuell unterstützen wir die Pakete:<br /> * JDK (Java SDK) von Oracle ab der Version 1.7<br /> * OpenJDK 7 oder neuer<br /> * IBM-Java 7 JDK<br /> &lt;div class=&quot;note&quot;&gt;<br /> Eine Java Runtime Environment (JRE)-Version reicht nicht aus.<br /> &lt;/div&gt;<br /> <br /> ===Webserver===<br /> ====Apache 2====<br /> Weitere Informationen finden Sie unter http://www.apache.org<br /> <br /> Empfohlene Module für die Integration des IES in den Apache:<br /> mod_proxy<br /> mod_proxy_balancer<br /> mod_proxy_http<br /> mod_rewrite<br /> mod_ssl<br /> mod_headers <br /> <br /> Informationen zur Konfiguration finden Sie unter [[Integration des IES in den Apache]].<br /> <br /> Für die Auslieferung von Webseiten wird PHP benötigt; der Webserver benötigt dann verschiedene PHP-Erweiterungen [[Installationsanleitung PHP]].<br /> <br /> ===Datenbank===<br /> ====MySQL====<br /> Weitere Informationen finden Sie unter http://www.mysql.com<br /> <br /> MySQL ab der Version 5. Engine: INNODB<br /> <br /> Zur Konfiguration finden Sie unter [[Hinweise zu MySQL]] wichtige Informationen.<br /> <br /> ===Mailserver===<br /> Wird ein MailPublisher verwendet empfehlen wir aus unterschiedlichen Gründen die Installation eines lokalen Mailservers (Sendmail, Postfix, QMail, etc.) auch wenn in dem entsprechendem Netzwerk ein separater Mailserver konfiguriert wurde.<br /> <br /> Gründe für den Einsatz eines lokalen Mailservers:<br /> # Die Publikation von Artikeln über den Mail-Publisher ist wesentlich schneller, da keine Netzwerk-Kommunikation notwendig ist. Gerade beim Versand von Newslettern an sehr viele Adressaten ist hier ein signifikanter Performanzvorteil zu erkennen.<br /> # Bei Problemen im lokalen Netzwerk bzw. der temp. Überlastung des Mailservers werden keine E-Mails verschickt. Ein späterer Versandt würde nicht erfolgen, da der IES nicht ''spooled''. Dies ist Aufgabe eines Mailservers würde durch einen lokaler Mailserver auf ideale Weise erfüllt.<br /> <br /> Die Konfiguration des lokalen Mailservers sollte daher bereits bei der Installation des IES erfolgen. Der IES ist grundsätzlich für die lokale E-Mail-Auslieferung konfiguriert.<br /> <br /> &lt;noinclude&gt;<br /> [[Kategorie:Installation| 100]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=Systemvoraussetzungen&diff=6636 2014-03-17T23:51:20Z

<p>Liebold: /* Linux */</p> <hr /> <div>Aktuelle Systemvoraussetzungen für Neuinstallationen und den Betrieb des [[IES]].<br /> <br /> ===Betriebssysteme===<br /> Wir unterstützen nur 64bit-Betriebssysteme.<br /> &lt;div class=&quot;note&quot;&gt;<br /> 32-bit-Systeme werde nicht unterstützt.<br /> &lt;/div&gt;<br /> <br /> ====Linux====<br /> * CentOS Linux ab Version 6 (http://www.centos.org)<br /> * Ubuntu Linux ab Version 12 (http://www.ubuntu.com)<br /> * Red Hat Linux ab Version 6 (http://www.redhat.com)<br /> * Debian Linux ab Version 6 (http://www.debian.org)<br /> * Suse Linux Enterprise Server ab Version 11 (http://www.suse.com)<br /> * OpenSUSE ab Version 13 (bzw. http://www.opensuse.org/)<br /> &lt;div class=&quot;note&quot;&gt;<br /> Achtung: &quot;SuSE Linux Enterprise Server&quot;-Nutzer. Grundsätzlich ist unsere Software auf SLES lauffähig; aufgrund von nicht in Standardrepositories vorhandenen Softwaren (u.a. ImageMagick, MySQL &gt; 5.0, Xvfb) ist die Installation und Konfiguration nur von versierten Administratoren vorzunehmen. Gerne bieten wir hier exklusive Installationsschulung oder -unterstützung an. &lt;strong&gt;Die Funktion zur Umwandlung einer Webseite in eine PDF-Datei steht unter SUSE NICHT bereit. Die dafür notwendige Software wird von SUSE NICHT zur Verfügung gestellt; das Herunterladen der Webseite als PDF funktioniert auf einem SUSE-System nicht.&lt;/strong&gt;<br /> &lt;/div&gt;<br /> <br /> =====Abhängigkeiten=====<br /> * ImageMagick (http://www.imagemagick.org/) ab Version 6<br /> * curl, grep, egrep, netstat, ps, tail, useradd, groupadd, chown, sum, awk, head, nm, bc<br /> Die hier genannten Abhängigkeiten sind durch die aufgeführten Distributionen erfüllbar und werden teilweise bereits automatisch installiert.<br /> <br /> (''Hinweis:'' Je nach Linux-Distribution sind einzelne Tools zum Beispiel in Paketen wie &lt;code&gt;net-tools&lt;/code&gt;, &lt;code&gt;coreutils&lt;/code&gt;, &lt;code&gt;binutils&lt;/code&gt;, &lt;code&gt;passwd&lt;/code&gt; und anderen organisiert.)<br /> <br /> ====Windows====<br /> * '''Windows Server''' Version 2008 R2 (64bit) (http://www.microsoft.com)<br /> * Windows 7 und Windows 8 werden als Betriebssysteme nicht unterstützt.<br /> <br /> &lt;div class=&quot;note&quot;&gt;<br /> Die Verwendung von Windows als Betriebssystem für den Webserver wird von Sitepark NICHT empfohlen. PHP kann auch unter einem 64bit-Windows nur mit 32bit-Integer-Zahlen arbeiten; alle PHP-Anwendungen, die mit von Java übergebenen Zeitstempeln im Millisekundenbereich rechnen, sind nicht korrekt lauffähig.<br /> &lt;/div&gt;<br /> <br /> =====Abhängigkeiten=====<br /> * ImageMagick (http://www.imagemagick.org/) ab Version 6<br /> * mTail (http://ophilipp.free.fr/op_tail.htm) (Zur Wartung und Administration)<br /> * 7-Zip (http://www.7-zip.org/) (Zip-Funktionen des Windows-Explorers reichen nicht aus) (Zur Wartung und Administration)<br /> * Process Explorer (http://technet.microsoft.com/de-de/sysinternals/bb896653) (Zur Wartung und Administration)<br /> * Process Monitor (http://technet.microsoft.com/de-de/sysinternals/bb896645) (Zur Wartung und Administration)<br /> <br /> <br /> ===Hardware===<br /> Die Leistungsstärke der Hardware ist in Abhängigkeit zum zu realisierenden Projekt individuell unterschiedlich. Die hier angegebenen Anforderungen und Empfehlungen sind als Richtwerte zu verstehen.<br /> <br /> Relevante Kenngrößen sind die CPU-Leistungsfähigkeit, die RAM-Größe, die Zugriffsgeschwindigkeit auf die Speichergeräte (Festplatten) und die Netzwerkanbindung.<br /> <br /> Der IES hält während des Betriebs im optimalen Fall alle von ihm verwaltetet Daten im Arbeitsspeicher, ebenso sollte die MySQL-Datenbank komplett dort liegen. Auslagerungen auf die Festplatte bremsen das System unnötig aus. Der IES schreibt datenbankunabhängige echte Webseiten auf die Festplatte. Diese Dateien werden vom Webserver ausgeliefert; dabei findet kein Datenbankzugriff mehr statt. Ein schnelles Schreiben der Daten für den Webserver (Festplatten-Schreib-Geschwindigkeit) ist ebenso notwendig wie ein schnelles Lesen der Daten für die Auslieferung. Wenn das Dateisystem für den die Seiten ausliefernden Webserver über das Netzwerk verfügbar gemacht wird, ist die Netzwerkgeschwindigkeit ebenfalls für ein performantes Gesamtsystem sehr wichtig.<br /> &lt;div class=&quot;note&quot;&gt;<br /> Die Anforderungen können sich während des Betriebs des IES je nach Anwendungsszenario und Veränderungen in der Datenmenge oder Nutzermenge verändern. Mehr Daten benötigen mehr Speicherplatz (RAM und Festplatte), höhere Nutzungsfrequenzen benötigen schnellere bzw. breitere Netzwerk-Anbindungen und CPU-Leistungsfähigkeit. Wir empfehlen den Betrieb in einer virtuellen Umgebung, damit Sie flexibel auf Änderungen der Anforderungen reagieren können.<br /> &lt;/div&gt;<br /> <br /> ====Minimal-Anforderung====<br /> Prozessor P4 1GHZ 64bit, 2 GB Hauptspeicher PLUS die 1,2fache Menge der Größe der MySQL-Datenbank, 18 GB HDD, Netzwerk<br /> <br /> ===Empfehlung===<br /> Mehrprozessorsystem (z.B. QuadCore) ~3GHz 64Bit, 8 GB RAM PLUS die 2fache Menge der Größe der MySQL-Datenbank, RAID-10-System mit 100 GB HDD, Gbit-Netzwerk<br /> <br /> Die Schreib- und Lesezugriffe auf die Festplatte sollten für ein performantes Arbeiten folgende Werte (im Durchschnitt) nicht unterschreiten: &lt;strong&gt;Lesen 300MB/sek, Schreiben 120MB/sek&lt;/strong&gt;.<br /> <br /> ===Java===<br /> ====JDK - Java Development Kit====<br /> Für den Betrieb des IES wird ein Java-Development-Kit inkl. Java-Compiler benötigt. Aktuell unterstützen wir die Pakete:<br /> * JDK (Java SDK) von Oracle ab der Version 1.7<br /> * OpenJDK 7 oder neuer<br /> * IBM-Java 7 JDK<br /> &lt;div class=&quot;note&quot;&gt;<br /> Eine Java Runtime Environment (JRE)-Version reicht nicht aus.<br /> &lt;/div&gt;<br /> <br /> ===Webserver===<br /> ====Apache 2====<br /> Weitere Informationen finden Sie unter http://www.apache.org<br /> <br /> Empfohlene Module für die Integration des IES in den Apache:<br /> mod_proxy<br /> mod_proxy_balancer<br /> mod_proxy_http<br /> mod_rewrite<br /> mod_ssl<br /> mod_headers <br /> <br /> Informationen zur Konfiguration finden Sie unter [[Integration des IES in den Apache]].<br /> <br /> Für die Auslieferung von Webseiten wird PHP benötigt; der Webserver benötigt dann verschiedene PHP-Erweiterungen [[Installationsanleitung PHP]].<br /> <br /> ===Datenbank===<br /> ====MySQL====<br /> Weitere Informationen finden Sie unter http://www.mysql.com<br /> <br /> MySQL ab der Version 5. Engine: INNODB<br /> <br /> Zur Konfiguration finden Sie unter [[Hinweise zu MySQL]] wichtige Informationen.<br /> <br /> ===Mailserver===<br /> Wird ein MailPublisher verwendet empfehlen wir aus unterschiedlichen Gründen die Installation eines lokalen Mailservers (Sendmail, Postfix, QMail, etc.) auch wenn in dem entsprechendem Netzwerk ein separater Mailserver konfiguriert wurde.<br /> <br /> Gründe für den Einsatz eines lokalen Mailservers:<br /> # Die Publikation von Artikeln über den Mail-Publisher ist wesentlich schneller, da keine Netzwerk-Kommunikation notwendig ist. Gerade beim Versand von Newslettern an sehr viele Adressaten ist hier ein signifikanter Performanzvorteil zu erkennen.<br /> # Bei Problemen im lokalen Netzwerk bzw. der temp. Überlastung des Mailservers werden keine E-Mails verschickt. Ein späterer Versandt würde nicht erfolgen, da der IES nicht ''spooled''. Dies ist Aufgabe eines Mailservers würde durch einen lokaler Mailserver auf ideale Weise erfüllt.<br /> <br /> Die Konfiguration des lokalen Mailservers sollte daher bereits bei der Installation des IES erfolgen. Der IES ist grundsätzlich für die lokale E-Mail-Auslieferung konfiguriert.<br /> <br /> &lt;noinclude&gt;<br /> [[Kategorie:Installation| 100]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=FormSolutions_Schnittstelle&diff=5843 2012-05-15T13:08:59Z

<p>Liebold: </p> <hr /> <div>Formulare der Firma [http://www.form-solutions.de Form-Solutions] können in den IES integriert werden. Hierzu ist eine Form-Solutions Lizenz erforderlich.<br /> <br /> ===Funktionsweise===<br /> Referenzen der Formulare werden in den IES (Sitepark Information Enterprise Server) importiert und durch regelmäßige Imports synchron gehalten. Mit Hilfe des [[spt:formsolutions]]-Tag kann ein Link-Dialog geöffnet werden, um ein Formulare zu verwenden. Für jede erzeugte Verlinkung wird eine neue URL erzeugt. Über dieser URL kann das Formular vom Form-Solutions-Server geladen werden (Z.B. PDF). Der [[spt:formsolutions]]-Tag erzeugt einen Button über den das Formular konfiguriert werden kann. Nach Klick auf diesen Button öffnet sich eine Seite des Form-Solutions-Servers mit der das Formular konfiguriert wird.<br /> <br /> ===Voraussetzungen===<br /> Um die Form-Solutions-Schnittstelle einrichten zu können müssen folgende Voraussetzungen gegeben sein:<br /> * Der Kunde muss eine Form-Solutions Lizenz besitzen, um den den Form-Solutions-Server ansprechen zu können<br /> * Der IES muss Zugang zum Internet haben, um den Formsolutions-Server erreichen zu können.<br /> * Die Redakteure, die die Formulare Verknüpfen sollen, müssen Zugang zum Internet haben, um den Formsolutions-Server erreichen zu können.<br /> * Es muß ein CMS-Key für die Form-Solutions-Schnittstelle bekannt sein der vom IES verwendet werden kann. Dieser Key wird den Kunden von Form-Solutions genannt. Der Key sollte keine Sonderzeichen enthalten!<br /> * Die zu verwendenden Formulare werden zur Personalisierung mit einem Form-Solutions-Nutzer verknüpft. Hier muss ein Default-Nutzer bekannt sein, der initial für neue Formular-Links verwendet wird. Diese Nutzer kann bei der weiteren Konfiguration des Formulars geändert werden. Für die Form-Solutions-Schnittelle ist eine Default-Nutzer-Nummer erforderlich. Sie muss das Format &lt;code&gt;00000000-0001-0001&lt;/code&gt; haben.<br /> * Es muss ein TemplatePool mit dem Anchor '&lt;code&gt;formsolutions.template.pool&lt;/code&gt;' existieren, der unterhalb des Pools 'Seitentemplates' hinterlegt ist oder das Flag 'Dieser Pool enthält Seitentemplates' gesetzt hat. <br /> * Es muss ein ArtikelPool mit dem Anchor '&lt;code&gt;formsolutions&lt;/code&gt;' existieren. Dieser Pool besitzt den 'Standard Infosite Container' sowie das Template für die Eigenschaften 'nur Resourcen anlegen'. Der 'Templatepool für die Bearbeitung' ist der zuvor angelegte TemplatePool 'formsolutions.template.pool'.<br /> * Es muss folgendes Template mit dem Anchor '&lt;code&gt;formsolutions.template.config&lt;/code&gt;' angelegt sein:<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;sp:io type=&quot;in&quot;&gt;<br /> &lt;em&gt;<br /> Diese Konfigurationswerte werden über den Form-Solutions import gesetzt und können an dieser Stellen nicht geändert werden.<br /> Ist eine Änderung der Werte nötig, muss diese Änderung am Importer vorgenommen werden.<br /> &lt;/em&gt;<br /> &lt;br/&gt;<br /> &lt;br/&gt;<br /> Webservice Url&lt;br&gt;<br /> &lt;spt:text name=&quot;wsurl&quot; readonly=&quot;false&quot; size=&quot;80&quot;/&gt;&lt;br/&gt;<br /> CMS-Key&lt;br&gt;<br /> &lt;spt:text name=&quot;cms&quot; readonly=&quot;true&quot; size=&quot;80&quot;/&gt;&lt;br/&gt;<br /> Nutzer-Nummer&lt;br&gt;<br /> &lt;spt:text name=&quot;user&quot; readonly=&quot;true&quot; size=&quot;80&quot;/&gt;&lt;br/&gt;<br /> &lt;/sp:io&gt;<br /> &lt;/source&gt;<br /> * Es muss folgendes Template mit dem Anchor '&lt;code&gt;formsolutions.template.form&lt;/code&gt;' angelegt sein:<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;sp:io type=&quot;in&quot;&gt;<br /> Formular-Nummer&lt;br/&gt;<br /> &lt;spt:text name=&quot;fs_fnr&quot;/&gt;&lt;br/&gt;<br /> Anzahl der Seiten&lt;br/&gt;<br /> &lt;spt:text name=&quot;fs_pagecount&quot;/&gt;&lt;br/&gt;<br /> Erzeugt am&lt;br/&gt;<br /> &lt;spt:text name=&quot;fs_created&quot;/&gt;&lt;br/&gt;<br /> Letzte Änderung am&lt;br/&gt;<br /> &lt;spt:text name=&quot;fs_changed&quot;/&gt;&lt;br/&gt;<br /> Bemerkung&lt;br/&gt;<br /> &lt;spt:text name=&quot;fs_bem&quot;/&gt;&lt;br/&gt;<br /> Beschreibung&lt;br/&gt;<br /> &lt;spt:text name=&quot;fs_beschr&quot;/&gt;&lt;br/&gt;<br /> Typ&lt;br/&gt;<br /> &lt;spt:text name=&quot;fs_type&quot;/&gt;&lt;br/&gt;<br /> &lt;/sp:io&gt;&lt;/source&gt;<br /> <br /> ===Konfiguration===<br /> Um den Import einrichten zu können müssen von dem Kunden folgende Informationen bereit gestellt werden:<br /> * CMS-Key des Kunden-Accounts<br /> * Kunden-Account: Login und Passwort<br /> <br /> Dann sind folgende Dateien in &lt;code&gt;/etc/sitepark&lt;/code&gt; anzulegen:<br /> <br /> '''&lt;code&gt;form-solutions.xml&lt;/code&gt;'''&lt;br&gt;<br /> Hier &lt;strong&gt;müssen&lt;/strong&gt; die Variablen ''cmskey'' und ''user'' entsprechend den Daten des Kunden ersetzt werden.&lt;br&gt;<br /> &lt;strong style=&quot;color:red&quot;&gt;Vorsicht:&lt;/strong&gt; Sollte der Key Zeichen wie '&amp;' enthalten, muss der unten verwendete Platzhalter '${cmskey}' gegen den XML encodeten Key getauscht werden!<br /> <br /> &lt;syntaxhighlight lang=&quot;xml&quot;&gt;<br /> &lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;<br /> &lt;ies-client&gt;<br /> &lt;logging&gt;<br /> &lt;appender name=&quot;FILE&quot; class=&quot;org.apache.log4j.RollingFileAppender&quot;&gt;<br /> &lt;layout class=&quot;org.apache.log4j.PatternLayout&quot;&gt;<br /> &lt;param name=&quot;ConversionPattern&quot; value=&quot;%d %-5p %m%n&quot;/&gt;<br /> &lt;/layout&gt;<br /> &lt;param name=&quot;File&quot; value=&quot;${sitepark.home}/form-solutions.log&quot;/&gt;<br /> &lt;param name=&quot;MaxFileSize&quot; value=&quot;10MB&quot;/&gt;<br /> &lt;param name=&quot;MaxBackupIndex&quot; value=&quot;10&quot;/&gt;<br /> &lt;/appender&gt;<br /> &lt;logger name=&quot;com.sitepark.ies&quot; additivity=&quot;false&quot;&gt;<br /> &lt;appender-ref ref=&quot;FILE&quot;/&gt;<br /> &lt;priority value=&quot;INFO&quot;/&gt;<br /> &lt;/logger&gt;<br /> &lt;/logging&gt; <br /> &lt;ies-connection login=&quot;login&quot; password=&quot;password&quot; client=&quot;anchor_of_the_client&quot; module=&quot;Form Solutions Importer&quot;/&gt;<br /> &lt;properties&gt;<br /> &lt;property name=&quot;ies.xip.import.deleteWorkDir&quot;&gt;true&lt;/property&gt;<br /> &lt;property name=&quot;ies.xip.import.syncfile&quot;&gt;${sitepark.home}/conf/form-solutions.sync&lt;/property&gt;<br /> &lt;property name=&quot;ies.xip.import.publishMode&quot;&gt;all-file&lt;/property&gt;<br /> &lt;property name=&quot;ies.xip.import.ignoreParents&quot;&gt;false&lt;/property&gt;<br /> &lt;property name=&quot;ies.xip.import.deleteElements&quot;&gt;true&lt;/property&gt;<br /> &lt;property name=&quot;ies.xip.import.deletePools&quot;&gt;true&lt;/property&gt;<br /> &lt;property name=&quot;ies.xip.import.deleteOnlyEmptyPools&quot;&gt;true&lt;/property&gt;<br /> &lt;property name=&quot;ies.xip.import.variables&quot;&gt;wsurl=https://pdf.form-solutions.net/ws2&lt;/property&gt;<br /> &lt;property name=&quot;ies.xip.import.variables&quot;&gt;cmskey=293478912hskdfh238&lt;/property&gt;<br /> &lt;property name=&quot;ies.xip.import.variables&quot;&gt;user=12345678-1234-1234&lt;/property&gt;<br /> &lt;/properties&gt;<br /> &lt;xip command=&quot;import&quot;&gt; <br /> &lt;source type=&quot;http&quot; url=&quot;${wsurl}/getformlist.php&quot; method=&quot;post&quot;&gt;<br /> &lt;header name=&quot;SOAPAction&quot;&gt;&quot;urn:FS#getformlist&quot;&lt;/header&gt;<br /> &lt;body content-type=&quot;text/xml; charset=UTF-8&quot;&gt;&lt;![CDATA[&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;<br /> &lt;SOAP-ENV:Envelope xmlns:SOAP-ENV=&quot;http://schemas.xmlsoap.org/soap/envelope/&quot; xmlns:xsd=&quot;http://www.w3.org/2001/XMLSchema&quot; xmlns:xsi=&quot;http://www.w3.org/2001/XMLSchema-instance&quot; xmlns:SOAP-ENC=&quot;http://schemas.xmlsoap.org/soap/encoding/&quot; xmlns:tns=&quot;urn:FS&quot; SOAP-ENV:encodingStyle=&quot;http://schemas.xmlsoap.org/soap/encoding/&quot;&gt;<br /> &lt;SOAP-ENV:Body&gt;<br /> &lt;tns:getformlist xmlns:tns=&quot;urn:FS&quot;&gt;<br /> &lt;cms xsi:type=&quot;xsd:string&quot;&gt;${cmskey}&lt;/cms&gt;<br /> &lt;/tns:getformlist&gt;<br /> &lt;/SOAP-ENV:Body&gt;<br /> &lt;/SOAP-ENV:Envelope&gt;]]&gt;&lt;/body&gt;<br /> &lt;/source&gt;<br /> &lt;transform xslt=&quot;${sitepark.home}/conf/form-solutions.xslt&quot;/&gt;<br /> &lt;/xip&gt;<br /> &lt;/ies-client&gt;<br /> &lt;/syntaxhighlight&gt;<br /> <br /> '''&lt;code&gt;form-solutions.xslt&lt;/code&gt;'''<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;?xml version=&quot;1.0&quot; encoding=&quot;ISO-8859-1&quot;?&gt;<br /> &lt;xsl:stylesheet version=&quot;1.0&quot;<br /> xmlns:xsl=&quot;http://www.w3.org/1999/XSL/Transform&quot;<br /> xmlns:xip=&quot;http://ies.sitepark.com/xip&quot;<br /> extension-element-prefixes=&quot;xip&quot;&gt;<br /> <br /> &lt;xsl:output method=&quot;xml&quot; encoding=&quot;UTF-8&quot; indent=&quot;yes&quot;/&gt;<br /> <br /> &lt;xsl:function name=&quot;xip:getCategoryId&quot;&gt; &lt;xsl:param name=&quot;s&quot;/&gt;<br /> &lt;!-- Erstes Zeichen ermitteln --&gt;<br /> &lt;xsl:variable name=&quot;id&quot; select=&quot;substring-before($s,' ')&quot;/&gt;<br /> &lt;xsl:value-of select=&quot;substring-before($s,' ')&quot;/&gt;<br /> &lt;/xsl:function&gt;<br /> <br /> &lt;xsl:key name=&quot;categoryId&quot; match=&quot;item&quot; use=&quot;xip:getCategoryId(kat)&quot;/&gt;<br /> <br /> &lt;xsl:template match=&quot;/&quot;&gt;<br /> &lt;xip&gt;<br /> &lt;resource parent=&quot;formsolutions&quot; anchor=&quot;formsolutions.config&quot; name=&quot;Form Solutions Konfiguration&quot; template=&quot;formsolutions.template.config&quot;&gt;<br /> &lt;text name=&quot;wsurl&quot;&gt;${wsurl}&lt;/text&gt;<br /> &lt;text name=&quot;cms&quot;&gt;${cmskey}&lt;/text&gt;<br /> &lt;text name=&quot;user&quot;&gt;${user}&lt;/text&gt;<br /> &lt;/resource&gt;<br /> &lt;!-- Schleife über Kategorien --&gt;<br /> &lt;xsl:for-each select=&quot;//item[generate-id() = generate-id(key('categoryId', xip:getCategoryId(kat))[1])]&quot;&gt;<br /> <br /> &lt;xsl:variable name=&quot;category&quot; select=&quot;xip:getCategoryId(kat)&quot;/&gt;<br /> &lt;!-- gelöschte Formulare haben keine Kategorie --&gt;<br /> &lt;xsl:if test=&quot;$category != ''&quot;&gt;<br /> &lt;xsl:variable name=&quot;categoryName&quot; select=&quot;kat/text()&quot;/&gt;<br /> &lt;articlepool parent=&quot;formsolutions&quot; anchor=&quot;formsolutions.category.{$category}&quot; name=&quot;{$categoryName}&quot;&gt;<br /> &lt;resource&gt;<br /> &lt;text name=&quot;container&quot; anchor=&quot;is5:gui.container.infosite.standard&quot;/&gt;<br /> &lt;text name=&quot;registrationTemplate&quot; anchor=&quot;is5:gui.container.infosite.standard.all&quot;/&gt;<br /> &lt;text name=&quot;editorTemplatePool&quot; anchor=&quot;standard.container.editing&quot;&gt;&lt;/text&gt;<br /> &lt;/resource&gt;<br /> &lt;!-- Schleife über alle mit gleicher Kategorie --&gt;<br /> &lt;xsl:for-each select=&quot;key('categoryId',$category)&quot;&gt;<br /> &lt;resource anchor=&quot;formsolutions.form.{fnr}&quot; name=&quot;{title} ({fnr})&quot; template=&quot;formsolutions.template.form&quot;&gt;<br /> &lt;comment&gt;&lt;xsl:value-of select=&quot;bem&quot;/&gt;&lt;/comment&gt;<br /> &lt;text name=&quot;fs_fnr&quot;&gt;&lt;xsl:value-of select=&quot;fnr&quot;/&gt;&lt;/text&gt;<br /> &lt;text name=&quot;fs_pagecount&quot;&gt;&lt;xsl:value-of select=&quot;pagecount&quot;/&gt;&lt;/text&gt;<br /> &lt;text name=&quot;fs_created&quot;&gt;&lt;xsl:value-of select=&quot;created&quot;/&gt;&lt;/text&gt;<br /> &lt;text name=&quot;fs_changed&quot;&gt;&lt;xsl:value-of select=&quot;changed&quot;/&gt;&lt;/text&gt;<br /> &lt;text name=&quot;fs_beschr&quot;&gt;&lt;xsl:value-of select=&quot;beschr&quot;/&gt;&lt;/text&gt;<br /> &lt;text name=&quot;fs_type&quot;&gt;&lt;xsl:value-of select=&quot;type&quot;/&gt;&lt;/text&gt;<br /> &lt;/resource&gt;<br /> &lt;/xsl:for-each&gt;<br /> &lt;/articlepool&gt;<br /> &lt;/xsl:if&gt;<br /> &lt;/xsl:for-each&gt;<br /> &lt;/xip&gt;<br /> &lt;/xsl:template&gt;<br /> &lt;/xsl:stylesheet&gt;<br /> &lt;/source&gt;<br /> <br /> ===Aktivierung===<br /> <br /> Der Import kann manuell durch Aufruf des Skriptes &lt;code&gt;iespkg&lt;/code&gt; gestartet werden:<br /> &lt;source lang=&quot;bash&quot;&gt;<br /> server:# /srv/sitepark/bin/iespkg /etc/form-solutions.xml<br /> &lt;/source&gt;<br /> <br /> *Zur regelmäßigen Synchronisation ist ein Cronjob in folgender Form notwendig:<br /> &lt;source lang=&quot;bash&quot;&gt;<br /> # m h dom mon dow command<br /> # Formulare von form-solutions aktualisieren.<br /> 1 1 * * * /srv/sitepark/bin/iespkg /etc/form-solutions.xml<br /> &lt;/source&gt;<br /> <br /> *Auf Windows-Systemen müsste eine entsprechende 'Aufgabe' konfiguriert werden, die den beispielhaften Aufruf &lt;code&gt;c:/Programme/Sitepark/bin/iespkg /etc/form-solutions.xml&lt;/code&gt; einmal täglich ausführt. <br /> <br /> &lt;noinclude&gt;<br /> [[Kategorie:InfoSite5]]<br /> [[Kategorie:CityGov3]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=FormSolutions_Schnittstelle&diff=5842 2012-05-15T13:08:25Z

<p>Liebold: </p> <hr /> <div>Formulare der Firma [http://www.form-solutions.de Form-Solutions] können in den IES integriert werden. Hierzu ist eine Form-Solutions Lizenz erforderlich.<br /> <br /> ===Funktionsweise===<br /> Referenzen der Formulare werden in den IES (Sitepark Information Enterprise Server) importiert und durch regelmäßige Imports synchron gehalten. Mit Hilfe des [[spt:formsolutions]]-Tag kann ein Link-Dialog geöffnet werden, um ein Formulare zu verwendet. Für jede erzeugte Verlinkung wird eine neue URL erzeugt. Über dieser URL kann das Formular vom Form-Solutions-Server geladen werden (Z.B. PDF). Der [[spt:formsolutions]]-Tag erzeugt einen Button über den das Formular konfiguriert werden kann. Nach Klick auf diesen Button öffnet sich eine Seite des Form-Solutions-Servers mit der das Formular konfiguriert wird.<br /> <br /> ===Voraussetzungen===<br /> Um die Form-Solutions-Schnittstelle einrichten zu können müssen folgende Voraussetzungen gegeben sein:<br /> * Der Kunde muss eine Form-Solutions Lizenz besitzen, um den den Form-Solutions-Server ansprechen zu können<br /> * Der IES muss Zugang zum Internet haben, um den Formsolutions-Server erreichen zu können.<br /> * Die Redakteure, die die Formulare Verknüpfen sollen, müssen Zugang zum Internet haben, um den Formsolutions-Server erreichen zu können.<br /> * Es muß ein CMS-Key für die Form-Solutions-Schnittstelle bekannt sein der vom IES verwendet werden kann. Dieser Key wird den Kunden von Form-Solutions genannt. Der Key sollte keine Sonderzeichen enthalten!<br /> * Die zu verwendenden Formulare werden zur Personalisierung mit einem Form-Solutions-Nutzer verknüpft. Hier muss ein Default-Nutzer bekannt sein, der initial für neue Formular-Links verwendet wird. Diese Nutzer kann bei der weiteren Konfiguration des Formulars geändert werden. Für die Form-Solutions-Schnittelle ist eine Default-Nutzer-Nummer erforderlich. Sie muss das Format &lt;code&gt;00000000-0001-0001&lt;/code&gt; haben.<br /> * Es muss ein TemplatePool mit dem Anchor '&lt;code&gt;formsolutions.template.pool&lt;/code&gt;' existieren, der unterhalb des Pools 'Seitentemplates' hinterlegt ist oder das Flag 'Dieser Pool enthält Seitentemplates' gesetzt hat. <br /> * Es muss ein ArtikelPool mit dem Anchor '&lt;code&gt;formsolutions&lt;/code&gt;' existieren. Dieser Pool besitzt den 'Standard Infosite Container' sowie das Template für die Eigenschaften 'nur Resourcen anlegen'. Der 'Templatepool für die Bearbeitung' ist der zuvor angelegte TemplatePool 'formsolutions.template.pool'.<br /> * Es muss folgendes Template mit dem Anchor '&lt;code&gt;formsolutions.template.config&lt;/code&gt;' angelegt sein:<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;sp:io type=&quot;in&quot;&gt;<br /> &lt;em&gt;<br /> Diese Konfigurationswerte werden über den Form-Solutions import gesetzt und können an dieser Stellen nicht geändert werden.<br /> Ist eine Änderung der Werte nötig, muss diese Änderung am Importer vorgenommen werden.<br /> &lt;/em&gt;<br /> &lt;br/&gt;<br /> &lt;br/&gt;<br /> Webservice Url&lt;br&gt;<br /> &lt;spt:text name=&quot;wsurl&quot; readonly=&quot;false&quot; size=&quot;80&quot;/&gt;&lt;br/&gt;<br /> CMS-Key&lt;br&gt;<br /> &lt;spt:text name=&quot;cms&quot; readonly=&quot;true&quot; size=&quot;80&quot;/&gt;&lt;br/&gt;<br /> Nutzer-Nummer&lt;br&gt;<br /> &lt;spt:text name=&quot;user&quot; readonly=&quot;true&quot; size=&quot;80&quot;/&gt;&lt;br/&gt;<br /> &lt;/sp:io&gt;<br /> &lt;/source&gt;<br /> * Es muss folgendes Template mit dem Anchor '&lt;code&gt;formsolutions.template.form&lt;/code&gt;' angelegt sein:<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;sp:io type=&quot;in&quot;&gt;<br /> Formular-Nummer&lt;br/&gt;<br /> &lt;spt:text name=&quot;fs_fnr&quot;/&gt;&lt;br/&gt;<br /> Anzahl der Seiten&lt;br/&gt;<br /> &lt;spt:text name=&quot;fs_pagecount&quot;/&gt;&lt;br/&gt;<br /> Erzeugt am&lt;br/&gt;<br /> &lt;spt:text name=&quot;fs_created&quot;/&gt;&lt;br/&gt;<br /> Letzte Änderung am&lt;br/&gt;<br /> &lt;spt:text name=&quot;fs_changed&quot;/&gt;&lt;br/&gt;<br /> Bemerkung&lt;br/&gt;<br /> &lt;spt:text name=&quot;fs_bem&quot;/&gt;&lt;br/&gt;<br /> Beschreibung&lt;br/&gt;<br /> &lt;spt:text name=&quot;fs_beschr&quot;/&gt;&lt;br/&gt;<br /> Typ&lt;br/&gt;<br /> &lt;spt:text name=&quot;fs_type&quot;/&gt;&lt;br/&gt;<br /> &lt;/sp:io&gt;&lt;/source&gt;<br /> <br /> ===Konfiguration===<br /> Um den Import einrichten zu können müssen von dem Kunden folgende Informationen bereit gestellt werden:<br /> * CMS-Key des Kunden-Accounts<br /> * Kunden-Account: Login und Passwort<br /> <br /> Dann sind folgende Dateien in &lt;code&gt;/etc/sitepark&lt;/code&gt; anzulegen:<br /> <br /> '''&lt;code&gt;form-solutions.xml&lt;/code&gt;'''&lt;br&gt;<br /> Hier &lt;strong&gt;müssen&lt;/strong&gt; die Variablen ''cmskey'' und ''user'' entsprechend den Daten des Kunden ersetzt werden.&lt;br&gt;<br /> &lt;strong style=&quot;color:red&quot;&gt;Vorsicht:&lt;/strong&gt; Sollte der Key Zeichen wie '&amp;' enthalten, muss der unten verwendete Platzhalter '${cmskey}' gegen den XML encodeten Key getauscht werden!<br /> <br /> &lt;syntaxhighlight lang=&quot;xml&quot;&gt;<br /> &lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;<br /> &lt;ies-client&gt;<br /> &lt;logging&gt;<br /> &lt;appender name=&quot;FILE&quot; class=&quot;org.apache.log4j.RollingFileAppender&quot;&gt;<br /> &lt;layout class=&quot;org.apache.log4j.PatternLayout&quot;&gt;<br /> &lt;param name=&quot;ConversionPattern&quot; value=&quot;%d %-5p %m%n&quot;/&gt;<br /> &lt;/layout&gt;<br /> &lt;param name=&quot;File&quot; value=&quot;${sitepark.home}/form-solutions.log&quot;/&gt;<br /> &lt;param name=&quot;MaxFileSize&quot; value=&quot;10MB&quot;/&gt;<br /> &lt;param name=&quot;MaxBackupIndex&quot; value=&quot;10&quot;/&gt;<br /> &lt;/appender&gt;<br /> &lt;logger name=&quot;com.sitepark.ies&quot; additivity=&quot;false&quot;&gt;<br /> &lt;appender-ref ref=&quot;FILE&quot;/&gt;<br /> &lt;priority value=&quot;INFO&quot;/&gt;<br /> &lt;/logger&gt;<br /> &lt;/logging&gt; <br /> &lt;ies-connection login=&quot;login&quot; password=&quot;password&quot; client=&quot;anchor_of_the_client&quot; module=&quot;Form Solutions Importer&quot;/&gt;<br /> &lt;properties&gt;<br /> &lt;property name=&quot;ies.xip.import.deleteWorkDir&quot;&gt;true&lt;/property&gt;<br /> &lt;property name=&quot;ies.xip.import.syncfile&quot;&gt;${sitepark.home}/conf/form-solutions.sync&lt;/property&gt;<br /> &lt;property name=&quot;ies.xip.import.publishMode&quot;&gt;all-file&lt;/property&gt;<br /> &lt;property name=&quot;ies.xip.import.ignoreParents&quot;&gt;false&lt;/property&gt;<br /> &lt;property name=&quot;ies.xip.import.deleteElements&quot;&gt;true&lt;/property&gt;<br /> &lt;property name=&quot;ies.xip.import.deletePools&quot;&gt;true&lt;/property&gt;<br /> &lt;property name=&quot;ies.xip.import.deleteOnlyEmptyPools&quot;&gt;true&lt;/property&gt;<br /> &lt;property name=&quot;ies.xip.import.variables&quot;&gt;wsurl=https://pdf.form-solutions.net/ws2&lt;/property&gt;<br /> &lt;property name=&quot;ies.xip.import.variables&quot;&gt;cmskey=293478912hskdfh238&lt;/property&gt;<br /> &lt;property name=&quot;ies.xip.import.variables&quot;&gt;user=12345678-1234-1234&lt;/property&gt;<br /> &lt;/properties&gt;<br /> &lt;xip command=&quot;import&quot;&gt; <br /> &lt;source type=&quot;http&quot; url=&quot;${wsurl}/getformlist.php&quot; method=&quot;post&quot;&gt;<br /> &lt;header name=&quot;SOAPAction&quot;&gt;&quot;urn:FS#getformlist&quot;&lt;/header&gt;<br /> &lt;body content-type=&quot;text/xml; charset=UTF-8&quot;&gt;&lt;![CDATA[&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;<br /> &lt;SOAP-ENV:Envelope xmlns:SOAP-ENV=&quot;http://schemas.xmlsoap.org/soap/envelope/&quot; xmlns:xsd=&quot;http://www.w3.org/2001/XMLSchema&quot; xmlns:xsi=&quot;http://www.w3.org/2001/XMLSchema-instance&quot; xmlns:SOAP-ENC=&quot;http://schemas.xmlsoap.org/soap/encoding/&quot; xmlns:tns=&quot;urn:FS&quot; SOAP-ENV:encodingStyle=&quot;http://schemas.xmlsoap.org/soap/encoding/&quot;&gt;<br /> &lt;SOAP-ENV:Body&gt;<br /> &lt;tns:getformlist xmlns:tns=&quot;urn:FS&quot;&gt;<br /> &lt;cms xsi:type=&quot;xsd:string&quot;&gt;${cmskey}&lt;/cms&gt;<br /> &lt;/tns:getformlist&gt;<br /> &lt;/SOAP-ENV:Body&gt;<br /> &lt;/SOAP-ENV:Envelope&gt;]]&gt;&lt;/body&gt;<br /> &lt;/source&gt;<br /> &lt;transform xslt=&quot;${sitepark.home}/conf/form-solutions.xslt&quot;/&gt;<br /> &lt;/xip&gt;<br /> &lt;/ies-client&gt;<br /> &lt;/syntaxhighlight&gt;<br /> <br /> '''&lt;code&gt;form-solutions.xslt&lt;/code&gt;'''<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;?xml version=&quot;1.0&quot; encoding=&quot;ISO-8859-1&quot;?&gt;<br /> &lt;xsl:stylesheet version=&quot;1.0&quot;<br /> xmlns:xsl=&quot;http://www.w3.org/1999/XSL/Transform&quot;<br /> xmlns:xip=&quot;http://ies.sitepark.com/xip&quot;<br /> extension-element-prefixes=&quot;xip&quot;&gt;<br /> <br /> &lt;xsl:output method=&quot;xml&quot; encoding=&quot;UTF-8&quot; indent=&quot;yes&quot;/&gt;<br /> <br /> &lt;xsl:function name=&quot;xip:getCategoryId&quot;&gt; &lt;xsl:param name=&quot;s&quot;/&gt;<br /> &lt;!-- Erstes Zeichen ermitteln --&gt;<br /> &lt;xsl:variable name=&quot;id&quot; select=&quot;substring-before($s,' ')&quot;/&gt;<br /> &lt;xsl:value-of select=&quot;substring-before($s,' ')&quot;/&gt;<br /> &lt;/xsl:function&gt;<br /> <br /> &lt;xsl:key name=&quot;categoryId&quot; match=&quot;item&quot; use=&quot;xip:getCategoryId(kat)&quot;/&gt;<br /> <br /> &lt;xsl:template match=&quot;/&quot;&gt;<br /> &lt;xip&gt;<br /> &lt;resource parent=&quot;formsolutions&quot; anchor=&quot;formsolutions.config&quot; name=&quot;Form Solutions Konfiguration&quot; template=&quot;formsolutions.template.config&quot;&gt;<br /> &lt;text name=&quot;wsurl&quot;&gt;${wsurl}&lt;/text&gt;<br /> &lt;text name=&quot;cms&quot;&gt;${cmskey}&lt;/text&gt;<br /> &lt;text name=&quot;user&quot;&gt;${user}&lt;/text&gt;<br /> &lt;/resource&gt;<br /> &lt;!-- Schleife über Kategorien --&gt;<br /> &lt;xsl:for-each select=&quot;//item[generate-id() = generate-id(key('categoryId', xip:getCategoryId(kat))[1])]&quot;&gt;<br /> <br /> &lt;xsl:variable name=&quot;category&quot; select=&quot;xip:getCategoryId(kat)&quot;/&gt;<br /> &lt;!-- gelöschte Formulare haben keine Kategorie --&gt;<br /> &lt;xsl:if test=&quot;$category != ''&quot;&gt;<br /> &lt;xsl:variable name=&quot;categoryName&quot; select=&quot;kat/text()&quot;/&gt;<br /> &lt;articlepool parent=&quot;formsolutions&quot; anchor=&quot;formsolutions.category.{$category}&quot; name=&quot;{$categoryName}&quot;&gt;<br /> &lt;resource&gt;<br /> &lt;text name=&quot;container&quot; anchor=&quot;is5:gui.container.infosite.standard&quot;/&gt;<br /> &lt;text name=&quot;registrationTemplate&quot; anchor=&quot;is5:gui.container.infosite.standard.all&quot;/&gt;<br /> &lt;text name=&quot;editorTemplatePool&quot; anchor=&quot;standard.container.editing&quot;&gt;&lt;/text&gt;<br /> &lt;/resource&gt;<br /> &lt;!-- Schleife über alle mit gleicher Kategorie --&gt;<br /> &lt;xsl:for-each select=&quot;key('categoryId',$category)&quot;&gt;<br /> &lt;resource anchor=&quot;formsolutions.form.{fnr}&quot; name=&quot;{title} ({fnr})&quot; template=&quot;formsolutions.template.form&quot;&gt;<br /> &lt;comment&gt;&lt;xsl:value-of select=&quot;bem&quot;/&gt;&lt;/comment&gt;<br /> &lt;text name=&quot;fs_fnr&quot;&gt;&lt;xsl:value-of select=&quot;fnr&quot;/&gt;&lt;/text&gt;<br /> &lt;text name=&quot;fs_pagecount&quot;&gt;&lt;xsl:value-of select=&quot;pagecount&quot;/&gt;&lt;/text&gt;<br /> &lt;text name=&quot;fs_created&quot;&gt;&lt;xsl:value-of select=&quot;created&quot;/&gt;&lt;/text&gt;<br /> &lt;text name=&quot;fs_changed&quot;&gt;&lt;xsl:value-of select=&quot;changed&quot;/&gt;&lt;/text&gt;<br /> &lt;text name=&quot;fs_beschr&quot;&gt;&lt;xsl:value-of select=&quot;beschr&quot;/&gt;&lt;/text&gt;<br /> &lt;text name=&quot;fs_type&quot;&gt;&lt;xsl:value-of select=&quot;type&quot;/&gt;&lt;/text&gt;<br /> &lt;/resource&gt;<br /> &lt;/xsl:for-each&gt;<br /> &lt;/articlepool&gt;<br /> &lt;/xsl:if&gt;<br /> &lt;/xsl:for-each&gt;<br /> &lt;/xip&gt;<br /> &lt;/xsl:template&gt;<br /> &lt;/xsl:stylesheet&gt;<br /> &lt;/source&gt;<br /> <br /> ===Aktivierung===<br /> <br /> Der Import kann manuell durch Aufruf des Skriptes &lt;code&gt;iespkg&lt;/code&gt; gestartet werden:<br /> &lt;source lang=&quot;bash&quot;&gt;<br /> server:# /srv/sitepark/bin/iespkg /etc/form-solutions.xml<br /> &lt;/source&gt;<br /> <br /> *Zur regelmäßigen Synchronisation ist ein Cronjob in folgender Form notwendig:<br /> &lt;source lang=&quot;bash&quot;&gt;<br /> # m h dom mon dow command<br /> # Formulare von form-solutions aktualisieren.<br /> 1 1 * * * /srv/sitepark/bin/iespkg /etc/form-solutions.xml<br /> &lt;/source&gt;<br /> <br /> *Auf Windows-Systemen müsste eine entsprechende 'Aufgabe' konfiguriert werden, die den beispielhaften Aufruf &lt;code&gt;c:/Programme/Sitepark/bin/iespkg /etc/form-solutions.xml&lt;/code&gt; einmal täglich ausführt. <br /> <br /> &lt;noinclude&gt;<br /> [[Kategorie:InfoSite5]]<br /> [[Kategorie:CityGov3]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=FormSolutions_Schnittstelle&diff=5830 2012-05-14T07:21:06Z

<p>Liebold: /* Voraussetzungen */</p> <hr /> <div>Formulare der Firma [http://www.form-solutions.de Form-Solutions] können in den IES integriert werden. Hierzu ist eine Form-Solutions Lizenz erforderlich.<br /> <br /> ===Funktionsweise===<br /> Referenzen der Formulare werden in den IES importiert und durch regelmäßige Imports synchron gehalten. Mit Hilfe des [[spt:formsolutions]]-Tag kann ein Link-Dialog geöffnet werden, um ein Formulare zu verwendet. Für jede erzeugte Verlinkung wird eine neue URL erzeugt. Über dieser URL kann das Formular vom Form-Solutions-Server geladen werden (Z.B. PDF). Der [[spt:formsolutions]]-Tag erzeugt einen Button über den das Formular konfiguriert werden kann. Nach Klick auf diesen Button öffnet sich eine Seite des Form-Solutions-Servers mit der das Formular konfiguriert wird.<br /> <br /> ===Voraussetzungen===<br /> Um die Form-Solutions-Schnittstelle einrichten zu können müssen folgende Voraussetzungen gegeben sein:<br /> * Der Kunde muss eine Form-Solutions Lizenz besitzen, um den den Form-Solutions-Server ansprechen zu können<br /> * Der IES muss Zugang zum Internet haben, um den Formsolutions-Server erreichen zu können.<br /> * Die Redakteure, die die Formulare Verknüpfen sollen, müssen Zugang zum Internet haben, um den Formsolutions-Server erreichen zu können.<br /> * Es muß ein CMS-Key für die Form-Solutions-Schnittstelle bekannt sein der vom IES verwendet werden kann. Dieser Key wird den Kunden von Form-Solutions genannt. Der Key sollte keine Sonderzeichen enthalten!<br /> * Die zu verwendenden Formulare werden zur Personalisierung mit einem Form-Solutions-Nutzer verknüpft. Hier muss ein Default-Nutzer bekannt sein, der initial für neue Formular-Links verwendet wird. Diese Nutzer kann bei der weiteren Konfiguration des Formulars geändert werden. Für die Form-Solutions-Schnittelle ist eine Default-Nutzer-Nummer erforderlich. Sie muss das Format &lt;code&gt;00000000-0001-0001&lt;/code&gt; haben.<br /> * Es muss ein ArtikelPool mit dem Anchor '&lt;code&gt;formsolutions&lt;/code&gt;' existieren.<br /> * Es muss folgendes Template mit dem Anchor '&lt;code&gt;formsolutions.template.config&lt;/code&gt;' angelegt sein:<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;sp:io type=&quot;in&quot;&gt;<br /> &lt;em&gt;<br /> Diese Konfigurationswerte werden über den Form-Solutions import gesetzt und können an dieser Stellen nicht geändert werden.<br /> Ist eine Änderung der Werte nötig, muss diese Änderung am Importer vorgenommen werden.<br /> &lt;/em&gt;<br /> &lt;br/&gt;<br /> &lt;br/&gt;<br /> Webservice Url&lt;br&gt;<br /> &lt;spt:text name=&quot;wsurl&quot; readonly=&quot;false&quot; size=&quot;80&quot;/&gt;&lt;br/&gt;<br /> CMS-Key&lt;br&gt;<br /> &lt;spt:text name=&quot;cms&quot; readonly=&quot;true&quot; size=&quot;80&quot;/&gt;&lt;br/&gt;<br /> Nutzer-Nummer&lt;br&gt;<br /> &lt;spt:text name=&quot;user&quot; readonly=&quot;true&quot; size=&quot;80&quot;/&gt;&lt;br/&gt;<br /> &lt;/sp:io&gt;<br /> &lt;/source&gt;<br /> * Es muss folgendes Template mit dem Anchor '&lt;code&gt;formsolutions.template.form&lt;/code&gt;' angelegt sein:<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;sp:io type=&quot;in&quot;&gt;<br /> Formular-Nummer&lt;br/&gt;<br /> &lt;spt:text name=&quot;fs_fnr&quot;/&gt;&lt;br/&gt;<br /> Anzahl der Seiten&lt;br/&gt;<br /> &lt;spt:text name=&quot;fs_pagecount&quot;/&gt;&lt;br/&gt;<br /> Erzeugt am&lt;br/&gt;<br /> &lt;spt:text name=&quot;fs_created&quot;/&gt;&lt;br/&gt;<br /> Letzte Änderung am&lt;br/&gt;<br /> &lt;spt:text name=&quot;fs_changed&quot;/&gt;&lt;br/&gt;<br /> Bemerkung&lt;br/&gt;<br /> &lt;spt:text name=&quot;fs_bem&quot;/&gt;&lt;br/&gt;<br /> Beschreibung&lt;br/&gt;<br /> &lt;spt:text name=&quot;fs_beschr&quot;/&gt;&lt;br/&gt;<br /> Typ&lt;br/&gt;<br /> &lt;spt:text name=&quot;fs_type&quot;/&gt;&lt;br/&gt;<br /> &lt;/sp:io&gt;&lt;/source&gt;<br /> <br /> ===Konfiguration===<br /> Um den Import einrichten zu können müssen von dem Kunden folgende Informationen bereit gestellt werden:<br /> * CMS-Key des Kunden-Accounts<br /> * Kunden-Account: Login und Passwort<br /> <br /> Dann sind folgende Dateien in &lt;code&gt;/etc/sitepark&lt;/code&gt; anzulegen:<br /> <br /> '''&lt;code&gt;form-solutions.xml&lt;/code&gt;'''&lt;br&gt;<br /> Hier &lt;strong&gt;müssen&lt;/strong&gt; die Variablen ''cmskey'' und ''user'' entsprechend den Daten des Kunden ersetzt werden.&lt;br&gt;<br /> &lt;strong style=&quot;color:red&quot;&gt;Vorsicht:&lt;/strong&gt; Sollte der Key Zeichen wie '&amp;' enthalten, muss der unten verwendete Platzhalter '${cmskey}' gegen den XML encodeten Key getauscht werden!<br /> <br /> &lt;syntaxhighlight lang=&quot;xml&quot;&gt;<br /> &lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;<br /> &lt;ies-client&gt;<br /> &lt;logging&gt;<br /> &lt;appender name=&quot;FILE&quot; class=&quot;org.apache.log4j.RollingFileAppender&quot;&gt;<br /> &lt;layout class=&quot;org.apache.log4j.PatternLayout&quot;&gt;<br /> &lt;param name=&quot;ConversionPattern&quot; value=&quot;%d %-5p %m%n&quot;/&gt;<br /> &lt;/layout&gt;<br /> &lt;param name=&quot;File&quot; value=&quot;${sitepark.home}/form-solutions.log&quot;/&gt;<br /> &lt;param name=&quot;MaxFileSize&quot; value=&quot;10MB&quot;/&gt;<br /> &lt;param name=&quot;MaxBackupIndex&quot; value=&quot;10&quot;/&gt;<br /> &lt;/appender&gt;<br /> &lt;logger name=&quot;com.sitepark.ies&quot; additivity=&quot;false&quot;&gt;<br /> &lt;appender-ref ref=&quot;FILE&quot;/&gt;<br /> &lt;priority value=&quot;INFO&quot;/&gt;<br /> &lt;/logger&gt;<br /> &lt;/logging&gt; <br /> &lt;ies-connection login=&quot;login&quot; password=&quot;password&quot; client=&quot;anchor_of_the_client&quot; module=&quot;Form Solutions Importer&quot;/&gt;<br /> &lt;properties&gt;<br /> &lt;property name=&quot;ies.xip.import.deleteWorkDir&quot;&gt;true&lt;/property&gt;<br /> &lt;property name=&quot;ies.xip.import.syncfile&quot;&gt;${sitepark.home}/conf/form-solutions.sync&lt;/property&gt;<br /> &lt;property name=&quot;ies.xip.import.publishMode&quot;&gt;all-file&lt;/property&gt;<br /> &lt;property name=&quot;ies.xip.import.ignoreParents&quot;&gt;false&lt;/property&gt;<br /> &lt;property name=&quot;ies.xip.import.deleteElements&quot;&gt;true&lt;/property&gt;<br /> &lt;property name=&quot;ies.xip.import.deletePools&quot;&gt;true&lt;/property&gt;<br /> &lt;property name=&quot;ies.xip.import.deleteOnlyEmptyPools&quot;&gt;true&lt;/property&gt;<br /> &lt;property name=&quot;ies.xip.import.variables&quot;&gt;wsurl=https://pdf.form-solutions.net/ws2&lt;/property&gt;<br /> &lt;property name=&quot;ies.xip.import.variables&quot;&gt;cmskey=293478912hskdfh238&lt;/property&gt;<br /> &lt;property name=&quot;ies.xip.import.variables&quot;&gt;user=12345678-1234-1234&lt;/property&gt;<br /> &lt;/properties&gt;<br /> &lt;xip command=&quot;import&quot;&gt; <br /> &lt;source type=&quot;http&quot; url=&quot;${wsurl}/getformlist.php&quot; method=&quot;post&quot;&gt;<br /> &lt;header name=&quot;SOAPAction&quot;&gt;&quot;urn:FS#getformlist&quot;&lt;/header&gt;<br /> &lt;body content-type=&quot;text/xml; charset=UTF-8&quot;&gt;&lt;![CDATA[&lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&gt;<br /> &lt;SOAP-ENV:Envelope xmlns:SOAP-ENV=&quot;http://schemas.xmlsoap.org/soap/envelope/&quot; xmlns:xsd=&quot;http://www.w3.org/2001/XMLSchema&quot; xmlns:xsi=&quot;http://www.w3.org/2001/XMLSchema-instance&quot; xmlns:SOAP-ENC=&quot;http://schemas.xmlsoap.org/soap/encoding/&quot; xmlns:tns=&quot;urn:FS&quot; SOAP-ENV:encodingStyle=&quot;http://schemas.xmlsoap.org/soap/encoding/&quot;&gt;<br /> &lt;SOAP-ENV:Body&gt;<br /> &lt;tns:getformlist xmlns:tns=&quot;urn:FS&quot;&gt;<br /> &lt;cms xsi:type=&quot;xsd:string&quot;&gt;${cmskey}&lt;/cms&gt;<br /> &lt;/tns:getformlist&gt;<br /> &lt;/SOAP-ENV:Body&gt;<br /> &lt;/SOAP-ENV:Envelope&gt;]]&gt;&lt;/body&gt;<br /> &lt;/source&gt;<br /> &lt;transform xslt=&quot;${sitepark.home}/conf/form-solutions.xslt&quot;/&gt;<br /> &lt;/xip&gt;<br /> &lt;/ies-client&gt;<br /> &lt;/syntaxhighlight&gt;<br /> <br /> '''&lt;code&gt;form-solutions.xslt&lt;/code&gt;'''<br /> &lt;source lang=&quot;xml&quot;&gt;<br /> &lt;?xml version=&quot;1.0&quot; encoding=&quot;ISO-8859-1&quot;?&gt;<br /> &lt;xsl:stylesheet version=&quot;1.0&quot;<br /> xmlns:xsl=&quot;http://www.w3.org/1999/XSL/Transform&quot;<br /> xmlns:xip=&quot;http://ies.sitepark.com/xip&quot;<br /> extension-element-prefixes=&quot;xip&quot;&gt;<br /> <br /> &lt;xsl:output method=&quot;xml&quot; encoding=&quot;UTF-8&quot; indent=&quot;yes&quot;/&gt;<br /> <br /> &lt;xsl:function name=&quot;xip:getCategoryId&quot;&gt; &lt;xsl:param name=&quot;s&quot;/&gt;<br /> &lt;!-- Erstes Zeichen ermitteln --&gt;<br /> &lt;xsl:variable name=&quot;id&quot; select=&quot;substring-before($s,' ')&quot;/&gt;<br /> &lt;xsl:value-of select=&quot;substring-before($s,' ')&quot;/&gt;<br /> &lt;/xsl:function&gt;<br /> <br /> &lt;xsl:key name=&quot;categoryId&quot; match=&quot;item&quot; use=&quot;xip:getCategoryId(kat)&quot;/&gt;<br /> <br /> &lt;xsl:template match=&quot;/&quot;&gt;<br /> &lt;xip&gt;<br /> &lt;resource parent=&quot;formsolutions&quot; anchor=&quot;formsolutions.config&quot; name=&quot;Form Solutions Konfiguration&quot; template=&quot;formsolutions.template.config&quot;&gt;<br /> &lt;text name=&quot;wsurl&quot;&gt;${wsurl}&lt;/text&gt;<br /> &lt;text name=&quot;cms&quot;&gt;${cmskey}&lt;/text&gt;<br /> &lt;text name=&quot;user&quot;&gt;${user}&lt;/text&gt;<br /> &lt;/resource&gt;<br /> &lt;!-- Schleife über Kategorien --&gt;<br /> &lt;xsl:for-each select=&quot;//item[generate-id() = generate-id(key('categoryId', xip:getCategoryId(kat))[1])]&quot;&gt;<br /> <br /> &lt;xsl:variable name=&quot;category&quot; select=&quot;xip:getCategoryId(kat)&quot;/&gt;<br /> &lt;!-- gelöschte Formulare haben keine Kategorie --&gt;<br /> &lt;xsl:if test=&quot;$category != ''&quot;&gt;<br /> &lt;xsl:variable name=&quot;categoryName&quot; select=&quot;kat/text()&quot;/&gt;<br /> &lt;articlepool parent=&quot;formsolutions&quot; anchor=&quot;formsolutions.category.{$category}&quot; name=&quot;{$categoryName}&quot;&gt;<br /> &lt;resource&gt;<br /> &lt;text name=&quot;container&quot; anchor=&quot;is5:gui.container.infosite.standard&quot;/&gt;<br /> &lt;text name=&quot;registrationTemplate&quot; anchor=&quot;is5:gui.container.infosite.standard.all&quot;/&gt;<br /> &lt;text name=&quot;editorTemplatePool&quot; anchor=&quot;standard.container.editing&quot;&gt;&lt;/text&gt;<br /> &lt;/resource&gt;<br /> &lt;!-- Schleife über alle mit gleicher Kategorie --&gt;<br /> &lt;xsl:for-each select=&quot;key('categoryId',$category)&quot;&gt;<br /> &lt;resource anchor=&quot;formsolutions.form.{fnr}&quot; name=&quot;{title} ({fnr})&quot; template=&quot;formsolutions.template.form&quot;&gt;<br /> &lt;comment&gt;&lt;xsl:value-of select=&quot;bem&quot;/&gt;&lt;/comment&gt;<br /> &lt;text name=&quot;fs_fnr&quot;&gt;&lt;xsl:value-of select=&quot;fnr&quot;/&gt;&lt;/text&gt;<br /> &lt;text name=&quot;fs_pagecount&quot;&gt;&lt;xsl:value-of select=&quot;pagecount&quot;/&gt;&lt;/text&gt;<br /> &lt;text name=&quot;fs_created&quot;&gt;&lt;xsl:value-of select=&quot;created&quot;/&gt;&lt;/text&gt;<br /> &lt;text name=&quot;fs_changed&quot;&gt;&lt;xsl:value-of select=&quot;changed&quot;/&gt;&lt;/text&gt;<br /> &lt;text name=&quot;fs_beschr&quot;&gt;&lt;xsl:value-of select=&quot;beschr&quot;/&gt;&lt;/text&gt;<br /> &lt;text name=&quot;fs_type&quot;&gt;&lt;xsl:value-of select=&quot;type&quot;/&gt;&lt;/text&gt;<br /> &lt;/resource&gt;<br /> &lt;/xsl:for-each&gt;<br /> &lt;/articlepool&gt;<br /> &lt;/xsl:if&gt;<br /> &lt;/xsl:for-each&gt;<br /> &lt;/xip&gt;<br /> &lt;/xsl:template&gt;<br /> &lt;/xsl:stylesheet&gt;<br /> &lt;/source&gt;<br /> <br /> Zur regelmäßigen Synchronisation ist weiterhin ein Cronjob folgender Form notwendig:<br /> &lt;source lang=&quot;bash&quot;&gt;<br /> # m h dom mon dow command<br /> # Formulare von form-solutions aktualisieren.<br /> 1 1 * * * /srv/sitepark/bin/iespkg /etc/form-solutions.xml<br /> &lt;/source&gt;<br /> &lt;noinclude&gt;<br /> [[Kategorie:InfoSite5]]<br /> [[Kategorie:CityGov3]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=Changelog_Infosite_5&diff=5800 2012-03-14T09:57:49Z

<p>Liebold: /* Anmerkungen */</p> <hr /> <div>__NOTOC__<br /> ==Weitere Changelogs==<br /> *[[Changelog|IES]]<br /> *[[Changelog_CityGov_3|CityGov 3]]<br /> *[[Changelog_CityCall115|CityCall115]]<br /> <br /> ====Anmerkungen====<br /> &lt;div class=&quot;note&quot;&gt;<br /> Seit InfoSite 5.2 führen wir für InfoSite und IES getrennte Changelogs. Ältere Changelog-Einträge für InfoSite befinden sich daher im [[Changelog|IES Changelog]].<br /> &lt;/div&gt;<br /> <br /> ==Changelog==<br /> ===5.2 (13.03.2012)===<br /> ''Sourcen in GIT verwaltet.''<br /> {|<br /> | style=&quot;vertical-align:top;&quot; | {{add}} || Personen-Bilder aus der VV können nun auch angezeigt werden<br /> |-<br /> | style=&quot;vertical-align:top;&quot; | {{update}} || Div-Container für Hinweistext optisch überarbeitet<br /> |-<br /> | style=&quot;vertical-align:top;&quot; | {{add}} || CodeMirror auf Version 2.18 aktuallisiert<br /> |-<br /> | style=&quot;vertical-align:top;&quot; | {{fix}} || Zeitgesteuerte Publikation wird beim Speichern von &amp;#039;Eigenschafen&amp;#039; wieder entfernt<br /> |-<br /> | style=&quot;vertical-align:top;&quot; | {{fix}} || Unterstützung des Attributs cmsURL für den SmartEditor<br /> |-<br /> | style=&quot;vertical-align:top;&quot; | {{add}} || Neue Hintergrundgrafik für Testsysteme<br /> |}</div>

Liebold https://wiki.sitepark.com/index.php?title=Changelog_Infosite_5&diff=5799 2012-03-14T09:56:31Z

<p>Liebold: </p> <hr /> <div>__NOTOC__<br /> ==Weitere Changelogs==<br /> *[[Changelog|IES]]<br /> *[[Changelog_CityGov_3|CityGov 3]]<br /> *[[Changelog_CityCall115|CityCall115]]<br /> <br /> ====Anmerkungen====<br /> &lt;div class=&quot;note&quot;&gt;<br /> Seit InfoSite 5.2 führen wir für InfoSite und IES getrennte Changelogs. Ältere Changelog-Einträge für InfoSite befinden sich daher im [[IES-Changelog]].<br /> &lt;/div&gt;<br /> <br /> ==Changelog==<br /> ===5.2 (13.03.2012)===<br /> ''Sourcen in GIT verwaltet.''<br /> {|<br /> | style=&quot;vertical-align:top;&quot; | {{add}} || Personen-Bilder aus der VV können nun auch angezeigt werden<br /> |-<br /> | style=&quot;vertical-align:top;&quot; | {{update}} || Div-Container für Hinweistext optisch überarbeitet<br /> |-<br /> | style=&quot;vertical-align:top;&quot; | {{add}} || CodeMirror auf Version 2.18 aktuallisiert<br /> |-<br /> | style=&quot;vertical-align:top;&quot; | {{fix}} || Zeitgesteuerte Publikation wird beim Speichern von &amp;#039;Eigenschafen&amp;#039; wieder entfernt<br /> |-<br /> | style=&quot;vertical-align:top;&quot; | {{fix}} || Unterstützung des Attributs cmsURL für den SmartEditor<br /> |-<br /> | style=&quot;vertical-align:top;&quot; | {{add}} || Neue Hintergrundgrafik für Testsysteme<br /> |}</div>

Liebold https://wiki.sitepark.com/index.php?title=Changelog_Infosite_5&diff=5798 2012-03-13T16:02:48Z

<p>Liebold: </p> <hr /> <div>__NOTOC__<br /> ==Weitere Changelogs==<br /> *[[Changelog|IES]]<br /> *[[Changelog_CityGov_3|CityGov 3]]<br /> *[[Changelog_CityCall115|CityCall115]]<br /> <br /> ==Changelog==<br /> ===5.2 (13.03.2012)===<br /> ''Sourcen in GIT verwaltet.''<br /> {|<br /> | style=&quot;vertical-align:top;&quot; | {{add}} || Personen-Bilder aus der VV können nun auch angezeigt werden<br /> |-<br /> | style=&quot;vertical-align:top;&quot; | {{update}} || Div-Container für Hinweistext optisch überarbeitet<br /> |-<br /> | style=&quot;vertical-align:top;&quot; | {{add}} || CodeMirror auf Version 2.18 aktuallisiert<br /> |-<br /> | style=&quot;vertical-align:top;&quot; | {{fix}} || Zeitgesteuerte Publikation wird beim Speichern von &amp;#039;Eigenschafen&amp;#039; wieder entfernt<br /> |-<br /> | style=&quot;vertical-align:top;&quot; | {{fix}} || Unterstützung des Attributs cmsURL für den SmartEditor<br /> |-<br /> | style=&quot;vertical-align:top;&quot; | {{add}} || Neue Hintergrundgrafik für Testsysteme<br /> |}</div>

Liebold https://wiki.sitepark.com/index.php?title=Changelog_Infosite_5&diff=5797 2012-03-13T16:01:52Z

<p>Liebold: </p> <hr /> <div>__NOTOC__<br /> ==Weitere Changelogs==<br /> *[[Changelog|IES]]<br /> *[[Changelog_CityGov_3|CityGov 3]]<br /> *[[Changelog_CityCall115|CityCall115]]<br /> <br /> <br /> ==Changelog==<br /> ===5.2 (13.03.2012)===<br /> ''Sourcen in GIT verwaltet.''<br /> {|<br /> | style=&quot;vertical-align:top;&quot; | {{add}} || Personen-Bilder aus der VV können nun auch angezeigt werden<br /> |-<br /> | style=&quot;vertical-align:top;&quot; | {{update}} || Div-Container für Hinweistext optisch überarbeitet<br /> |-<br /> | style=&quot;vertical-align:top;&quot; | {{add}} || CodeMirror auf Version 2.18 aktuallisiert<br /> |-<br /> | style=&quot;vertical-align:top;&quot; | {{fix}} || Zeitgesteuerte Publikation wird beim Speichern von &amp;#039;Eigenschafen&amp;#039; wieder entfernt<br /> |-<br /> | style=&quot;vertical-align:top;&quot; | {{fix}} || Unterstützung des Attributs cmsURL für den SmartEditor<br /> |-<br /> | style=&quot;vertical-align:top;&quot; | {{add}} || Neue Hintergrundgrafik für Testsysteme<br /> |}</div>

Liebold https://wiki.sitepark.com/index.php?title=Changelog_Infosite_5&diff=5796 2012-03-13T16:01:29Z

<p>Liebold: </p> <hr /> <div>__NOTOC__<br /> ==Weitere Changelogs==<br /> *[[Changelog Changelog|IES]]<br /> *[[Changelog_CityGov_3|CityGov 3]]<br /> *[[Changelog_CityCall115|CityCall115]]<br /> <br /> <br /> ==Changelog==<br /> ===5.2 (13.03.2012)===<br /> ''Sourcen in GIT verwaltet.''<br /> {|<br /> | style=&quot;vertical-align:top;&quot; | {{add}} || Personen-Bilder aus der VV können nun auch angezeigt werden<br /> |-<br /> | style=&quot;vertical-align:top;&quot; | {{update}} || Div-Container für Hinweistext optisch überarbeitet<br /> |-<br /> | style=&quot;vertical-align:top;&quot; | {{add}} || CodeMirror auf Version 2.18 aktuallisiert<br /> |-<br /> | style=&quot;vertical-align:top;&quot; | {{fix}} || Zeitgesteuerte Publikation wird beim Speichern von &amp;#039;Eigenschafen&amp;#039; wieder entfernt<br /> |-<br /> | style=&quot;vertical-align:top;&quot; | {{fix}} || Unterstützung des Attributs cmsURL für den SmartEditor<br /> |-<br /> | style=&quot;vertical-align:top;&quot; | {{add}} || Neue Hintergrundgrafik für Testsysteme<br /> |}</div>

Liebold https://wiki.sitepark.com/index.php?title=InfoTicket_-_Roadmap&diff=5675 2011-10-26T12:25:51Z

<p>Liebold: /* Milestone 13 - November 2011 */</p> <hr /> <div>==Milestone 1 - Erste präsentierbare Version auf pp.sitepark.com==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Kontaktdaten anlegen&lt;/span&gt;<br /> :- Verknüpfung auf einen KontaktDatensatz durch Angabe der ID des Kontaktes oder<br /> :- Verknüpfen durch Angabe der Kontaktdaten in dem 'contact' Feld. Die E-Mail dient als eindeutiger Identifier um den Datensatz im System zu finden. Wird kein Eintrag gefunden, wir der Kontaktdatensatz angelegt und verknüpft.<br /> :Bei Gleichheit von E-Mail-Adresse werden die übergebenen Daten überschrieben.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Folgende Eigenschaften müssen noch konfigurierbar werden&lt;/span&gt;<br /> :&lt;span style=&quot;color:green; font-weight:bold&quot;&gt;OK&lt;/span&gt; Verkünpfung zwischen CallCenter-Mandant und InfoTicket-Mandant. Mandant und Nutzer im 'TicketArtikel' des CallCenters konfigurierbar.<br /> :&lt;span style=&quot;color:green; font-weight:bold&quot;&gt;OK&lt;/span&gt; InfoTicket-Nutzer als Absender (Temporäre, nur für Milestone 1)<br /> :&lt;span style=&quot;color:green; font-weight:bold&quot;&gt;offen&lt;/span&gt; Workflowverhalten (Eskalationszeiten, ...). hart kodiert. Welche Werte? (1 Tag!)<br /> :&lt;span style=&quot;color:green; font-weight:bold&quot;&gt;OK&lt;/span&gt; Aussehen der E-Mail. <br /> <br /> ;&lt;span style=&quot;color:green; font-weight:bold&quot;&gt;Ticket aus dem CallCenter anlegen&lt;/span&gt;<br /> :&lt;span style=&quot;color:green; font-weight:bold&quot;&gt;OK&lt;/span&gt; Über Bürgeranfrage <br /> :&lt;span style=&quot;color:green; font-weight:bold&quot;&gt;OK&lt;/span&gt; Über Mitarbeiter-Visitenkarte - Standard Ticket öffnen<br /> :&lt;span style=&quot;color:green; font-weight:bold&quot;&gt;OK&lt;/span&gt; Über Dienstleistung - Standard Ticket öffnen<br /> <br /> ;&lt;span style=&quot;color:green; font-weight:bold&quot;&gt;Wie soll der Ticket-Mandant ermittelt werden, damit beim Login-Fenster keine Auswahl erscheint?&lt;/span&gt;<br /> : Antwort:<br /> :#Es werden alle Mandanten abgefragt, die aktiv sind und mit dem InfoTicket-Mandanten verknüpft sind. Entspricht nur ein Mandant diesen Kriterien wird keine Auswahl angezeigt und nur dieser verwendet.<br /> :#Es kann per URL-Parameter der gewünschte Mandant übergeben werden (ParameterName 'client', Wert ist der Anchor des Mandanten)<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Namensformat&lt;/span&gt;<br /> :Nutzernamen können (noch) nicht an allen Stellen über die ID ermittelt werden (Bei einer Suchabfrage müssen select user-&gt;name funktionieren), darum wird der Nutzername direkt gespeichert und nicht seine ID. Für diese Fälle muss das Namensformat (Nachname, Vorname, Title) überall gleich sein.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Fehlerbehandlung&lt;/span&gt;<br /> :Auf Serverseite müssen noch ein paar Fehlerzustände abgefangen werden.<br /> :;createTicket<br /> ::Wenn Email-Adresse in 'participant' nicht gefunden werden kann muss ein Fehler auftreten.<br /> ::Wenn ID in 'participant' nicht existiert<br /> ::Wenn ID in 'participant' existiert, Nutzer aber keine Email-Adresse hat.<br /> :;getTicket<br /> :: ID nicht gefunden<br /> :: Ticket ist bereist geschlossen<br /> :: Ticket ist weitergeleitet. Bearbeitet kann Ticket nicht mehr bearbeiten<br /> :;addTicketItem<br /> :: ID nicht gefunden<br /> :: Ticket ist bereist geschlossen<br /> :: Ticket ist weitergeleitet. Bearbeitet kann Ticket nicht mehr bearbeiten<br /> :: Übergebene Werte validieren (ticketType, priority, ...)<br /> :; closeTicket<br /> :: ID nicht gefunden<br /> :: Ticket ist bereist geschlossen<br /> :: Ticket ist weitergeleitet. Bearbeitet kann Ticket nicht mehr bearbeiten<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Ticket-Eigenschaften&lt;/span&gt;<br /> :nächste Wiedervorlagen, nächste Eskalation<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Agenten (Absender des Tickets)&lt;/span&gt;<br /> :Globaler IES-Nutzer aus dem Infoticket-Mandant wird als Absender gesetzt.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Installation auf pp.sitepark.com&lt;/span&gt;<br /> :Zwei Mandanten: Master und Work<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Auswahlliste der Empfänger im CallCenter&lt;/span&gt;<br /> :Wie kommen die Nutzer in das TicketSystem? Werden per Hand angelegt.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Sortierreihenfolge von Status, Typ und Aktion&lt;/span&gt;<br /> :''Status''<br /> :# Eskalation<br /> :# Erinnerung<br /> :# offen<br /> :# in Arbeit<br /> :# (geschlossen?)<br /> <br /> :''Typ''<br /> :# Aktennotiz<br /> :# Aufgabe<br /> :# Beschwerde<br /> :# D115-Weiterleitung<br /> :# Information<br /> :# Rückrufwunsch<br /> :# Störungsmeldung<br /> <br /> :''Aktion'' (für Ticket-Einträge)<br /> :# Neu<br /> :# Änderung<br /> :# Notiz<br /> :# Erinnerung<br /> :# Eskalation<br /> :# Weiterleitung<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Locking von Tickets&lt;/span&gt;<br /> :Kein Locking<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Konzeption: Eigenschaften ändern / Notiz anlegen&lt;/span&gt;<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Nachfrage-Dialog für Weiterleitungsbestätigung&lt;/span&gt;<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Speichern ohne Kommentar ist so in Ordung&lt;/span&gt;<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Subject muss man ändern können&lt;/span&gt;<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Wenn eine neue Notiz hinzugefügt wird, werden alle Einträge zugeklappt und nur der letzte geöffnet. Die Einträge, die geöffnet wurde sollen aber weiter offen bleiben. Es soll auch weiterhin zu dem letzten Eintrag gescrollt werden.&lt;/span&gt;<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Wenn Ticket-Tag geschlossen wird, muss nachgefragt werden, Wenn Ticket noch einen Message enthält (Wenn 'aktion ausführen' Button akive ist)&lt;/span&gt;<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Bei Kontakt ohne Telefon steht 'null', muss durch langen Strich ersetzt werden&lt;/span&gt;<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Bei öffnen des Tabs, Sanduhr an Maus bis Tab geöffnet&lt;/span&gt;<br /> :Fazit: So nicht zu realisieren.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Aufbau des Tab ruckelt (Firefox). Prüfen, ob das verhindert werden kann.&lt;/span&gt;<br /> :Geprüft. Der unruhige Aufbau läßt sich nicht so einfach nachstellen. Muss wohl an sehr langsamen Rechnern liegen. Habe auch keinen Weg gefunden da etwas zu verbessern.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Ticket-Einträge müssen nicht ausgewählt werden können. Auch ohne Mouse-over&lt;/span&gt;<br /> <br /> ==Milestone 2 - Mo, 27.09.2010==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;gestalteter Login-Dialog, Seitenhintergrund&lt;/span&gt;<br /> <br /> ==Milestone 3 - Ende Oktober 2010==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Kontaktdaten anlegen&lt;/span&gt;<br /> :Kontakte können beim Anlegen von Tickets erstellt werden, wenn keine bestehender Kontakt ausgewählt wurde.<br /> :Wenn Daten gefunden wurden, werden nach Auswahl des Kontakts alle Daten angezeigt.<br /> :Bei Gleichheit von E-Mail Adresse (oder Auswahl eines gefundenen Kontaktes) werden die Datenfelder aktualisiert.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Ticket aus CityCall115 anlegen (vorläufig)&lt;/span&gt;<br /> :An Personendatensatz Ticket öffnen, z.B. Rückrufwunsch<br /> :An Dienstleistung Ticket öffnen<br /> :*Personenticket (Kontakt)<br /> :*Alle Kontakte der Dienstleistung als Vorschlag<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Geschlossene Tickets anzeigen&lt;/span&gt;<br /> :Ist soweit implementiert. Folgendes fehlt noch<br /> :* Vorgabe für GUI zum aktivieren/deaktivieren des Filters (Nane)<br /> :* Bugfix, geschlossen Tickets haben nicht den Status 'geschlossen' (Ralf)<br /> <br /> ==Milestone 4 Fr, 03.12.2010==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Code-Optimierung (Java) (1 Tage)&lt;/span&gt;<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;GUI Sicht auf Tickets anderer Nutzer (Nutzerauswahl)&lt;/span&gt;<br /> :Dropdown mit allen Nutzern auf deren Tickets mindestens Leserechte bestehen<br /> :*Zusätzlicher Punkt: alle Nutzer <br /> :*Nur eigene Tickets im Zugriff -&gt; Dropdown entfällt<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Einfache Ticketsuche&lt;/span&gt;<br /> :Die Suche ist ein weiterer Filter, der einschränkend wirkt (UND-Verknüpfung)<br /> :*die Suche berücksichtigt die Nutzerauswahl, d.h. die Suche ist auf den/die gewählten Nutzer eingeschränkt<br /> :*die Suche verwendet die aktiven Filterkriterien<br /> :*die Suche wirkt solange als Filter, bis das Suchfeld gelöscht wird<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Kontaktdaten&lt;/span&gt;<br /> :Auch innerhalb von InfoTicket müssen die Kontaktdaten bearbeitet werden können.<br /> :E-Mail-Adressen bei der Darstellung von Kontaktdaten werden mit mailto:-Link versehen.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Geschlossene Tickets öffnen&lt;/span&gt;<br /> :Inhalte geschlossener Tickets müssen einsehbar sein<br /> :Geschlossene Tickets müssen wieder geöffnet werden können<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Notizen anfügen&lt;/span&gt;<br /> :Jeder kann jederzeit an jedes Ticket, auch an geschlossene Tickets, Notizen anfügen, sofern die Oberfläche von InfoTicket bzw. CityCall115 einen Zugriff auf das Ticket erlaubt. Hierfür muss sich das Ticket nicht im eigenen Besitz befinden und durch die Bearbeitung findet auch kein Besitzerwechsel statt.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Automatischer Besitzerwechsel bei mehreren Empfängern&lt;/span&gt;<br /> :Tickets, die in meiner ToDo-Liste liegen und mehreren Empfängern zugewiesen sind, wechseln beim Öffnen automatisch den Besitzer und werden mir zugewiesen. Der Besitzerwechsel wird als Weiterleitung protokolliert und erscheint sofort als letzter Eintrag im geöffneten Ticket. Tickets, die nicht in meiner ToDo-Liste liegen, wechseln beim Öffnen nicht den Besitzer.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Besitzerwechsel bei Bedarf&lt;/span&gt;<br /> :In InfoTicket kann jeder jedes Ticket bearbeiten, wenn im Rahmen eines übergreifenden Rechtemanagements Zugriffsrechte bestehen. Jedes Ändern von Headerdaten (Betreff, Priorität etc.), jedes Weiterleiten und jedes Schließen setzt den Besitz des Tickets voraus. Wird eine solche Funktion bei Tickets ausgeführt, die nicht in der eigenen ToDo-Liste liegen, erscheint vor dem Speichern ein Dialog „Für diese Funktion müssen Sie zunächst den Besitz des Tickets übernehmen. [übernehmen] [abbrechen]“. Die Übernahme wird sofort durch einen Weiterleitungs-Eintrag im Ticket protokolliert. Unmittelbar im Anschluß wird die änderung bzw. Ergänzung gespeichert. Kein Besitzerwechsel ist notwendig beim Anfügen von Notizen sowie beim Ändern von Kontaktdaten.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Weiterleitung führt nicht zum Statuswechsel&lt;/span&gt;<br /> :Die Weiterleitung eines Tickets soll nicht zu einem Statuswechsel führen. Offene Tickets bleiben durch eine Weiterleitung offen, eskalierte Tickets bleiben eskaliert usw.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Weiterleitung ohne Notiz ermöglichen&lt;/span&gt;<br /> :Es soll möglich sein ein Ticket weiterzuleiten ohne zugleich eine Notiz anzufügen.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Statuswechsel 'offen' zu 'in Arbeit'&lt;/span&gt;<br /> :Ein Statuswechsel von 'offen' zu 'in Arbeit' ist abhängig von der Umgebung in der eine Aktion am Ticket ausgeführt wird. Innerhalb von InfoTicket erfolgt ein Statuswechsel automatisch beim ersten Speichern eines Tickets. Ausnahme: Weiterleitung und Kontaktdaten. <br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Versionsabgleich&lt;/span&gt;<br /> :Vor dem Speichern einer Ticketbearbeitung wird der Versionsstand mit dem Server abgeglichen. Liegt zwischenzeitlich eine neuere Version auf dem Server vor, wird diese nach einem Hinweis neu geladen. Der Speichervorgang wird abgebrochen und kann wiederholt werden. Neu hinzugekommene Einträge in der Historie werden farbig gekennzeichnet. Tickets brauchen somit nicht vor konkurrierendem Zugriff geschützt (gelockt) zu werden.<br /> <br /> ==Milestone 5 - 15.01.2011==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Ticket aus CityCall115 anlegen&lt;/span&gt;<br /> :Über die Oberfläche von CityCall115 können Tickets angelegt werden<br /> :*Definition von HTML-Formularen über einen Formulargenerator<br /> :*Ausgabe aller Formulare auf einer eigenen Formular-Seite<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Formularservice&lt;/span&gt;<br /> :Es wird ein allgemeiner Formularservice eingerichtet<br /> :*Eingabe der Formulardaten<br /> :*Eingabe der BürgerKontakt-Daten, nach Einverständnis<br /> :*Prüfung/Korrektur der vorausgewählten Empfänger (aus der Dienstleistung oder Visitenkarte)<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;InfoTicket Funktionen:&lt;/span&gt;<br /> :Anpassungen der folgenden InfoTicket Funktionen<br /> :*Der Betreff eines Tickets darf nicht leer sein.<br /> :*In der Detailansicht der Tickets wird ein Bearbeitungsschritt nicht aufklappbar dargestellt (Plus-Symbol), wenn kein darszustellender Inhalt vorhanden ist.<br /> :*Erfasste Kontaktdaten zum Anrufenden müssen immer angezeigt werden, egal ob die E-Mail-Adresse eingegeben wurde.<br /> :*Der Statusfilter funktioniert nicht korrekt: Egal welcher Haken entfernt wird, werden alle Tickets ausgeblendet.<br /> :*Werden vom Statusfilter alle Haken entfernt, wird eine Fehlermeldung ausgegeben.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Design-Review und Feinschliff&lt;/span&gt;<br /> :Überprüfung der bestehenden Umsetzung des vorgesehenen Screendesigns und ggf. Nachbesserung<br /> :*Das Filtersymbol (Trichter) wird angepasst<br /> <br /> ==Milestone 6 - 11.02.2011==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;CityCall115&lt;/span&gt;<br /> :Anpassung der Oberfläche von CityCall115<br /> :*Die Beschriftung der Menüpunktes &quot;Formulare&quot; ändern in &quot;Ticket erstellen&quot;.<br /> :*Der Button &quot;Ticket erstellen&quot; auf der rechten Seite in der Oberfläche von CityCall115 müssen entfernt werden.<br /> :*Deaktivierung des Menüpunktes &quot;Bürgeranfrage&quot;.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Ticket aus CityCall115 anlegen&lt;/span&gt;<br /> :Über die Oberfläche von CityCall115 können Tickets angelegt werden<br /> :*Definition von Pflichtfeldern für Kontaktdaten je Formular konfigurierbar<br /> :*Einführung eines Hinweistextes für die Kontaktdatenerfassung.<br /> :*Abfrage der Zustimmung des Bürgers zum Speichern persönlicher Daten.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;InfoTicket-Funktionen&lt;/span&gt;<br /> :Anpassungen der folgenden InfoTicket Funktionen <br /> :*In der Übersichtsseite wird eine zusätzliche Spalte für die Darstellung der Ticketbesitzer eingebaut.<br /> :*Steht die Ticketauswahl auf &quot;Eigene Tickets&quot; und der Filter wird auf &quot;geschlossene Tickets&quot; gestellt, soll der Nutzer nur die Tickets angezeigt bekommen, die auch von ihm geschlossen wurden und nicht alle geschlossenen Tickets.<br /> :*Nach einem Logout soll der Nutzername und das Passwort nicht automatisch in den entsprechenden Feldern stehen bleiben, sondern nur der Nutzername. (Achtung: Das gilt nicht für die Funktion &quot;Passwort speichern&quot; des Browsers. Wird diese Funktion genutzt haben wir keinen Einfluss auf das automatische Eintragen von Nutzerdaten.)<br /> :*Paging in der Übersicht nach Änderung der Filtereinstellung korrigieren.<br /> :*Im Tooltip zur Erstellung für Hyperlinks, in der Erstellung von Notizen sollte das Wort &quot;text&quot; am Ende des Satzes groß geschrieben werden.<br /> :*Die Suche soll auch über Kontaktdaten suchen.<br /> <br /> ==Milestone 7 - 25.02.2011==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;InfoTicket-Funktionen&lt;/span&gt;<br /> :Ticket-Typen müssen frei definierbar (konfigurierbar sein)&lt;br/&gt;Eigenschaften eines Ticket-Typs sind:<br /> ::Name<br /> ::Beschreibung (Tooltip?)<br /> ::Sortierwert<br /> ::Eskalationszeit<br /> ::Icon<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Eskalation&lt;/span&gt;<br /> :Auswertung der Eskalationszeit unter Berücksichtigung von Wochenenden und Feiertagen.<br /> :: Wie folgt zu berechnen<br /> ::* http://openbook.galileodesign.de/javainsel5/javainsel10_006.htm#Rxx747java10006040003451F0291C3<br /> ::* http://de.wikipedia.org/wiki/Feiertage_in_Deutschland<br /> :: Implementierte Logik:<br /> :: Es gibt zwei Modi:<br /> ::* Arbeitstage<br /> ::: Wenn als Eskalationszeit Arbeitstage angegeben wurde, dann werden &quot;nicht Arbeitstage&quot; wie Wochenende oder Feiertage für den zu errechnenden Eskalationszeitpunkt nicht mit berechnet. Wird Beispielsweise ein Ticket am Donnerstag um 16:00 angelegt und hat eine Eskalationszeit von 3 Arbeitstagen, dann eskaliert das Ticket am Dienstag um 16:00 (wenn Samstag und Sonntag als &quot;nicht Arbeitstage&quot; konfiguriert wurden). Das Ticket kann ausserhalb der Arbeits'''zeit''' eskalieren, aber nur an einem Arbeits'''tag'''.<br /> ::* Arbeitsstunden<br /> ::: Wenn als Eskalationszeit Arbeitsstunden angegeben wurden, dann wird der Eskalationszeitpunkt nur über die konfigurierte Arbeitszeit berechnet.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Datenschutz&lt;/span&gt;<br /> :automatisches Löschen von Personendatensätzen, wenn das letzte &lt;b&gt;offene&lt;/b&gt; Ticket, das auf einen Personendatensatz verweist, geschlossen wird.<br /> <br /> ==Milestone 8 - bis Ende März 2011==<br /> ;&lt;span style=&quot;color:green&quot;&gt;Rechteverwaltung&lt;/span&gt;<br /> :Definition und Umsetzung einer Rechteverwaltung, zunächst unter Nutzung der bestehenden Oberfläche von InfoSite.<br /> :*Erstellung einer Konzeption<br /> :*Implementierung der Funktionalität in die Oberfläche von InfoSite<br /> :*Technische Anpassung der Formularverwaltung in CityCall115<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Ticket aus CityCall115 anlegen&lt;/span&gt;<br /> :Über die Oberfläche von CityCall115 können Tickets angelegt werden<br /> :*Integration eines &quot;Ticket&quot;-Reiters bei allen Dienstleistungen innerhalb der CityCall115-Ausgabe von CityGov 3.<br /> :*Darstellung eines &quot;Ticket&quot;-Buttons bei allen Kontakten innerhalb der CityCall115-Ausgabe von CityGov 3.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Dokumentation&lt;/span&gt;<br /> :Bereitstellung einer vorläufigen Bedienungsanleitung.<br /> <br /> ==Milestone 9 (Qualitätssicherung) - April 2011==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Performanz-Tests mit vielen Tickets und parallelen Zugriffen&lt;/span&gt;<br /> : Optimierung der Antwortzeiten für Ticket-Listen<br /> ;&lt;span style=&quot;color:green&quot;&gt;Stabilitäts-Tests&lt;/span&gt;<br /> ;&lt;span style=&quot;color:green&quot;&gt;Funktions-Tests&lt;/span&gt;<br /> <br /> ==Milestone 10 - Mai 2011==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Konfiguration der Arbeitszeit und Arbeitstage&lt;/span&gt;<br /> :Unabhängigkeit der Arbeitszeit und Arbeitstage auflösen. Wenn Arbeitszeit konfiguriert ist, ist es automatisch ein Arbeitstag (Häkchen nicht änderbar).<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Design-Review&lt;/span&gt;<br /> :Anpassung der neuen Konfigurations-Dialoge<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Suche&lt;/span&gt;<br /> :Volltextsuche muss auch Tickets über die Ticket-ID finden.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Druckansicht&lt;/span&gt;<br /> :Über einen Button wird ein neues Fenster geöffnet, der die Historie eines Tickets ausdruckbar darstellt.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Upload und Verwaltung von Anhängen&lt;/span&gt;<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Eskalation&lt;/span&gt;<br /> :Implementierung von Funktionen zur Auflösung von Eskalationen<br /> :*Vor einer Weiterleitung eines eskalierten Tickets wird der Anwender gefragt, ob er zuvor noch einen neuen Eskalations-Termin setzen möchte.<br /> :*Ein Ticket was sich im Status &quot;Eskalation&quot; befindet kann vom Besitzer jederzeit eine neue Eskalations- und Erinnerungszeit erhalten. Das Ticket wechselt dann wieder in den Status 'In Arbeit'. Hierfür gibt es im Kopfbereich des Tickets eine Schaltfläche. Die neue Eskalations- und Erinnerungszeit kann unabhängig vom Tickettyp frei eingestellt werden.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Neue Ticket-Stati&lt;/span&gt;<br /> :Implementierung neuer Ticket-Stati für<br /> :*Warte auf Kunden-Antwort&lt;br&gt;&quot;Warte auf Kunden-Antwort&quot; ist ein Ticket-Status, der die Zeitmessung für Eskalations- und Erinnerungszeiten pausieren lässt. <br /> :*Warte auf Wiedervorlage&lt;br&gt;&quot;Warte auf Wiedervorlage&quot; ist ein Ticket-Status, bei dem die Zeitmessung für Eskalations- und Erinnerungszeiten weiterläuft.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Adresse in der Browseradressleiste nach Logout auf Standard-URL des Ticketsystems zurücksetzen.&lt;/span&gt;<br /> :Sonst kann es vorkommen, dass nach dem Aufruf eines Tickets über eine URL mit der ID als Parameter trotz Logout das Ticket immer wieder aufgerufen wird. Der Nutzer sollte hier direkt zur Übersichtsseite gelangen.<br /> <br /> ==Milestone 11 - Juli 2011==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Technische Implementierung des Multi-Accordion Layout-Managers für die rechte Spalte.&lt;/style&gt;<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Erweiterung der Konfiguration der arbeitsfreien Tage&lt;/span&gt;<br /> :Es sollten auch eigene relative Arbeitstage konfiguriert werden können<br /> :Eigene arbeitsfreie Tage sollen nachträglich in der Tabelle editiert werden können.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;gelesen-Flag für Ticket&lt;/span&gt;<br /> :neue Tickets im eigenen Eingang werden mit Symbol in separater Spalte und fett als ungelesen gekennzeichnet.<br /> :Tickets werden automatisch als gelesen gekennzeichnet, wenn man sie öffnet.<br /> :Wenn ein anderer Nutzer eine Notiz anfügt, wird das gelesen-Flag zurückgesetzt und der Besitzer des Tickets per Mail benachrichtigt.<br /> :''Anm.: Das gelesen-Flag ist ausschließlich zur Identifikation neuer Tickets im eigenen Eingang vorgesehen und kann nicht zurückgesetzt werden. Eine Prioritätenverwaltung sollte über die Prioritäteneigenschaften des Tickets erfolgen.''<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;allgemeine Favoritenverwaltung&lt;/span&gt;<br /> :Favoriten sind nutzerbezogene Listen von Elementen. Die Pflege von Favoriten erfolgt individuell durch jedem Nutzer, eine zentrale Bereitstellung von Favoriten ist nicht vorgesehen.<br /> :In InfoTicket handelt es sich bei den Favoriten um ausgewählte Weiterleitungsempfänger, die im Weiterleitungsdialog gesondert zur Auswahl angeboten werden.<br /> :Die Verwaltung der Favoriten erfolgt in InfoTicket innerhalb des Weiterleiten-Dialoges. Favoriten werden in Gruppen verwaltet, von denen folgende vorgesehen sind:<br /> :*Historie&lt;br&gt;Liste der zuletzt verwendeten Weiterleitungsempfänger, chronologisch sortiert<br /> :*Häufig genutzt&lt;br&gt;Liste der Weiterleitungsempfänger an die am häufigsten ein Ticket weitergeleitet wurde, sortiert nach Häufigkeit<br /> :*Lesezeichen&lt;br&gt;individuell pflegbare Liste von Weiterleitungsempfängern, alphabetisch sortiert nach Nachnahme. Hinzugefügt werden Empfänger, indem sie im Weiterleitungs-Dialog markiert werden. Gelöscht werden sie über die löschen-Funktion (rechte Maustaste bzw. Auswahl und &quot;Entf&quot;-Taste).<br /> :*Suchergebnisse&lt;br&gt;Beliebig viele Listen, deren Inhalt das Ergebnis eine Suche ist, alphabetisch dortiert nach nachnahme. Hinzugefügt werden Suchergebnisse über die Suchen-Funktion im Weiterleiten-Dialog. Einzelne Empfänger können nicht aus dem Suchergebnis entfernt werden. Listen können umbenannt und über die löschen-Funktion entfernt werden.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Drag and Drop für Weiterleitungen über die rechte Spalte&lt;/span&gt;<br /> :In der Übersichtsseite wird in die rechte Spalte eine Schnell-Weiterleiten-Funktion eingebaut über die aus der Liste von Tickets ein oder mehrere Tickets per Drag and Drop an einen Empfänger weitergeleitet werden können. Über einen Popup-Dialog kann der Weiterleitung eine Notiz hinzugefügt werden. Bei Mehrfach-Weiterleitungen erhalten alle Tickets die gleiche Notiz.<br /> :Die aufgelisteten Weiterleitungs-Empfänger sind Nutzer einer in der Box auswählbaren Favoritengruppe<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;erweiterter Weiterleiten-Auswahl-Dialog&lt;/span&gt;<br /> :Der Standard-Auswahldialog wird erweitert um:<br /> :*Suchfunktion<br /> :*Favoritenliste<br /> :*verschiedene Ansichten<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Textvorlagen auswählen , erstellen, löschen&lt;/span&gt;<br /> :Textvorlagen werden in der rechten Spalte der Ticket-Detaildarstellung angeboten.<br /> :Über einen Dialog mit WYSIWYG-Editor kann eine Textvorlage erstellt oder bearbeitet werden.<br /> :Textvorlagen lassen sich über die rechte Maustaste und Auswahldialog löschen oder bearbeiten.<br /> :Textvorlagen werden per Doppelklick an die aktive Cursorposition des Notiz-Feldes eingefügt.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Datenschutz&lt;/span&gt;<br /> :Erweiterung der Funktion nach der Personendatensätze gelöscht werden, wenn kein offenes Ticket mehr auf einen Datensatz verweist um einen konfigurierbaren zeitlichen Versatz. (Kontakte werden z.B. erst 3 Monate nachdem das letzte Ticket geschlossen wird, gelöscht.)<br /> <br /> ==Milestone 12 - Oktober 2011 ==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Unvollständig-Funktion&lt;/span&gt;<br /> :Die Unvollständig-Funktion soll über das Ticketing-System abgedeckt werden.<br /> :*Unvollständigkeitsmeldung als Ticket verfassen.<br /> :*Den Button &quot;Unvollständig&quot; auf der rechten Seite in der Oberfläche von CityCall115 entfernen, wenn ein Unvollständig-Ticket erstellt werden kann.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;CityCall115&lt;/span&gt;<br /> :Der Betreff eines Tickets kann beim Anlegen durch den Agenten optional um Zusatzinformationen ergänzt werden.<br /> :Funktion zur Ticket-Recherche und zum Anfügen von Notizen für Agenten.<br /> <br /> ==Milestone 13 - November 2011 ==<br /> <br /> ;Code Review / Code Optimierung<br /> : Umstellung auf ExtJS 4<br /> <br /> ;Agenten (Absender des Tickets)<br /> :Alle Agenten müssen in das InfoTicket-System synchronisiert werden.<br /> <br /> ;Statistik über Tickets<br /> :Statistik-Angaben<br /> :*Anzahl an eskalierten Tickets in einem Zeitraum.<br /> :*Anzahl an aktiven Nutzern<br /> :*Anzahl an inaktiven Nutzern (keine Ticketbearbeitung innerhalb der letzten paar Monate)<br /> :*Anzahl an registrierten Nutzern<br /> :*Anzahl an Bürgerdatensätzen<br /> :*Längste Ticketbearbeitungsdauer<br /> :*Kürzeste Ticketbearbeitungsdauer<br /> :*Durchschnittliche Ticketbearbeitungsdauer<br /> :*Anzahl offener Tickets<br /> :*Anzahl eskalierter Tickets<br /> :*Anzahl der Tickets pro zugeordneter Diensleistung/Organisationseinheit innerhalb eines wählbaren Zeitraums.<br /> <br /> ;Statistik im Ticket<br /> :kurze Statistik-Angaben zum Ticket in der rechten Spalte<br /> :*Anzahl an Eskalationen<br /> :*Anzahl an Weiterleitungen<br /> <br /> ;Anpassung von Eskalationszeiten nach Ticketstatusänderung<br /> <br /> ==Milestone 14==<br /> <br /> ;Ticket-id soll ohne Typ und Mandanten-Kennung verwendet werden<br /> :Suchabfrage muss diese ID schon so zurückliefern (oder per JavaScript beschneiden)<br /> :Alle RPC-Funktionen des TicketSystems müssen die ID in dem neuen Format lesen können und auch so zurück liefern.<br /> <br /> ;Mail-Gateway<br /> :Mailversand:<br /> :*Als Antwort<br /> :*Als Weiterleitung an Extern<br /> :*Konfigurationsmöglichkeit für einen zentralen Footer, der durch Variablen Nutzerdaten einfügen kann (Name, Vorname, Abteilung, …)<br /> <br /> :Mailempfang:<br /> :*E-Mail als Ticket (siehe altes Dokument)<br /> :*E-Mail als externe Nachricht am Ticket<br /> :*E-Mail als Antwort für Weiterleitung an Extern<br /> <br /> ;Integration der D115 Meldungstypen (Empfang und Bearbeitung)<br /> <br /> ==Milestone 15==<br /> <br /> ;Formular-Service<br /> :Erstellung von Benachrichtigung über einen Dienst, der die Formulardaten auswertet und pdf und/oder xml Dateien erstellt und je nach Konfiguration eine Mail oder ein Ticket erstellt.<br /> <br /> ;GUI Nutzerverwaltung / Rechtevergabe<br /> :Neues GUI, als Prototyp für eine Applikation auf Basis der IES Nutzerverwaltung. Die technischen Möglichkeiten des IES / InfoSite bleiben bis auf die obige Erweiterung erhalten und werden durch das neue GUI bedient. Ggf. sind Erweiterungen nötig!?<br /> :Die Nutzerliste im Nutzerpool enthält direkte Hinweise auf die zugewiesenen Rollen des einzelnen Nutzers.<br /> <br /> ==Milestone X==<br /> <br /> ;Subtickets<br /> <br /> ;Workflow:<br /> ;:Tickets können durch ihre Definition eine Abfolge von Nutzer(-gruppen) enthalten, die durch eine „Weiter“ und „Zurück“ Navigation durchlaufen werden.<br /> <br /> ;erweiterte Suchfunktion<br /> :muss noch definiert werden<br /> <br /> <br /> &lt;noinclude&gt;<br /> [[Kategorie:Partner]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=InfoTicket_-_Roadmap&diff=5674 2011-10-26T12:25:32Z

<p>Liebold: /* Milestone 12 - Oktober 2011 */</p> <hr /> <div>==Milestone 1 - Erste präsentierbare Version auf pp.sitepark.com==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Kontaktdaten anlegen&lt;/span&gt;<br /> :- Verknüpfung auf einen KontaktDatensatz durch Angabe der ID des Kontaktes oder<br /> :- Verknüpfen durch Angabe der Kontaktdaten in dem 'contact' Feld. Die E-Mail dient als eindeutiger Identifier um den Datensatz im System zu finden. Wird kein Eintrag gefunden, wir der Kontaktdatensatz angelegt und verknüpft.<br /> :Bei Gleichheit von E-Mail-Adresse werden die übergebenen Daten überschrieben.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Folgende Eigenschaften müssen noch konfigurierbar werden&lt;/span&gt;<br /> :&lt;span style=&quot;color:green; font-weight:bold&quot;&gt;OK&lt;/span&gt; Verkünpfung zwischen CallCenter-Mandant und InfoTicket-Mandant. Mandant und Nutzer im 'TicketArtikel' des CallCenters konfigurierbar.<br /> :&lt;span style=&quot;color:green; font-weight:bold&quot;&gt;OK&lt;/span&gt; InfoTicket-Nutzer als Absender (Temporäre, nur für Milestone 1)<br /> :&lt;span style=&quot;color:green; font-weight:bold&quot;&gt;offen&lt;/span&gt; Workflowverhalten (Eskalationszeiten, ...). hart kodiert. Welche Werte? (1 Tag!)<br /> :&lt;span style=&quot;color:green; font-weight:bold&quot;&gt;OK&lt;/span&gt; Aussehen der E-Mail. <br /> <br /> ;&lt;span style=&quot;color:green; font-weight:bold&quot;&gt;Ticket aus dem CallCenter anlegen&lt;/span&gt;<br /> :&lt;span style=&quot;color:green; font-weight:bold&quot;&gt;OK&lt;/span&gt; Über Bürgeranfrage <br /> :&lt;span style=&quot;color:green; font-weight:bold&quot;&gt;OK&lt;/span&gt; Über Mitarbeiter-Visitenkarte - Standard Ticket öffnen<br /> :&lt;span style=&quot;color:green; font-weight:bold&quot;&gt;OK&lt;/span&gt; Über Dienstleistung - Standard Ticket öffnen<br /> <br /> ;&lt;span style=&quot;color:green; font-weight:bold&quot;&gt;Wie soll der Ticket-Mandant ermittelt werden, damit beim Login-Fenster keine Auswahl erscheint?&lt;/span&gt;<br /> : Antwort:<br /> :#Es werden alle Mandanten abgefragt, die aktiv sind und mit dem InfoTicket-Mandanten verknüpft sind. Entspricht nur ein Mandant diesen Kriterien wird keine Auswahl angezeigt und nur dieser verwendet.<br /> :#Es kann per URL-Parameter der gewünschte Mandant übergeben werden (ParameterName 'client', Wert ist der Anchor des Mandanten)<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Namensformat&lt;/span&gt;<br /> :Nutzernamen können (noch) nicht an allen Stellen über die ID ermittelt werden (Bei einer Suchabfrage müssen select user-&gt;name funktionieren), darum wird der Nutzername direkt gespeichert und nicht seine ID. Für diese Fälle muss das Namensformat (Nachname, Vorname, Title) überall gleich sein.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Fehlerbehandlung&lt;/span&gt;<br /> :Auf Serverseite müssen noch ein paar Fehlerzustände abgefangen werden.<br /> :;createTicket<br /> ::Wenn Email-Adresse in 'participant' nicht gefunden werden kann muss ein Fehler auftreten.<br /> ::Wenn ID in 'participant' nicht existiert<br /> ::Wenn ID in 'participant' existiert, Nutzer aber keine Email-Adresse hat.<br /> :;getTicket<br /> :: ID nicht gefunden<br /> :: Ticket ist bereist geschlossen<br /> :: Ticket ist weitergeleitet. Bearbeitet kann Ticket nicht mehr bearbeiten<br /> :;addTicketItem<br /> :: ID nicht gefunden<br /> :: Ticket ist bereist geschlossen<br /> :: Ticket ist weitergeleitet. Bearbeitet kann Ticket nicht mehr bearbeiten<br /> :: Übergebene Werte validieren (ticketType, priority, ...)<br /> :; closeTicket<br /> :: ID nicht gefunden<br /> :: Ticket ist bereist geschlossen<br /> :: Ticket ist weitergeleitet. Bearbeitet kann Ticket nicht mehr bearbeiten<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Ticket-Eigenschaften&lt;/span&gt;<br /> :nächste Wiedervorlagen, nächste Eskalation<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Agenten (Absender des Tickets)&lt;/span&gt;<br /> :Globaler IES-Nutzer aus dem Infoticket-Mandant wird als Absender gesetzt.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Installation auf pp.sitepark.com&lt;/span&gt;<br /> :Zwei Mandanten: Master und Work<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Auswahlliste der Empfänger im CallCenter&lt;/span&gt;<br /> :Wie kommen die Nutzer in das TicketSystem? Werden per Hand angelegt.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Sortierreihenfolge von Status, Typ und Aktion&lt;/span&gt;<br /> :''Status''<br /> :# Eskalation<br /> :# Erinnerung<br /> :# offen<br /> :# in Arbeit<br /> :# (geschlossen?)<br /> <br /> :''Typ''<br /> :# Aktennotiz<br /> :# Aufgabe<br /> :# Beschwerde<br /> :# D115-Weiterleitung<br /> :# Information<br /> :# Rückrufwunsch<br /> :# Störungsmeldung<br /> <br /> :''Aktion'' (für Ticket-Einträge)<br /> :# Neu<br /> :# Änderung<br /> :# Notiz<br /> :# Erinnerung<br /> :# Eskalation<br /> :# Weiterleitung<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Locking von Tickets&lt;/span&gt;<br /> :Kein Locking<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Konzeption: Eigenschaften ändern / Notiz anlegen&lt;/span&gt;<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Nachfrage-Dialog für Weiterleitungsbestätigung&lt;/span&gt;<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Speichern ohne Kommentar ist so in Ordung&lt;/span&gt;<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Subject muss man ändern können&lt;/span&gt;<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Wenn eine neue Notiz hinzugefügt wird, werden alle Einträge zugeklappt und nur der letzte geöffnet. Die Einträge, die geöffnet wurde sollen aber weiter offen bleiben. Es soll auch weiterhin zu dem letzten Eintrag gescrollt werden.&lt;/span&gt;<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Wenn Ticket-Tag geschlossen wird, muss nachgefragt werden, Wenn Ticket noch einen Message enthält (Wenn 'aktion ausführen' Button akive ist)&lt;/span&gt;<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Bei Kontakt ohne Telefon steht 'null', muss durch langen Strich ersetzt werden&lt;/span&gt;<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Bei öffnen des Tabs, Sanduhr an Maus bis Tab geöffnet&lt;/span&gt;<br /> :Fazit: So nicht zu realisieren.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Aufbau des Tab ruckelt (Firefox). Prüfen, ob das verhindert werden kann.&lt;/span&gt;<br /> :Geprüft. Der unruhige Aufbau läßt sich nicht so einfach nachstellen. Muss wohl an sehr langsamen Rechnern liegen. Habe auch keinen Weg gefunden da etwas zu verbessern.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Ticket-Einträge müssen nicht ausgewählt werden können. Auch ohne Mouse-over&lt;/span&gt;<br /> <br /> ==Milestone 2 - Mo, 27.09.2010==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;gestalteter Login-Dialog, Seitenhintergrund&lt;/span&gt;<br /> <br /> ==Milestone 3 - Ende Oktober 2010==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Kontaktdaten anlegen&lt;/span&gt;<br /> :Kontakte können beim Anlegen von Tickets erstellt werden, wenn keine bestehender Kontakt ausgewählt wurde.<br /> :Wenn Daten gefunden wurden, werden nach Auswahl des Kontakts alle Daten angezeigt.<br /> :Bei Gleichheit von E-Mail Adresse (oder Auswahl eines gefundenen Kontaktes) werden die Datenfelder aktualisiert.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Ticket aus CityCall115 anlegen (vorläufig)&lt;/span&gt;<br /> :An Personendatensatz Ticket öffnen, z.B. Rückrufwunsch<br /> :An Dienstleistung Ticket öffnen<br /> :*Personenticket (Kontakt)<br /> :*Alle Kontakte der Dienstleistung als Vorschlag<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Geschlossene Tickets anzeigen&lt;/span&gt;<br /> :Ist soweit implementiert. Folgendes fehlt noch<br /> :* Vorgabe für GUI zum aktivieren/deaktivieren des Filters (Nane)<br /> :* Bugfix, geschlossen Tickets haben nicht den Status 'geschlossen' (Ralf)<br /> <br /> ==Milestone 4 Fr, 03.12.2010==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Code-Optimierung (Java) (1 Tage)&lt;/span&gt;<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;GUI Sicht auf Tickets anderer Nutzer (Nutzerauswahl)&lt;/span&gt;<br /> :Dropdown mit allen Nutzern auf deren Tickets mindestens Leserechte bestehen<br /> :*Zusätzlicher Punkt: alle Nutzer <br /> :*Nur eigene Tickets im Zugriff -&gt; Dropdown entfällt<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Einfache Ticketsuche&lt;/span&gt;<br /> :Die Suche ist ein weiterer Filter, der einschränkend wirkt (UND-Verknüpfung)<br /> :*die Suche berücksichtigt die Nutzerauswahl, d.h. die Suche ist auf den/die gewählten Nutzer eingeschränkt<br /> :*die Suche verwendet die aktiven Filterkriterien<br /> :*die Suche wirkt solange als Filter, bis das Suchfeld gelöscht wird<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Kontaktdaten&lt;/span&gt;<br /> :Auch innerhalb von InfoTicket müssen die Kontaktdaten bearbeitet werden können.<br /> :E-Mail-Adressen bei der Darstellung von Kontaktdaten werden mit mailto:-Link versehen.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Geschlossene Tickets öffnen&lt;/span&gt;<br /> :Inhalte geschlossener Tickets müssen einsehbar sein<br /> :Geschlossene Tickets müssen wieder geöffnet werden können<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Notizen anfügen&lt;/span&gt;<br /> :Jeder kann jederzeit an jedes Ticket, auch an geschlossene Tickets, Notizen anfügen, sofern die Oberfläche von InfoTicket bzw. CityCall115 einen Zugriff auf das Ticket erlaubt. Hierfür muss sich das Ticket nicht im eigenen Besitz befinden und durch die Bearbeitung findet auch kein Besitzerwechsel statt.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Automatischer Besitzerwechsel bei mehreren Empfängern&lt;/span&gt;<br /> :Tickets, die in meiner ToDo-Liste liegen und mehreren Empfängern zugewiesen sind, wechseln beim Öffnen automatisch den Besitzer und werden mir zugewiesen. Der Besitzerwechsel wird als Weiterleitung protokolliert und erscheint sofort als letzter Eintrag im geöffneten Ticket. Tickets, die nicht in meiner ToDo-Liste liegen, wechseln beim Öffnen nicht den Besitzer.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Besitzerwechsel bei Bedarf&lt;/span&gt;<br /> :In InfoTicket kann jeder jedes Ticket bearbeiten, wenn im Rahmen eines übergreifenden Rechtemanagements Zugriffsrechte bestehen. Jedes Ändern von Headerdaten (Betreff, Priorität etc.), jedes Weiterleiten und jedes Schließen setzt den Besitz des Tickets voraus. Wird eine solche Funktion bei Tickets ausgeführt, die nicht in der eigenen ToDo-Liste liegen, erscheint vor dem Speichern ein Dialog „Für diese Funktion müssen Sie zunächst den Besitz des Tickets übernehmen. [übernehmen] [abbrechen]“. Die Übernahme wird sofort durch einen Weiterleitungs-Eintrag im Ticket protokolliert. Unmittelbar im Anschluß wird die änderung bzw. Ergänzung gespeichert. Kein Besitzerwechsel ist notwendig beim Anfügen von Notizen sowie beim Ändern von Kontaktdaten.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Weiterleitung führt nicht zum Statuswechsel&lt;/span&gt;<br /> :Die Weiterleitung eines Tickets soll nicht zu einem Statuswechsel führen. Offene Tickets bleiben durch eine Weiterleitung offen, eskalierte Tickets bleiben eskaliert usw.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Weiterleitung ohne Notiz ermöglichen&lt;/span&gt;<br /> :Es soll möglich sein ein Ticket weiterzuleiten ohne zugleich eine Notiz anzufügen.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Statuswechsel 'offen' zu 'in Arbeit'&lt;/span&gt;<br /> :Ein Statuswechsel von 'offen' zu 'in Arbeit' ist abhängig von der Umgebung in der eine Aktion am Ticket ausgeführt wird. Innerhalb von InfoTicket erfolgt ein Statuswechsel automatisch beim ersten Speichern eines Tickets. Ausnahme: Weiterleitung und Kontaktdaten. <br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Versionsabgleich&lt;/span&gt;<br /> :Vor dem Speichern einer Ticketbearbeitung wird der Versionsstand mit dem Server abgeglichen. Liegt zwischenzeitlich eine neuere Version auf dem Server vor, wird diese nach einem Hinweis neu geladen. Der Speichervorgang wird abgebrochen und kann wiederholt werden. Neu hinzugekommene Einträge in der Historie werden farbig gekennzeichnet. Tickets brauchen somit nicht vor konkurrierendem Zugriff geschützt (gelockt) zu werden.<br /> <br /> ==Milestone 5 - 15.01.2011==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Ticket aus CityCall115 anlegen&lt;/span&gt;<br /> :Über die Oberfläche von CityCall115 können Tickets angelegt werden<br /> :*Definition von HTML-Formularen über einen Formulargenerator<br /> :*Ausgabe aller Formulare auf einer eigenen Formular-Seite<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Formularservice&lt;/span&gt;<br /> :Es wird ein allgemeiner Formularservice eingerichtet<br /> :*Eingabe der Formulardaten<br /> :*Eingabe der BürgerKontakt-Daten, nach Einverständnis<br /> :*Prüfung/Korrektur der vorausgewählten Empfänger (aus der Dienstleistung oder Visitenkarte)<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;InfoTicket Funktionen:&lt;/span&gt;<br /> :Anpassungen der folgenden InfoTicket Funktionen<br /> :*Der Betreff eines Tickets darf nicht leer sein.<br /> :*In der Detailansicht der Tickets wird ein Bearbeitungsschritt nicht aufklappbar dargestellt (Plus-Symbol), wenn kein darszustellender Inhalt vorhanden ist.<br /> :*Erfasste Kontaktdaten zum Anrufenden müssen immer angezeigt werden, egal ob die E-Mail-Adresse eingegeben wurde.<br /> :*Der Statusfilter funktioniert nicht korrekt: Egal welcher Haken entfernt wird, werden alle Tickets ausgeblendet.<br /> :*Werden vom Statusfilter alle Haken entfernt, wird eine Fehlermeldung ausgegeben.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Design-Review und Feinschliff&lt;/span&gt;<br /> :Überprüfung der bestehenden Umsetzung des vorgesehenen Screendesigns und ggf. Nachbesserung<br /> :*Das Filtersymbol (Trichter) wird angepasst<br /> <br /> ==Milestone 6 - 11.02.2011==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;CityCall115&lt;/span&gt;<br /> :Anpassung der Oberfläche von CityCall115<br /> :*Die Beschriftung der Menüpunktes &quot;Formulare&quot; ändern in &quot;Ticket erstellen&quot;.<br /> :*Der Button &quot;Ticket erstellen&quot; auf der rechten Seite in der Oberfläche von CityCall115 müssen entfernt werden.<br /> :*Deaktivierung des Menüpunktes &quot;Bürgeranfrage&quot;.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Ticket aus CityCall115 anlegen&lt;/span&gt;<br /> :Über die Oberfläche von CityCall115 können Tickets angelegt werden<br /> :*Definition von Pflichtfeldern für Kontaktdaten je Formular konfigurierbar<br /> :*Einführung eines Hinweistextes für die Kontaktdatenerfassung.<br /> :*Abfrage der Zustimmung des Bürgers zum Speichern persönlicher Daten.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;InfoTicket-Funktionen&lt;/span&gt;<br /> :Anpassungen der folgenden InfoTicket Funktionen <br /> :*In der Übersichtsseite wird eine zusätzliche Spalte für die Darstellung der Ticketbesitzer eingebaut.<br /> :*Steht die Ticketauswahl auf &quot;Eigene Tickets&quot; und der Filter wird auf &quot;geschlossene Tickets&quot; gestellt, soll der Nutzer nur die Tickets angezeigt bekommen, die auch von ihm geschlossen wurden und nicht alle geschlossenen Tickets.<br /> :*Nach einem Logout soll der Nutzername und das Passwort nicht automatisch in den entsprechenden Feldern stehen bleiben, sondern nur der Nutzername. (Achtung: Das gilt nicht für die Funktion &quot;Passwort speichern&quot; des Browsers. Wird diese Funktion genutzt haben wir keinen Einfluss auf das automatische Eintragen von Nutzerdaten.)<br /> :*Paging in der Übersicht nach Änderung der Filtereinstellung korrigieren.<br /> :*Im Tooltip zur Erstellung für Hyperlinks, in der Erstellung von Notizen sollte das Wort &quot;text&quot; am Ende des Satzes groß geschrieben werden.<br /> :*Die Suche soll auch über Kontaktdaten suchen.<br /> <br /> ==Milestone 7 - 25.02.2011==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;InfoTicket-Funktionen&lt;/span&gt;<br /> :Ticket-Typen müssen frei definierbar (konfigurierbar sein)&lt;br/&gt;Eigenschaften eines Ticket-Typs sind:<br /> ::Name<br /> ::Beschreibung (Tooltip?)<br /> ::Sortierwert<br /> ::Eskalationszeit<br /> ::Icon<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Eskalation&lt;/span&gt;<br /> :Auswertung der Eskalationszeit unter Berücksichtigung von Wochenenden und Feiertagen.<br /> :: Wie folgt zu berechnen<br /> ::* http://openbook.galileodesign.de/javainsel5/javainsel10_006.htm#Rxx747java10006040003451F0291C3<br /> ::* http://de.wikipedia.org/wiki/Feiertage_in_Deutschland<br /> :: Implementierte Logik:<br /> :: Es gibt zwei Modi:<br /> ::* Arbeitstage<br /> ::: Wenn als Eskalationszeit Arbeitstage angegeben wurde, dann werden &quot;nicht Arbeitstage&quot; wie Wochenende oder Feiertage für den zu errechnenden Eskalationszeitpunkt nicht mit berechnet. Wird Beispielsweise ein Ticket am Donnerstag um 16:00 angelegt und hat eine Eskalationszeit von 3 Arbeitstagen, dann eskaliert das Ticket am Dienstag um 16:00 (wenn Samstag und Sonntag als &quot;nicht Arbeitstage&quot; konfiguriert wurden). Das Ticket kann ausserhalb der Arbeits'''zeit''' eskalieren, aber nur an einem Arbeits'''tag'''.<br /> ::* Arbeitsstunden<br /> ::: Wenn als Eskalationszeit Arbeitsstunden angegeben wurden, dann wird der Eskalationszeitpunkt nur über die konfigurierte Arbeitszeit berechnet.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Datenschutz&lt;/span&gt;<br /> :automatisches Löschen von Personendatensätzen, wenn das letzte &lt;b&gt;offene&lt;/b&gt; Ticket, das auf einen Personendatensatz verweist, geschlossen wird.<br /> <br /> ==Milestone 8 - bis Ende März 2011==<br /> ;&lt;span style=&quot;color:green&quot;&gt;Rechteverwaltung&lt;/span&gt;<br /> :Definition und Umsetzung einer Rechteverwaltung, zunächst unter Nutzung der bestehenden Oberfläche von InfoSite.<br /> :*Erstellung einer Konzeption<br /> :*Implementierung der Funktionalität in die Oberfläche von InfoSite<br /> :*Technische Anpassung der Formularverwaltung in CityCall115<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Ticket aus CityCall115 anlegen&lt;/span&gt;<br /> :Über die Oberfläche von CityCall115 können Tickets angelegt werden<br /> :*Integration eines &quot;Ticket&quot;-Reiters bei allen Dienstleistungen innerhalb der CityCall115-Ausgabe von CityGov 3.<br /> :*Darstellung eines &quot;Ticket&quot;-Buttons bei allen Kontakten innerhalb der CityCall115-Ausgabe von CityGov 3.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Dokumentation&lt;/span&gt;<br /> :Bereitstellung einer vorläufigen Bedienungsanleitung.<br /> <br /> ==Milestone 9 (Qualitätssicherung) - April 2011==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Performanz-Tests mit vielen Tickets und parallelen Zugriffen&lt;/span&gt;<br /> : Optimierung der Antwortzeiten für Ticket-Listen<br /> ;&lt;span style=&quot;color:green&quot;&gt;Stabilitäts-Tests&lt;/span&gt;<br /> ;&lt;span style=&quot;color:green&quot;&gt;Funktions-Tests&lt;/span&gt;<br /> <br /> ==Milestone 10 - Mai 2011==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Konfiguration der Arbeitszeit und Arbeitstage&lt;/span&gt;<br /> :Unabhängigkeit der Arbeitszeit und Arbeitstage auflösen. Wenn Arbeitszeit konfiguriert ist, ist es automatisch ein Arbeitstag (Häkchen nicht änderbar).<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Design-Review&lt;/span&gt;<br /> :Anpassung der neuen Konfigurations-Dialoge<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Suche&lt;/span&gt;<br /> :Volltextsuche muss auch Tickets über die Ticket-ID finden.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Druckansicht&lt;/span&gt;<br /> :Über einen Button wird ein neues Fenster geöffnet, der die Historie eines Tickets ausdruckbar darstellt.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Upload und Verwaltung von Anhängen&lt;/span&gt;<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Eskalation&lt;/span&gt;<br /> :Implementierung von Funktionen zur Auflösung von Eskalationen<br /> :*Vor einer Weiterleitung eines eskalierten Tickets wird der Anwender gefragt, ob er zuvor noch einen neuen Eskalations-Termin setzen möchte.<br /> :*Ein Ticket was sich im Status &quot;Eskalation&quot; befindet kann vom Besitzer jederzeit eine neue Eskalations- und Erinnerungszeit erhalten. Das Ticket wechselt dann wieder in den Status 'In Arbeit'. Hierfür gibt es im Kopfbereich des Tickets eine Schaltfläche. Die neue Eskalations- und Erinnerungszeit kann unabhängig vom Tickettyp frei eingestellt werden.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Neue Ticket-Stati&lt;/span&gt;<br /> :Implementierung neuer Ticket-Stati für<br /> :*Warte auf Kunden-Antwort&lt;br&gt;&quot;Warte auf Kunden-Antwort&quot; ist ein Ticket-Status, der die Zeitmessung für Eskalations- und Erinnerungszeiten pausieren lässt. <br /> :*Warte auf Wiedervorlage&lt;br&gt;&quot;Warte auf Wiedervorlage&quot; ist ein Ticket-Status, bei dem die Zeitmessung für Eskalations- und Erinnerungszeiten weiterläuft.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Adresse in der Browseradressleiste nach Logout auf Standard-URL des Ticketsystems zurücksetzen.&lt;/span&gt;<br /> :Sonst kann es vorkommen, dass nach dem Aufruf eines Tickets über eine URL mit der ID als Parameter trotz Logout das Ticket immer wieder aufgerufen wird. Der Nutzer sollte hier direkt zur Übersichtsseite gelangen.<br /> <br /> ==Milestone 11 - Juli 2011==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Technische Implementierung des Multi-Accordion Layout-Managers für die rechte Spalte.&lt;/style&gt;<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Erweiterung der Konfiguration der arbeitsfreien Tage&lt;/span&gt;<br /> :Es sollten auch eigene relative Arbeitstage konfiguriert werden können<br /> :Eigene arbeitsfreie Tage sollen nachträglich in der Tabelle editiert werden können.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;gelesen-Flag für Ticket&lt;/span&gt;<br /> :neue Tickets im eigenen Eingang werden mit Symbol in separater Spalte und fett als ungelesen gekennzeichnet.<br /> :Tickets werden automatisch als gelesen gekennzeichnet, wenn man sie öffnet.<br /> :Wenn ein anderer Nutzer eine Notiz anfügt, wird das gelesen-Flag zurückgesetzt und der Besitzer des Tickets per Mail benachrichtigt.<br /> :''Anm.: Das gelesen-Flag ist ausschließlich zur Identifikation neuer Tickets im eigenen Eingang vorgesehen und kann nicht zurückgesetzt werden. Eine Prioritätenverwaltung sollte über die Prioritäteneigenschaften des Tickets erfolgen.''<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;allgemeine Favoritenverwaltung&lt;/span&gt;<br /> :Favoriten sind nutzerbezogene Listen von Elementen. Die Pflege von Favoriten erfolgt individuell durch jedem Nutzer, eine zentrale Bereitstellung von Favoriten ist nicht vorgesehen.<br /> :In InfoTicket handelt es sich bei den Favoriten um ausgewählte Weiterleitungsempfänger, die im Weiterleitungsdialog gesondert zur Auswahl angeboten werden.<br /> :Die Verwaltung der Favoriten erfolgt in InfoTicket innerhalb des Weiterleiten-Dialoges. Favoriten werden in Gruppen verwaltet, von denen folgende vorgesehen sind:<br /> :*Historie&lt;br&gt;Liste der zuletzt verwendeten Weiterleitungsempfänger, chronologisch sortiert<br /> :*Häufig genutzt&lt;br&gt;Liste der Weiterleitungsempfänger an die am häufigsten ein Ticket weitergeleitet wurde, sortiert nach Häufigkeit<br /> :*Lesezeichen&lt;br&gt;individuell pflegbare Liste von Weiterleitungsempfängern, alphabetisch sortiert nach Nachnahme. Hinzugefügt werden Empfänger, indem sie im Weiterleitungs-Dialog markiert werden. Gelöscht werden sie über die löschen-Funktion (rechte Maustaste bzw. Auswahl und &quot;Entf&quot;-Taste).<br /> :*Suchergebnisse&lt;br&gt;Beliebig viele Listen, deren Inhalt das Ergebnis eine Suche ist, alphabetisch dortiert nach nachnahme. Hinzugefügt werden Suchergebnisse über die Suchen-Funktion im Weiterleiten-Dialog. Einzelne Empfänger können nicht aus dem Suchergebnis entfernt werden. Listen können umbenannt und über die löschen-Funktion entfernt werden.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Drag and Drop für Weiterleitungen über die rechte Spalte&lt;/span&gt;<br /> :In der Übersichtsseite wird in die rechte Spalte eine Schnell-Weiterleiten-Funktion eingebaut über die aus der Liste von Tickets ein oder mehrere Tickets per Drag and Drop an einen Empfänger weitergeleitet werden können. Über einen Popup-Dialog kann der Weiterleitung eine Notiz hinzugefügt werden. Bei Mehrfach-Weiterleitungen erhalten alle Tickets die gleiche Notiz.<br /> :Die aufgelisteten Weiterleitungs-Empfänger sind Nutzer einer in der Box auswählbaren Favoritengruppe<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;erweiterter Weiterleiten-Auswahl-Dialog&lt;/span&gt;<br /> :Der Standard-Auswahldialog wird erweitert um:<br /> :*Suchfunktion<br /> :*Favoritenliste<br /> :*verschiedene Ansichten<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Textvorlagen auswählen , erstellen, löschen&lt;/span&gt;<br /> :Textvorlagen werden in der rechten Spalte der Ticket-Detaildarstellung angeboten.<br /> :Über einen Dialog mit WYSIWYG-Editor kann eine Textvorlage erstellt oder bearbeitet werden.<br /> :Textvorlagen lassen sich über die rechte Maustaste und Auswahldialog löschen oder bearbeiten.<br /> :Textvorlagen werden per Doppelklick an die aktive Cursorposition des Notiz-Feldes eingefügt.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Datenschutz&lt;/span&gt;<br /> :Erweiterung der Funktion nach der Personendatensätze gelöscht werden, wenn kein offenes Ticket mehr auf einen Datensatz verweist um einen konfigurierbaren zeitlichen Versatz. (Kontakte werden z.B. erst 3 Monate nachdem das letzte Ticket geschlossen wird, gelöscht.)<br /> <br /> ==Milestone 12 - Oktober 2011 ==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Unvollständig-Funktion&lt;/span&gt;<br /> :Die Unvollständig-Funktion soll über das Ticketing-System abgedeckt werden.<br /> :*Unvollständigkeitsmeldung als Ticket verfassen.<br /> :*Den Button &quot;Unvollständig&quot; auf der rechten Seite in der Oberfläche von CityCall115 entfernen, wenn ein Unvollständig-Ticket erstellt werden kann.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;CityCall115&lt;/span&gt;<br /> :Der Betreff eines Tickets kann beim Anlegen durch den Agenten optional um Zusatzinformationen ergänzt werden.<br /> :Funktion zur Ticket-Recherche und zum Anfügen von Notizen für Agenten.<br /> <br /> ==Milestone 13 - November 2011 ==<br /> <br /> ;Code Review / Code Optimierung<br /> : Umstellung auf ExtJS 4<br /> <br /> ;Agenten (Absender des Tickets)<br /> :Alle Agenten müssen in das InfoTicket-System synchronisiert werden.<br /> <br /> ;Statistik über Tickets<br /> :Statistik-Angaben<br /> :*Anzahl an eskalierten Tickets in einem Zeitraum.<br /> :*Anzahl an aktiven Nutzern<br /> :*Anzahl an inaktiven Nutzern (keine Ticketbearbeitung innerhalb der letzten paar Monate)<br /> :*Anzahl an registrierten Nutzern<br /> :*Anzahl an Bürgerdatensätzen<br /> :*Längste Ticketbearbeitungsdauer<br /> :*Kürzeste Ticketbearbeitungsdauer<br /> :*Durchschnittliche Ticketbearbeitungsdauer<br /> :*Anzahl offener Tickets<br /> :*Anzahl eskalierter Tickets<br /> :*Anzahl der Tickets pro zugeordneter Diensleistung/Organisationseinheit innerhalb eines wählbaren Zeitraums.<br /> <br /> ;Statistik im Ticket<br /> :kurze Statistik-Angaben zum Ticket in der rechten Spalte<br /> :*Anzahl an Eskalationen<br /> :*Anzahl an Weiterleitungen<br /> <br /> ==Milestone 14==<br /> <br /> ;Ticket-id soll ohne Typ und Mandanten-Kennung verwendet werden<br /> :Suchabfrage muss diese ID schon so zurückliefern (oder per JavaScript beschneiden)<br /> :Alle RPC-Funktionen des TicketSystems müssen die ID in dem neuen Format lesen können und auch so zurück liefern.<br /> <br /> ;Mail-Gateway<br /> :Mailversand:<br /> :*Als Antwort<br /> :*Als Weiterleitung an Extern<br /> :*Konfigurationsmöglichkeit für einen zentralen Footer, der durch Variablen Nutzerdaten einfügen kann (Name, Vorname, Abteilung, …)<br /> <br /> :Mailempfang:<br /> :*E-Mail als Ticket (siehe altes Dokument)<br /> :*E-Mail als externe Nachricht am Ticket<br /> :*E-Mail als Antwort für Weiterleitung an Extern<br /> <br /> ;Integration der D115 Meldungstypen (Empfang und Bearbeitung)<br /> <br /> ==Milestone 15==<br /> <br /> ;Formular-Service<br /> :Erstellung von Benachrichtigung über einen Dienst, der die Formulardaten auswertet und pdf und/oder xml Dateien erstellt und je nach Konfiguration eine Mail oder ein Ticket erstellt.<br /> <br /> ;GUI Nutzerverwaltung / Rechtevergabe<br /> :Neues GUI, als Prototyp für eine Applikation auf Basis der IES Nutzerverwaltung. Die technischen Möglichkeiten des IES / InfoSite bleiben bis auf die obige Erweiterung erhalten und werden durch das neue GUI bedient. Ggf. sind Erweiterungen nötig!?<br /> :Die Nutzerliste im Nutzerpool enthält direkte Hinweise auf die zugewiesenen Rollen des einzelnen Nutzers.<br /> <br /> ==Milestone X==<br /> <br /> ;Subtickets<br /> <br /> ;Workflow:<br /> ;:Tickets können durch ihre Definition eine Abfolge von Nutzer(-gruppen) enthalten, die durch eine „Weiter“ und „Zurück“ Navigation durchlaufen werden.<br /> <br /> ;erweiterte Suchfunktion<br /> :muss noch definiert werden<br /> <br /> <br /> &lt;noinclude&gt;<br /> [[Kategorie:Partner]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=InfoTicket_-_Roadmap&diff=5673 2011-10-26T12:24:51Z

<p>Liebold: /* Milestone 12 - Oktober 2011 */</p> <hr /> <div>==Milestone 1 - Erste präsentierbare Version auf pp.sitepark.com==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Kontaktdaten anlegen&lt;/span&gt;<br /> :- Verknüpfung auf einen KontaktDatensatz durch Angabe der ID des Kontaktes oder<br /> :- Verknüpfen durch Angabe der Kontaktdaten in dem 'contact' Feld. Die E-Mail dient als eindeutiger Identifier um den Datensatz im System zu finden. Wird kein Eintrag gefunden, wir der Kontaktdatensatz angelegt und verknüpft.<br /> :Bei Gleichheit von E-Mail-Adresse werden die übergebenen Daten überschrieben.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Folgende Eigenschaften müssen noch konfigurierbar werden&lt;/span&gt;<br /> :&lt;span style=&quot;color:green; font-weight:bold&quot;&gt;OK&lt;/span&gt; Verkünpfung zwischen CallCenter-Mandant und InfoTicket-Mandant. Mandant und Nutzer im 'TicketArtikel' des CallCenters konfigurierbar.<br /> :&lt;span style=&quot;color:green; font-weight:bold&quot;&gt;OK&lt;/span&gt; InfoTicket-Nutzer als Absender (Temporäre, nur für Milestone 1)<br /> :&lt;span style=&quot;color:green; font-weight:bold&quot;&gt;offen&lt;/span&gt; Workflowverhalten (Eskalationszeiten, ...). hart kodiert. Welche Werte? (1 Tag!)<br /> :&lt;span style=&quot;color:green; font-weight:bold&quot;&gt;OK&lt;/span&gt; Aussehen der E-Mail. <br /> <br /> ;&lt;span style=&quot;color:green; font-weight:bold&quot;&gt;Ticket aus dem CallCenter anlegen&lt;/span&gt;<br /> :&lt;span style=&quot;color:green; font-weight:bold&quot;&gt;OK&lt;/span&gt; Über Bürgeranfrage <br /> :&lt;span style=&quot;color:green; font-weight:bold&quot;&gt;OK&lt;/span&gt; Über Mitarbeiter-Visitenkarte - Standard Ticket öffnen<br /> :&lt;span style=&quot;color:green; font-weight:bold&quot;&gt;OK&lt;/span&gt; Über Dienstleistung - Standard Ticket öffnen<br /> <br /> ;&lt;span style=&quot;color:green; font-weight:bold&quot;&gt;Wie soll der Ticket-Mandant ermittelt werden, damit beim Login-Fenster keine Auswahl erscheint?&lt;/span&gt;<br /> : Antwort:<br /> :#Es werden alle Mandanten abgefragt, die aktiv sind und mit dem InfoTicket-Mandanten verknüpft sind. Entspricht nur ein Mandant diesen Kriterien wird keine Auswahl angezeigt und nur dieser verwendet.<br /> :#Es kann per URL-Parameter der gewünschte Mandant übergeben werden (ParameterName 'client', Wert ist der Anchor des Mandanten)<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Namensformat&lt;/span&gt;<br /> :Nutzernamen können (noch) nicht an allen Stellen über die ID ermittelt werden (Bei einer Suchabfrage müssen select user-&gt;name funktionieren), darum wird der Nutzername direkt gespeichert und nicht seine ID. Für diese Fälle muss das Namensformat (Nachname, Vorname, Title) überall gleich sein.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Fehlerbehandlung&lt;/span&gt;<br /> :Auf Serverseite müssen noch ein paar Fehlerzustände abgefangen werden.<br /> :;createTicket<br /> ::Wenn Email-Adresse in 'participant' nicht gefunden werden kann muss ein Fehler auftreten.<br /> ::Wenn ID in 'participant' nicht existiert<br /> ::Wenn ID in 'participant' existiert, Nutzer aber keine Email-Adresse hat.<br /> :;getTicket<br /> :: ID nicht gefunden<br /> :: Ticket ist bereist geschlossen<br /> :: Ticket ist weitergeleitet. Bearbeitet kann Ticket nicht mehr bearbeiten<br /> :;addTicketItem<br /> :: ID nicht gefunden<br /> :: Ticket ist bereist geschlossen<br /> :: Ticket ist weitergeleitet. Bearbeitet kann Ticket nicht mehr bearbeiten<br /> :: Übergebene Werte validieren (ticketType, priority, ...)<br /> :; closeTicket<br /> :: ID nicht gefunden<br /> :: Ticket ist bereist geschlossen<br /> :: Ticket ist weitergeleitet. Bearbeitet kann Ticket nicht mehr bearbeiten<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Ticket-Eigenschaften&lt;/span&gt;<br /> :nächste Wiedervorlagen, nächste Eskalation<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Agenten (Absender des Tickets)&lt;/span&gt;<br /> :Globaler IES-Nutzer aus dem Infoticket-Mandant wird als Absender gesetzt.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Installation auf pp.sitepark.com&lt;/span&gt;<br /> :Zwei Mandanten: Master und Work<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Auswahlliste der Empfänger im CallCenter&lt;/span&gt;<br /> :Wie kommen die Nutzer in das TicketSystem? Werden per Hand angelegt.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Sortierreihenfolge von Status, Typ und Aktion&lt;/span&gt;<br /> :''Status''<br /> :# Eskalation<br /> :# Erinnerung<br /> :# offen<br /> :# in Arbeit<br /> :# (geschlossen?)<br /> <br /> :''Typ''<br /> :# Aktennotiz<br /> :# Aufgabe<br /> :# Beschwerde<br /> :# D115-Weiterleitung<br /> :# Information<br /> :# Rückrufwunsch<br /> :# Störungsmeldung<br /> <br /> :''Aktion'' (für Ticket-Einträge)<br /> :# Neu<br /> :# Änderung<br /> :# Notiz<br /> :# Erinnerung<br /> :# Eskalation<br /> :# Weiterleitung<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Locking von Tickets&lt;/span&gt;<br /> :Kein Locking<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Konzeption: Eigenschaften ändern / Notiz anlegen&lt;/span&gt;<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Nachfrage-Dialog für Weiterleitungsbestätigung&lt;/span&gt;<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Speichern ohne Kommentar ist so in Ordung&lt;/span&gt;<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Subject muss man ändern können&lt;/span&gt;<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Wenn eine neue Notiz hinzugefügt wird, werden alle Einträge zugeklappt und nur der letzte geöffnet. Die Einträge, die geöffnet wurde sollen aber weiter offen bleiben. Es soll auch weiterhin zu dem letzten Eintrag gescrollt werden.&lt;/span&gt;<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Wenn Ticket-Tag geschlossen wird, muss nachgefragt werden, Wenn Ticket noch einen Message enthält (Wenn 'aktion ausführen' Button akive ist)&lt;/span&gt;<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Bei Kontakt ohne Telefon steht 'null', muss durch langen Strich ersetzt werden&lt;/span&gt;<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Bei öffnen des Tabs, Sanduhr an Maus bis Tab geöffnet&lt;/span&gt;<br /> :Fazit: So nicht zu realisieren.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Aufbau des Tab ruckelt (Firefox). Prüfen, ob das verhindert werden kann.&lt;/span&gt;<br /> :Geprüft. Der unruhige Aufbau läßt sich nicht so einfach nachstellen. Muss wohl an sehr langsamen Rechnern liegen. Habe auch keinen Weg gefunden da etwas zu verbessern.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Ticket-Einträge müssen nicht ausgewählt werden können. Auch ohne Mouse-over&lt;/span&gt;<br /> <br /> ==Milestone 2 - Mo, 27.09.2010==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;gestalteter Login-Dialog, Seitenhintergrund&lt;/span&gt;<br /> <br /> ==Milestone 3 - Ende Oktober 2010==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Kontaktdaten anlegen&lt;/span&gt;<br /> :Kontakte können beim Anlegen von Tickets erstellt werden, wenn keine bestehender Kontakt ausgewählt wurde.<br /> :Wenn Daten gefunden wurden, werden nach Auswahl des Kontakts alle Daten angezeigt.<br /> :Bei Gleichheit von E-Mail Adresse (oder Auswahl eines gefundenen Kontaktes) werden die Datenfelder aktualisiert.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Ticket aus CityCall115 anlegen (vorläufig)&lt;/span&gt;<br /> :An Personendatensatz Ticket öffnen, z.B. Rückrufwunsch<br /> :An Dienstleistung Ticket öffnen<br /> :*Personenticket (Kontakt)<br /> :*Alle Kontakte der Dienstleistung als Vorschlag<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Geschlossene Tickets anzeigen&lt;/span&gt;<br /> :Ist soweit implementiert. Folgendes fehlt noch<br /> :* Vorgabe für GUI zum aktivieren/deaktivieren des Filters (Nane)<br /> :* Bugfix, geschlossen Tickets haben nicht den Status 'geschlossen' (Ralf)<br /> <br /> ==Milestone 4 Fr, 03.12.2010==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Code-Optimierung (Java) (1 Tage)&lt;/span&gt;<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;GUI Sicht auf Tickets anderer Nutzer (Nutzerauswahl)&lt;/span&gt;<br /> :Dropdown mit allen Nutzern auf deren Tickets mindestens Leserechte bestehen<br /> :*Zusätzlicher Punkt: alle Nutzer <br /> :*Nur eigene Tickets im Zugriff -&gt; Dropdown entfällt<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Einfache Ticketsuche&lt;/span&gt;<br /> :Die Suche ist ein weiterer Filter, der einschränkend wirkt (UND-Verknüpfung)<br /> :*die Suche berücksichtigt die Nutzerauswahl, d.h. die Suche ist auf den/die gewählten Nutzer eingeschränkt<br /> :*die Suche verwendet die aktiven Filterkriterien<br /> :*die Suche wirkt solange als Filter, bis das Suchfeld gelöscht wird<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Kontaktdaten&lt;/span&gt;<br /> :Auch innerhalb von InfoTicket müssen die Kontaktdaten bearbeitet werden können.<br /> :E-Mail-Adressen bei der Darstellung von Kontaktdaten werden mit mailto:-Link versehen.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Geschlossene Tickets öffnen&lt;/span&gt;<br /> :Inhalte geschlossener Tickets müssen einsehbar sein<br /> :Geschlossene Tickets müssen wieder geöffnet werden können<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Notizen anfügen&lt;/span&gt;<br /> :Jeder kann jederzeit an jedes Ticket, auch an geschlossene Tickets, Notizen anfügen, sofern die Oberfläche von InfoTicket bzw. CityCall115 einen Zugriff auf das Ticket erlaubt. Hierfür muss sich das Ticket nicht im eigenen Besitz befinden und durch die Bearbeitung findet auch kein Besitzerwechsel statt.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Automatischer Besitzerwechsel bei mehreren Empfängern&lt;/span&gt;<br /> :Tickets, die in meiner ToDo-Liste liegen und mehreren Empfängern zugewiesen sind, wechseln beim Öffnen automatisch den Besitzer und werden mir zugewiesen. Der Besitzerwechsel wird als Weiterleitung protokolliert und erscheint sofort als letzter Eintrag im geöffneten Ticket. Tickets, die nicht in meiner ToDo-Liste liegen, wechseln beim Öffnen nicht den Besitzer.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Besitzerwechsel bei Bedarf&lt;/span&gt;<br /> :In InfoTicket kann jeder jedes Ticket bearbeiten, wenn im Rahmen eines übergreifenden Rechtemanagements Zugriffsrechte bestehen. Jedes Ändern von Headerdaten (Betreff, Priorität etc.), jedes Weiterleiten und jedes Schließen setzt den Besitz des Tickets voraus. Wird eine solche Funktion bei Tickets ausgeführt, die nicht in der eigenen ToDo-Liste liegen, erscheint vor dem Speichern ein Dialog „Für diese Funktion müssen Sie zunächst den Besitz des Tickets übernehmen. [übernehmen] [abbrechen]“. Die Übernahme wird sofort durch einen Weiterleitungs-Eintrag im Ticket protokolliert. Unmittelbar im Anschluß wird die änderung bzw. Ergänzung gespeichert. Kein Besitzerwechsel ist notwendig beim Anfügen von Notizen sowie beim Ändern von Kontaktdaten.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Weiterleitung führt nicht zum Statuswechsel&lt;/span&gt;<br /> :Die Weiterleitung eines Tickets soll nicht zu einem Statuswechsel führen. Offene Tickets bleiben durch eine Weiterleitung offen, eskalierte Tickets bleiben eskaliert usw.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Weiterleitung ohne Notiz ermöglichen&lt;/span&gt;<br /> :Es soll möglich sein ein Ticket weiterzuleiten ohne zugleich eine Notiz anzufügen.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Statuswechsel 'offen' zu 'in Arbeit'&lt;/span&gt;<br /> :Ein Statuswechsel von 'offen' zu 'in Arbeit' ist abhängig von der Umgebung in der eine Aktion am Ticket ausgeführt wird. Innerhalb von InfoTicket erfolgt ein Statuswechsel automatisch beim ersten Speichern eines Tickets. Ausnahme: Weiterleitung und Kontaktdaten. <br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Versionsabgleich&lt;/span&gt;<br /> :Vor dem Speichern einer Ticketbearbeitung wird der Versionsstand mit dem Server abgeglichen. Liegt zwischenzeitlich eine neuere Version auf dem Server vor, wird diese nach einem Hinweis neu geladen. Der Speichervorgang wird abgebrochen und kann wiederholt werden. Neu hinzugekommene Einträge in der Historie werden farbig gekennzeichnet. Tickets brauchen somit nicht vor konkurrierendem Zugriff geschützt (gelockt) zu werden.<br /> <br /> ==Milestone 5 - 15.01.2011==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Ticket aus CityCall115 anlegen&lt;/span&gt;<br /> :Über die Oberfläche von CityCall115 können Tickets angelegt werden<br /> :*Definition von HTML-Formularen über einen Formulargenerator<br /> :*Ausgabe aller Formulare auf einer eigenen Formular-Seite<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Formularservice&lt;/span&gt;<br /> :Es wird ein allgemeiner Formularservice eingerichtet<br /> :*Eingabe der Formulardaten<br /> :*Eingabe der BürgerKontakt-Daten, nach Einverständnis<br /> :*Prüfung/Korrektur der vorausgewählten Empfänger (aus der Dienstleistung oder Visitenkarte)<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;InfoTicket Funktionen:&lt;/span&gt;<br /> :Anpassungen der folgenden InfoTicket Funktionen<br /> :*Der Betreff eines Tickets darf nicht leer sein.<br /> :*In der Detailansicht der Tickets wird ein Bearbeitungsschritt nicht aufklappbar dargestellt (Plus-Symbol), wenn kein darszustellender Inhalt vorhanden ist.<br /> :*Erfasste Kontaktdaten zum Anrufenden müssen immer angezeigt werden, egal ob die E-Mail-Adresse eingegeben wurde.<br /> :*Der Statusfilter funktioniert nicht korrekt: Egal welcher Haken entfernt wird, werden alle Tickets ausgeblendet.<br /> :*Werden vom Statusfilter alle Haken entfernt, wird eine Fehlermeldung ausgegeben.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Design-Review und Feinschliff&lt;/span&gt;<br /> :Überprüfung der bestehenden Umsetzung des vorgesehenen Screendesigns und ggf. Nachbesserung<br /> :*Das Filtersymbol (Trichter) wird angepasst<br /> <br /> ==Milestone 6 - 11.02.2011==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;CityCall115&lt;/span&gt;<br /> :Anpassung der Oberfläche von CityCall115<br /> :*Die Beschriftung der Menüpunktes &quot;Formulare&quot; ändern in &quot;Ticket erstellen&quot;.<br /> :*Der Button &quot;Ticket erstellen&quot; auf der rechten Seite in der Oberfläche von CityCall115 müssen entfernt werden.<br /> :*Deaktivierung des Menüpunktes &quot;Bürgeranfrage&quot;.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Ticket aus CityCall115 anlegen&lt;/span&gt;<br /> :Über die Oberfläche von CityCall115 können Tickets angelegt werden<br /> :*Definition von Pflichtfeldern für Kontaktdaten je Formular konfigurierbar<br /> :*Einführung eines Hinweistextes für die Kontaktdatenerfassung.<br /> :*Abfrage der Zustimmung des Bürgers zum Speichern persönlicher Daten.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;InfoTicket-Funktionen&lt;/span&gt;<br /> :Anpassungen der folgenden InfoTicket Funktionen <br /> :*In der Übersichtsseite wird eine zusätzliche Spalte für die Darstellung der Ticketbesitzer eingebaut.<br /> :*Steht die Ticketauswahl auf &quot;Eigene Tickets&quot; und der Filter wird auf &quot;geschlossene Tickets&quot; gestellt, soll der Nutzer nur die Tickets angezeigt bekommen, die auch von ihm geschlossen wurden und nicht alle geschlossenen Tickets.<br /> :*Nach einem Logout soll der Nutzername und das Passwort nicht automatisch in den entsprechenden Feldern stehen bleiben, sondern nur der Nutzername. (Achtung: Das gilt nicht für die Funktion &quot;Passwort speichern&quot; des Browsers. Wird diese Funktion genutzt haben wir keinen Einfluss auf das automatische Eintragen von Nutzerdaten.)<br /> :*Paging in der Übersicht nach Änderung der Filtereinstellung korrigieren.<br /> :*Im Tooltip zur Erstellung für Hyperlinks, in der Erstellung von Notizen sollte das Wort &quot;text&quot; am Ende des Satzes groß geschrieben werden.<br /> :*Die Suche soll auch über Kontaktdaten suchen.<br /> <br /> ==Milestone 7 - 25.02.2011==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;InfoTicket-Funktionen&lt;/span&gt;<br /> :Ticket-Typen müssen frei definierbar (konfigurierbar sein)&lt;br/&gt;Eigenschaften eines Ticket-Typs sind:<br /> ::Name<br /> ::Beschreibung (Tooltip?)<br /> ::Sortierwert<br /> ::Eskalationszeit<br /> ::Icon<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Eskalation&lt;/span&gt;<br /> :Auswertung der Eskalationszeit unter Berücksichtigung von Wochenenden und Feiertagen.<br /> :: Wie folgt zu berechnen<br /> ::* http://openbook.galileodesign.de/javainsel5/javainsel10_006.htm#Rxx747java10006040003451F0291C3<br /> ::* http://de.wikipedia.org/wiki/Feiertage_in_Deutschland<br /> :: Implementierte Logik:<br /> :: Es gibt zwei Modi:<br /> ::* Arbeitstage<br /> ::: Wenn als Eskalationszeit Arbeitstage angegeben wurde, dann werden &quot;nicht Arbeitstage&quot; wie Wochenende oder Feiertage für den zu errechnenden Eskalationszeitpunkt nicht mit berechnet. Wird Beispielsweise ein Ticket am Donnerstag um 16:00 angelegt und hat eine Eskalationszeit von 3 Arbeitstagen, dann eskaliert das Ticket am Dienstag um 16:00 (wenn Samstag und Sonntag als &quot;nicht Arbeitstage&quot; konfiguriert wurden). Das Ticket kann ausserhalb der Arbeits'''zeit''' eskalieren, aber nur an einem Arbeits'''tag'''.<br /> ::* Arbeitsstunden<br /> ::: Wenn als Eskalationszeit Arbeitsstunden angegeben wurden, dann wird der Eskalationszeitpunkt nur über die konfigurierte Arbeitszeit berechnet.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Datenschutz&lt;/span&gt;<br /> :automatisches Löschen von Personendatensätzen, wenn das letzte &lt;b&gt;offene&lt;/b&gt; Ticket, das auf einen Personendatensatz verweist, geschlossen wird.<br /> <br /> ==Milestone 8 - bis Ende März 2011==<br /> ;&lt;span style=&quot;color:green&quot;&gt;Rechteverwaltung&lt;/span&gt;<br /> :Definition und Umsetzung einer Rechteverwaltung, zunächst unter Nutzung der bestehenden Oberfläche von InfoSite.<br /> :*Erstellung einer Konzeption<br /> :*Implementierung der Funktionalität in die Oberfläche von InfoSite<br /> :*Technische Anpassung der Formularverwaltung in CityCall115<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Ticket aus CityCall115 anlegen&lt;/span&gt;<br /> :Über die Oberfläche von CityCall115 können Tickets angelegt werden<br /> :*Integration eines &quot;Ticket&quot;-Reiters bei allen Dienstleistungen innerhalb der CityCall115-Ausgabe von CityGov 3.<br /> :*Darstellung eines &quot;Ticket&quot;-Buttons bei allen Kontakten innerhalb der CityCall115-Ausgabe von CityGov 3.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Dokumentation&lt;/span&gt;<br /> :Bereitstellung einer vorläufigen Bedienungsanleitung.<br /> <br /> ==Milestone 9 (Qualitätssicherung) - April 2011==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Performanz-Tests mit vielen Tickets und parallelen Zugriffen&lt;/span&gt;<br /> : Optimierung der Antwortzeiten für Ticket-Listen<br /> ;&lt;span style=&quot;color:green&quot;&gt;Stabilitäts-Tests&lt;/span&gt;<br /> ;&lt;span style=&quot;color:green&quot;&gt;Funktions-Tests&lt;/span&gt;<br /> <br /> ==Milestone 10 - Mai 2011==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Konfiguration der Arbeitszeit und Arbeitstage&lt;/span&gt;<br /> :Unabhängigkeit der Arbeitszeit und Arbeitstage auflösen. Wenn Arbeitszeit konfiguriert ist, ist es automatisch ein Arbeitstag (Häkchen nicht änderbar).<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Design-Review&lt;/span&gt;<br /> :Anpassung der neuen Konfigurations-Dialoge<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Suche&lt;/span&gt;<br /> :Volltextsuche muss auch Tickets über die Ticket-ID finden.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Druckansicht&lt;/span&gt;<br /> :Über einen Button wird ein neues Fenster geöffnet, der die Historie eines Tickets ausdruckbar darstellt.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Upload und Verwaltung von Anhängen&lt;/span&gt;<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Eskalation&lt;/span&gt;<br /> :Implementierung von Funktionen zur Auflösung von Eskalationen<br /> :*Vor einer Weiterleitung eines eskalierten Tickets wird der Anwender gefragt, ob er zuvor noch einen neuen Eskalations-Termin setzen möchte.<br /> :*Ein Ticket was sich im Status &quot;Eskalation&quot; befindet kann vom Besitzer jederzeit eine neue Eskalations- und Erinnerungszeit erhalten. Das Ticket wechselt dann wieder in den Status 'In Arbeit'. Hierfür gibt es im Kopfbereich des Tickets eine Schaltfläche. Die neue Eskalations- und Erinnerungszeit kann unabhängig vom Tickettyp frei eingestellt werden.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Neue Ticket-Stati&lt;/span&gt;<br /> :Implementierung neuer Ticket-Stati für<br /> :*Warte auf Kunden-Antwort&lt;br&gt;&quot;Warte auf Kunden-Antwort&quot; ist ein Ticket-Status, der die Zeitmessung für Eskalations- und Erinnerungszeiten pausieren lässt. <br /> :*Warte auf Wiedervorlage&lt;br&gt;&quot;Warte auf Wiedervorlage&quot; ist ein Ticket-Status, bei dem die Zeitmessung für Eskalations- und Erinnerungszeiten weiterläuft.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Adresse in der Browseradressleiste nach Logout auf Standard-URL des Ticketsystems zurücksetzen.&lt;/span&gt;<br /> :Sonst kann es vorkommen, dass nach dem Aufruf eines Tickets über eine URL mit der ID als Parameter trotz Logout das Ticket immer wieder aufgerufen wird. Der Nutzer sollte hier direkt zur Übersichtsseite gelangen.<br /> <br /> ==Milestone 11 - Juli 2011==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Technische Implementierung des Multi-Accordion Layout-Managers für die rechte Spalte.&lt;/style&gt;<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Erweiterung der Konfiguration der arbeitsfreien Tage&lt;/span&gt;<br /> :Es sollten auch eigene relative Arbeitstage konfiguriert werden können<br /> :Eigene arbeitsfreie Tage sollen nachträglich in der Tabelle editiert werden können.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;gelesen-Flag für Ticket&lt;/span&gt;<br /> :neue Tickets im eigenen Eingang werden mit Symbol in separater Spalte und fett als ungelesen gekennzeichnet.<br /> :Tickets werden automatisch als gelesen gekennzeichnet, wenn man sie öffnet.<br /> :Wenn ein anderer Nutzer eine Notiz anfügt, wird das gelesen-Flag zurückgesetzt und der Besitzer des Tickets per Mail benachrichtigt.<br /> :''Anm.: Das gelesen-Flag ist ausschließlich zur Identifikation neuer Tickets im eigenen Eingang vorgesehen und kann nicht zurückgesetzt werden. Eine Prioritätenverwaltung sollte über die Prioritäteneigenschaften des Tickets erfolgen.''<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;allgemeine Favoritenverwaltung&lt;/span&gt;<br /> :Favoriten sind nutzerbezogene Listen von Elementen. Die Pflege von Favoriten erfolgt individuell durch jedem Nutzer, eine zentrale Bereitstellung von Favoriten ist nicht vorgesehen.<br /> :In InfoTicket handelt es sich bei den Favoriten um ausgewählte Weiterleitungsempfänger, die im Weiterleitungsdialog gesondert zur Auswahl angeboten werden.<br /> :Die Verwaltung der Favoriten erfolgt in InfoTicket innerhalb des Weiterleiten-Dialoges. Favoriten werden in Gruppen verwaltet, von denen folgende vorgesehen sind:<br /> :*Historie&lt;br&gt;Liste der zuletzt verwendeten Weiterleitungsempfänger, chronologisch sortiert<br /> :*Häufig genutzt&lt;br&gt;Liste der Weiterleitungsempfänger an die am häufigsten ein Ticket weitergeleitet wurde, sortiert nach Häufigkeit<br /> :*Lesezeichen&lt;br&gt;individuell pflegbare Liste von Weiterleitungsempfängern, alphabetisch sortiert nach Nachnahme. Hinzugefügt werden Empfänger, indem sie im Weiterleitungs-Dialog markiert werden. Gelöscht werden sie über die löschen-Funktion (rechte Maustaste bzw. Auswahl und &quot;Entf&quot;-Taste).<br /> :*Suchergebnisse&lt;br&gt;Beliebig viele Listen, deren Inhalt das Ergebnis eine Suche ist, alphabetisch dortiert nach nachnahme. Hinzugefügt werden Suchergebnisse über die Suchen-Funktion im Weiterleiten-Dialog. Einzelne Empfänger können nicht aus dem Suchergebnis entfernt werden. Listen können umbenannt und über die löschen-Funktion entfernt werden.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Drag and Drop für Weiterleitungen über die rechte Spalte&lt;/span&gt;<br /> :In der Übersichtsseite wird in die rechte Spalte eine Schnell-Weiterleiten-Funktion eingebaut über die aus der Liste von Tickets ein oder mehrere Tickets per Drag and Drop an einen Empfänger weitergeleitet werden können. Über einen Popup-Dialog kann der Weiterleitung eine Notiz hinzugefügt werden. Bei Mehrfach-Weiterleitungen erhalten alle Tickets die gleiche Notiz.<br /> :Die aufgelisteten Weiterleitungs-Empfänger sind Nutzer einer in der Box auswählbaren Favoritengruppe<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;erweiterter Weiterleiten-Auswahl-Dialog&lt;/span&gt;<br /> :Der Standard-Auswahldialog wird erweitert um:<br /> :*Suchfunktion<br /> :*Favoritenliste<br /> :*verschiedene Ansichten<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Textvorlagen auswählen , erstellen, löschen&lt;/span&gt;<br /> :Textvorlagen werden in der rechten Spalte der Ticket-Detaildarstellung angeboten.<br /> :Über einen Dialog mit WYSIWYG-Editor kann eine Textvorlage erstellt oder bearbeitet werden.<br /> :Textvorlagen lassen sich über die rechte Maustaste und Auswahldialog löschen oder bearbeiten.<br /> :Textvorlagen werden per Doppelklick an die aktive Cursorposition des Notiz-Feldes eingefügt.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Datenschutz&lt;/span&gt;<br /> :Erweiterung der Funktion nach der Personendatensätze gelöscht werden, wenn kein offenes Ticket mehr auf einen Datensatz verweist um einen konfigurierbaren zeitlichen Versatz. (Kontakte werden z.B. erst 3 Monate nachdem das letzte Ticket geschlossen wird, gelöscht.)<br /> <br /> ==Milestone 12 - Oktober 2011 ==<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;Unvollständig-Funktion&lt;/span&gt;<br /> :Die Unvollständig-Funktion soll über das Ticketing-System abgedeckt werden.<br /> :*Unvollständigkeitsmeldung als Ticket verfassen.<br /> :*Den Button &quot;Unvollständig&quot; auf der rechten Seite in der Oberfläche von CityCall115 entfernen, wenn ein Unvollständig-Ticket erstellt werden kann.<br /> <br /> ;&lt;span style=&quot;color:green&quot;&gt;CityCall115&lt;/span&gt;<br /> :Der Betreff eines Tickets kann beim Anlegen durch den Agenten optional um Zusatzinformationen ergänzt werden.<br /> :Funktion zur Ticket-Recherche und zum Anfügen von Notizen für Agenten.<br /> <br /> ;&lt;span style=&quot;color:red&quot;&gt;Anpassung von Eskalationszeiten nach Ticketstatusänderung&lt;/span&gt;<br /> <br /> ==Milestone 13 - November 2011 ==<br /> <br /> ;Code Review / Code Optimierung<br /> : Umstellung auf ExtJS 4<br /> <br /> ;Agenten (Absender des Tickets)<br /> :Alle Agenten müssen in das InfoTicket-System synchronisiert werden.<br /> <br /> ;Statistik über Tickets<br /> :Statistik-Angaben<br /> :*Anzahl an eskalierten Tickets in einem Zeitraum.<br /> :*Anzahl an aktiven Nutzern<br /> :*Anzahl an inaktiven Nutzern (keine Ticketbearbeitung innerhalb der letzten paar Monate)<br /> :*Anzahl an registrierten Nutzern<br /> :*Anzahl an Bürgerdatensätzen<br /> :*Längste Ticketbearbeitungsdauer<br /> :*Kürzeste Ticketbearbeitungsdauer<br /> :*Durchschnittliche Ticketbearbeitungsdauer<br /> :*Anzahl offener Tickets<br /> :*Anzahl eskalierter Tickets<br /> :*Anzahl der Tickets pro zugeordneter Diensleistung/Organisationseinheit innerhalb eines wählbaren Zeitraums.<br /> <br /> ;Statistik im Ticket<br /> :kurze Statistik-Angaben zum Ticket in der rechten Spalte<br /> :*Anzahl an Eskalationen<br /> :*Anzahl an Weiterleitungen<br /> <br /> ==Milestone 14==<br /> <br /> ;Ticket-id soll ohne Typ und Mandanten-Kennung verwendet werden<br /> :Suchabfrage muss diese ID schon so zurückliefern (oder per JavaScript beschneiden)<br /> :Alle RPC-Funktionen des TicketSystems müssen die ID in dem neuen Format lesen können und auch so zurück liefern.<br /> <br /> ;Mail-Gateway<br /> :Mailversand:<br /> :*Als Antwort<br /> :*Als Weiterleitung an Extern<br /> :*Konfigurationsmöglichkeit für einen zentralen Footer, der durch Variablen Nutzerdaten einfügen kann (Name, Vorname, Abteilung, …)<br /> <br /> :Mailempfang:<br /> :*E-Mail als Ticket (siehe altes Dokument)<br /> :*E-Mail als externe Nachricht am Ticket<br /> :*E-Mail als Antwort für Weiterleitung an Extern<br /> <br /> ;Integration der D115 Meldungstypen (Empfang und Bearbeitung)<br /> <br /> ==Milestone 15==<br /> <br /> ;Formular-Service<br /> :Erstellung von Benachrichtigung über einen Dienst, der die Formulardaten auswertet und pdf und/oder xml Dateien erstellt und je nach Konfiguration eine Mail oder ein Ticket erstellt.<br /> <br /> ;GUI Nutzerverwaltung / Rechtevergabe<br /> :Neues GUI, als Prototyp für eine Applikation auf Basis der IES Nutzerverwaltung. Die technischen Möglichkeiten des IES / InfoSite bleiben bis auf die obige Erweiterung erhalten und werden durch das neue GUI bedient. Ggf. sind Erweiterungen nötig!?<br /> :Die Nutzerliste im Nutzerpool enthält direkte Hinweise auf die zugewiesenen Rollen des einzelnen Nutzers.<br /> <br /> ==Milestone X==<br /> <br /> ;Subtickets<br /> <br /> ;Workflow:<br /> ;:Tickets können durch ihre Definition eine Abfolge von Nutzer(-gruppen) enthalten, die durch eine „Weiter“ und „Zurück“ Navigation durchlaufen werden.<br /> <br /> ;erweiterte Suchfunktion<br /> :muss noch definiert werden<br /> <br /> <br /> &lt;noinclude&gt;<br /> [[Kategorie:Partner]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=GVP_-_Roadmap&diff=5598 2011-07-28T14:10:29Z

<p>Liebold: /* Milestone 1 - bis Ende September 2011 */</p> <hr /> <div>Ziel des GVP-Moduls ist es alle nötigen Daten zur Erstellung eines Geschäftsverteilungsplans zu erfassen und zu verwalten. Die Ausgabe der Daten erfolgt als strukturierte XML-Daten und ggf. auch als in sich geschlossene HTML-Ausgabe (Mini-Website) für die Nutzung zu Recherchezwecken per Web-Browser. Dabei greift das Modul auf bestehende interne und externe Strukturen aus dem Basisprodukt CityGov zurück. Ergänzend sind weitere Funktionen denkbar, die auch auf den in CityGov und anderen Produkten und Modulen genutzten Datenbestand zurückwirken können.<br /> <br /> Neben der Wiedergabe eines aktuellen Datenbestandes kennt das Modul drei grundlegend eigenständig behandelte Datenstände. Dies ermöglicht es der Anforderung nach einem aktuell gültigen Stand (genehmigt), einem aktuell existierenden Zustand (gelebt) und einem oder mehreren Planungsständen innerhalb eines Systems nachzukommen.<br /> <br /> <br /> == Milestone 1 - bis Ende September 2011 ==<br /> <br /> * Benutzeroberfläche zur Erstellung, Bearbeitung und Visualisierung von Geschäftsverteilungsplänen<br /> ** In diesem Milestone sollen nur die Grund-Funktionalitäten enthalten sein. Erzeugen von Reports, Export der Stände nach CityGov, usw. sind hier noch nicht enthalten. Mit diesem Stand soll überprüft werden, ob die Art der Applikation den Anforderungen entspricht. <br /> <br /> * Funktionsumfang <br /> ** der &quot;gelebte&quot; Stand muss nicht angelegt werden, er ist immer verfügbar (wenn Rechte vorhanden) und spiegelt den aktuellen Stand in CityGov wieder. Dieser Stand ist nur begrenzt über das GVP-Modul editierbar (solange CityGov nicht das datenführende System ist).<br /> *** Nur Aufgabenbereiche können editiert werden.<br /> *** Die Struktur des gelebten Standes kann nicht geändert werden.<br /> *** Die Stammdaten wie Name, Beschreibung, Adressdaten, etc., die bereits in CityGov existieren können nicht geändert werden.<br /> *** Neue Organisationseinheiten können nicht angelegt werden.<br /> *** Organisationseinheiten können nicht gelöscht werden.<br /> ** Aus dem &quot;gelebten&quot; Stand kann ein &quot;genehmigter&quot; Stand erzeugt werden. Dieser Stand kann nicht mehr geändert werden.<br /> ** Neue Stände können durch kopieren eines existierenden Standes neu angelegt werden. <br /> ** In einem angelegtem Stand können Organisationseinheiten über die Baumansicht angelegt, verschoben und gelöscht werden (Drag&amp;amp;Drop und Context-Menü) <br /> ** Eine in der Baumansicht ausgewählte Organisationseinheit kann über den 'Blatt'-Reiter angesehen werden.<br /> *** Über den Blatt-Reiter wird die Organisationseinheit mit den eingetragenen Daten dargestellt. Die Ansicht entspricht der Darstellung so wie sie später auch exportiert werden soll.<br /> ** Eine in der Baumansicht ausgewählte Organisationseinheit kann über den 'Bearbeitung'-Reiter bearbeitet werden. (Stammdaten, Aufgabenbereiche)<br /> ** Die Daten aller Stände werden im Reporitory des Sitepark IES abgespeichert.<br /> <br /> ==Milestone 2 - bis Ende Oktober 2011 (abhängig vom Ergebnis der Auswertung)==<br /> *;Feedback-Auswertung des Saarlandes - Erweiterung der Funktionalität<br /> <br /> :Zusammen mit dem Saarland soll überprüft werden:<br /> :- welche Anforderungen noch fehlen und welche Funktionen überflüssig oder geändert werden müssen.<br /> :- Usability der Applikation überprüfen und anpassen<br /> :- Design anpassen<br /> <br /> ==Milestone 3 - bis Mitte November 2011==<br /> *;Export von Geschäftsverteilungsplänen als XML-Daten<br /> <br /> ==Milestone 4==<br /> *;Export von Geschäftsverteilungsplänen als in sich geschlossene HTML-Site<br /> <br /> :Hier ist zu prüfen, ob dies wirklich notwendig ist, da über die Benutzeroberfläche des GVP-Moduls diese Ausgabe im Prinzip schon existiert.<br /> <br /> ==Milestone 5==<br /> *;Export von Geschäftsverteilungsplänen als PDF-Dokument<br /> <br /> ==Milestone 6==<br /> *;Überführung eines Geschäftsverteilungsplans nach CityGov.<br /> <br /> *;Stände finalisieren und archivieren.<br /> <br /> :Die Organisationsstruktur von CityGov im Saarland wird über den Z-Finder Import bestimmt. Die Überführung eines Geschäftsverteilungsplans nach CityGov macht nur Sinn, wenn CityGov für die Struktur das führende System ist. Diese würde bedeuten, das zunächst ein Z-Finder Export implementiert werden muss, der den Import ablöst.<br /> :Organisationseinheiten werden auch aus dem LDAP-System und ACUSTIG in CityGov importiert. Dies wäre dann auch nicht mehr möglich.<br /> :Wenn weiterhin Daten aus F-Finder, LDAP und ACUSTIG importiert werden sollen (Mitarbeiter und Produkte) muss überlegt werden, wie das dann realisiert werden soll (Behörden-Schlüssel).<br /> <br /> ==Milestone 7==<br /> *;Bearbeitung der Stammdaten und Aufgabenbereiche innerhalb von CityGov für den gelebten Stand.<br /> <br /> &lt;noinclude&gt;<br /> [[Kategorie:Partner]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=GVP_-_Roadmap&diff=5597 2011-07-28T14:09:12Z

<p>Liebold: /* Milestone 1 - bis Ende September 2011 */</p> <hr /> <div>Ziel des GVP-Moduls ist es alle nötigen Daten zur Erstellung eines Geschäftsverteilungsplans zu erfassen und zu verwalten. Die Ausgabe der Daten erfolgt als strukturierte XML-Daten und ggf. auch als in sich geschlossene HTML-Ausgabe (Mini-Website) für die Nutzung zu Recherchezwecken per Web-Browser. Dabei greift das Modul auf bestehende interne und externe Strukturen aus dem Basisprodukt CityGov zurück. Ergänzend sind weitere Funktionen denkbar, die auch auf den in CityGov und anderen Produkten und Modulen genutzten Datenbestand zurückwirken können.<br /> <br /> Neben der Wiedergabe eines aktuellen Datenbestandes kennt das Modul drei grundlegend eigenständig behandelte Datenstände. Dies ermöglicht es der Anforderung nach einem aktuell gültigen Stand (genehmigt), einem aktuell existierenden Zustand (gelebt) und einem oder mehreren Planungsständen innerhalb eines Systems nachzukommen.<br /> <br /> <br /> == Milestone 1 - bis Ende September 2011 ==<br /> <br /> * Benutzeroberfläche zur Erstellung, Bearbeitung und Visualisierung von Geschäftsverteilungsplänen<br /> ** In diesem Milestone sollen nur die Grund-Funktionalitäten enthalten sein. Erzeugen von Reports, Export der Stände nach CityGov, usw. sind hier noch nicht enthalten. Mit diesem Stand soll überprüft werden, ob die Art der Applikation den Anforderungen entspricht. <br /> <br /> * Funktionsumfang <br /> ** der &quot;gelebte&quot; Stand muss nicht angelegt werden, er ist immer verfügbar (wenn Rechte vorhanden) und spiegelt den aktuellen Stand in CityGov wieder. Dieser Stand ist nur begrenzt über das GVP-Modul editierbar (solange CityGov nicht das datenführende System ist).<br /> *** Nur Aufgabenbereiche können editiert werden.<br /> *** Die Struktur des gelebten Standes kann nicht geändert werden.<br /> *** Die Stammdaten wie Name, Beschreibung, Adressdaten, ... die bereits in CityGov existieren können nicht geändert werden.<br /> *** Neue Organisationseinheiten können nicht angelegt werden.<br /> *** Organisationseinheiten können nicht gelöscht werden.<br /> ** Aus dem &quot;gelebten&quot; Stand kann ein &quot;genehmigter&quot; Stand erzeugt werden. Dieser Stand kann nicht mehr geändert werden.<br /> ** Neue Stände können durch kopieren eines existierenden Standes neu angelegt werden. <br /> ** In einem angelegtem Stand können Organisationseinheiten über die Baumansicht angelegt, verschoben und gelöscht werden (Drag&amp;amp;Drop und Context-Menü) <br /> ** Eine in der Baumansicht ausgewählte Organisationseinheit kann über den 'Blatt'-Reiter angesehen werden.<br /> *** Über den Blatt-Reiter wird die Organisationseinheit mit den eingetragenen Daten dargestellt. Die Ansicht entspricht der Darstellung so wie sie später auch exportiert werden soll.<br /> ** Eine in der Baumansicht ausgewählte Organisationseinheit kann über den 'Bearbeitung'-Reiter bearbeitet werden. (Stammdaten, Aufgabenbereiche)<br /> ** Die Daten aller Stände werden im Reporitory des Sitepark IES abgespeichert.<br /> <br /> ==Milestone 2 - bis Ende Oktober 2011 (abhängig vom Ergebnis der Auswertung)==<br /> *;Feedback-Auswertung des Saarlandes - Erweiterung der Funktionalität<br /> <br /> :Zusammen mit dem Saarland soll überprüft werden:<br /> :- welche Anforderungen noch fehlen und welche Funktionen überflüssig oder geändert werden müssen.<br /> :- Usability der Applikation überprüfen und anpassen<br /> :- Design anpassen<br /> <br /> ==Milestone 3 - bis Mitte November 2011==<br /> *;Export von Geschäftsverteilungsplänen als XML-Daten<br /> <br /> ==Milestone 4==<br /> *;Export von Geschäftsverteilungsplänen als in sich geschlossene HTML-Site<br /> <br /> :Hier ist zu prüfen, ob dies wirklich notwendig ist, da über die Benutzeroberfläche des GVP-Moduls diese Ausgabe im Prinzip schon existiert.<br /> <br /> ==Milestone 5==<br /> *;Export von Geschäftsverteilungsplänen als PDF-Dokument<br /> <br /> ==Milestone 6==<br /> *;Überführung eines Geschäftsverteilungsplans nach CityGov.<br /> <br /> *;Stände finalisieren und archivieren.<br /> <br /> :Die Organisationsstruktur von CityGov im Saarland wird über den Z-Finder Import bestimmt. Die Überführung eines Geschäftsverteilungsplans nach CityGov macht nur Sinn, wenn CityGov für die Struktur das führende System ist. Diese würde bedeuten, das zunächst ein Z-Finder Export implementiert werden muss, der den Import ablöst.<br /> :Organisationseinheiten werden auch aus dem LDAP-System und ACUSTIG in CityGov importiert. Dies wäre dann auch nicht mehr möglich.<br /> :Wenn weiterhin Daten aus F-Finder, LDAP und ACUSTIG importiert werden sollen (Mitarbeiter und Produkte) muss überlegt werden, wie das dann realisiert werden soll (Behörden-Schlüssel).<br /> <br /> ==Milestone 7==<br /> *;Bearbeitung der Stammdaten und Aufgabenbereiche innerhalb von CityGov für den gelebten Stand.<br /> <br /> &lt;noinclude&gt;<br /> [[Kategorie:Partner]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=GVP_-_Roadmap&diff=5592 2011-07-27T10:04:33Z

<p>Liebold: /* Milestone 7 */</p> <hr /> <div>Ziel des GVP-Moduls ist es alle nötigen Daten zur Erstellung eines Geschäftsverteilungsplans zu erfassen und zu verwalten. Die Ausgabe der Daten erfolgt als strukturierte XML-Daten und ggf. auch als in sich geschlossene HTML-Ausgabe (Mini-Website) für die Nutzung zu Recherchezwecken per Web-Browser. Dabei greift das Modul auf bestehende interne und externe Strukturen aus dem Basisprodukt CityGov zurück. Ergänzend sind weitere Funktionen denkbar, die auch auf den in CityGov und anderen Produkten und Modulen genutzten Datenbestand zurückwirken können.<br /> <br /> Neben der Wiedergabe eines aktuellen Datenbestandes kennt das Modul drei grundlegend eigenständig behandelte Datenstände. Dies ermöglicht es der Anforderung nach einem aktuell gültigen Stand (genehmigt), einem aktuell existierenden Zustand (gelebt) und einem oder mehreren Planungsständen innerhalb eines Systems nachzukommen.<br /> <br /> <br /> == Milestone 1 - bis Ende September 2011 ==<br /> <br /> *;Benutzeroberfläche zur Erstellung, Bearbeitung und Visualisierung von Geschäftsverteilungsplänen<br /> :In diesem Milestone sollen nur die Grund-Funktionalitäten enthalten sein. Erzeugen von Reports, Export der Stände nach CityGov, usw. sind hier noch nicht enthalten. Mit diesem Stand soll überprüft werden, ob die Art der Applikation den Anforderungen entspricht. <br /> <br /> *;Funktionsumfang <br /> :- der &quot;gelebte&quot; Stand muss nicht angelegt werden, er ist immer verfügbar (wenn Rechte vorhanden) und spiegelt den aktuellen Stand in CityGov wieder. Dieser Stand ist nicht über das GVP-Modul editierbar. <br /> :- Neue Stände können durch kopieren eines existierenden Standes neu angelegt werden. <br /> :- In einem angelegtem Stand können Organisationseinheiten über die Baumansicht angelegt, verschoben und gelöscht werden (Drag&amp;amp;Drop und Context-Menü) <br /> :- Eine in der Baumansicht ausgewählte Organisationseinheit kann über den 'Blatt'-Tab angesehen werden. <br /> :- Eine in der Baumansicht ausgewählte Organisationseinheit kann über den 'Bearbeitung'-Tab bearbeitet werden. (Stammdaten, Aufgabenbereiche)<br /> <br /> ==Milestone 2 - bis Ende Oktober 2011 (abhängig vom Ergebnis der Auswertung)==<br /> *;Feedback-Auswertung des Saarlandes - Erweiterung der Funktionalität<br /> <br /> :Zusammen mit dem Saarland soll überprüft werden:<br /> :- welche Anforderungen noch fehlen und welche Funktionen überflüssig oder geändert werden müssen.<br /> :- Usability der Applikation überprüfen und anpassen<br /> :- Design anpassen<br /> <br /> ==Milestone 3 - bis Mitte November 2011==<br /> *;Export von Geschäftsverteilungsplänen als XML-Daten<br /> <br /> ==Milestone 4==<br /> *;Export von Geschäftsverteilungsplänen als in sich geschlossene HTML-Site<br /> <br /> :Hier ist zu prüfen, ob dies wirklich notwendig ist, da über die Benutzeroberfläche des GVP-Moduls diese Ausgabe im Prinzip schon existiert.<br /> <br /> ==Milestone 5==<br /> *;Export von Geschäftsverteilungsplänen als PDF-Dokument<br /> <br /> ==Milestone 6==<br /> *;Überführung eines Geschäftsverteilungsplans nach CityGov.<br /> <br /> *;Stände finalisieren und archivieren.<br /> <br /> :Die Organisationsstruktur von CityGov im Saarland wird über den Z-Finder Import bestimmt. Die Überführung eines Geschäftsverteilungsplans nach CityGov macht nur Sinn, wenn CityGov für die Struktur das führende System ist. Diese würde bedeuten, das zunächst ein Z-Finder Export implementiert werden muss, der den Import ablöst.<br /> :Organisationseinheiten werden auch aus dem LDAP-System und ACUSTIG in CityGov importiert. Dies wäre dann auch nicht mehr möglich.<br /> :Wenn weiterhin Daten aus F-Finder, LDAP und ACUSTIG importiert werden sollen (Mitarbeiter und Produkte) muss überlegt werden, wie das dann realisiert werden soll (Behörden-Schlüssel).<br /> <br /> ==Milestone 7==<br /> *;Bearbeitung der Stammdaten und Aufgabenbereiche innerhalb von CityGov für den gelebten Stand.<br /> <br /> &lt;noinclude&gt;<br /> [[Kategorie:Partner]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=GVP_-_Roadmap&diff=5591 2011-07-27T10:03:23Z

<p>Liebold: /* Milestone 1 - bis Ende September 2011 */</p> <hr /> <div>Ziel des GVP-Moduls ist es alle nötigen Daten zur Erstellung eines Geschäftsverteilungsplans zu erfassen und zu verwalten. Die Ausgabe der Daten erfolgt als strukturierte XML-Daten und ggf. auch als in sich geschlossene HTML-Ausgabe (Mini-Website) für die Nutzung zu Recherchezwecken per Web-Browser. Dabei greift das Modul auf bestehende interne und externe Strukturen aus dem Basisprodukt CityGov zurück. Ergänzend sind weitere Funktionen denkbar, die auch auf den in CityGov und anderen Produkten und Modulen genutzten Datenbestand zurückwirken können.<br /> <br /> Neben der Wiedergabe eines aktuellen Datenbestandes kennt das Modul drei grundlegend eigenständig behandelte Datenstände. Dies ermöglicht es der Anforderung nach einem aktuell gültigen Stand (genehmigt), einem aktuell existierenden Zustand (gelebt) und einem oder mehreren Planungsständen innerhalb eines Systems nachzukommen.<br /> <br /> <br /> == Milestone 1 - bis Ende September 2011 ==<br /> <br /> *;Benutzeroberfläche zur Erstellung, Bearbeitung und Visualisierung von Geschäftsverteilungsplänen<br /> :In diesem Milestone sollen nur die Grund-Funktionalitäten enthalten sein. Erzeugen von Reports, Export der Stände nach CityGov, usw. sind hier noch nicht enthalten. Mit diesem Stand soll überprüft werden, ob die Art der Applikation den Anforderungen entspricht. <br /> <br /> *;Funktionsumfang <br /> :- der &quot;gelebte&quot; Stand muss nicht angelegt werden, er ist immer verfügbar (wenn Rechte vorhanden) und spiegelt den aktuellen Stand in CityGov wieder. Dieser Stand ist nicht über das GVP-Modul editierbar. <br /> :- Neue Stände können durch kopieren eines existierenden Standes neu angelegt werden. <br /> :- In einem angelegtem Stand können Organisationseinheiten über die Baumansicht angelegt, verschoben und gelöscht werden (Drag&amp;amp;Drop und Context-Menü) <br /> :- Eine in der Baumansicht ausgewählte Organisationseinheit kann über den 'Blatt'-Tab angesehen werden. <br /> :- Eine in der Baumansicht ausgewählte Organisationseinheit kann über den 'Bearbeitung'-Tab bearbeitet werden. (Stammdaten, Aufgabenbereiche)<br /> <br /> ==Milestone 2 - bis Ende Oktober 2011 (abhängig vom Ergebnis der Auswertung)==<br /> *;Feedback-Auswertung des Saarlandes - Erweiterung der Funktionalität<br /> <br /> :Zusammen mit dem Saarland soll überprüft werden:<br /> :- welche Anforderungen noch fehlen und welche Funktionen überflüssig oder geändert werden müssen.<br /> :- Usability der Applikation überprüfen und anpassen<br /> :- Design anpassen<br /> <br /> ==Milestone 3 - bis Mitte November 2011==<br /> *;Export von Geschäftsverteilungsplänen als XML-Daten<br /> <br /> ==Milestone 4==<br /> *;Export von Geschäftsverteilungsplänen als in sich geschlossene HTML-Site<br /> <br /> :Hier ist zu prüfen, ob dies wirklich notwendig ist, da über die Benutzeroberfläche des GVP-Moduls diese Ausgabe im Prinzip schon existiert.<br /> <br /> ==Milestone 5==<br /> *;Export von Geschäftsverteilungsplänen als PDF-Dokument<br /> <br /> ==Milestone 6==<br /> *;Überführung eines Geschäftsverteilungsplans nach CityGov.<br /> <br /> *;Stände finalisieren und archivieren.<br /> <br /> :Die Organisationsstruktur von CityGov im Saarland wird über den Z-Finder Import bestimmt. Die Überführung eines Geschäftsverteilungsplans nach CityGov macht nur Sinn, wenn CityGov für die Struktur das führende System ist. Diese würde bedeuten, das zunächst ein Z-Finder Export implementiert werden muss, der den Import ablöst.<br /> :Organisationseinheiten werden auch aus dem LDAP-System und ACUSTIG in CityGov importiert. Dies wäre dann auch nicht mehr möglich.<br /> :Wenn weiterhin Daten aus F-Finder, LDAP und ACUSTIG importiert werden sollen (Mitarbeiter und Produkte) muss überlegt werden, wie das dann realisiert werden soll (Behörden-Schlüssel).<br /> <br /> ==Milestone 7==<br /> *;Bearbeitung der Stammdaten und Aufgabenbereiche innerhalb von CityGov für den gelebten Stand<br /> <br /> &lt;noinclude&gt;<br /> [[Kategorie:Partner]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=GVP_-_Roadmap&diff=5590 2011-07-27T09:50:53Z

<p>Liebold: /* Milestone 6 */</p> <hr /> <div>== Milestone 1 - bis Ende September 2011 ==<br /> <br /> *;Benutzeroberfläche zur Erstellung, Bearbeitung und Visualisierung von Geschäftsverteilungsplänen<br /> :In diesem Milestone sollen nur die Grund-Funktionalitäten enthalten sein. Erzeugen von Reports, Export der Stände nach CityGov, usw. sind hier noch nicht enthalten. Mit diesem Stand soll überprüft werden, ob die Art der Applikation den Anforderungen entspricht. <br /> <br /> *;Funktionsumfang <br /> :- der &quot;gelebte&quot; Stand muss nicht angelegt werden, er ist immer verfügbar (wenn Rechte vorhanden) und spiegelt den aktuellen Stand in CityGov wieder. Dieser Stand ist nicht über das GVP-Modul editierbar. <br /> :- Neue Stände können durch kopieren eines existierenden Standes neu angelegt werden. <br /> :- In einem angelegtem Stand können Organisationseinheiten über die Baumansicht angelegt, verschoben und gelöscht werden (Drag&amp;amp;Drop und Context-Menü) <br /> :- Eine in der Baumansicht ausgewählte Organisationseinheit kann über den 'Blatt'-Tab angesehen werden. <br /> :- Eine in der Baumansicht ausgewählte Organisationseinheit kann über den 'Bearbeitung'-Tab bearbeitet werden. (Stammdaten, Aufgabenbereiche)<br /> <br /> ==Milestone 2 - bis Ende Oktober 2011 (abhängig vom Ergebnis der Auswertung)==<br /> *;Feedback-Auswertung des Saarlandes - Erweiterung der Funktionalität<br /> <br /> :Zusammen mit dem Saarland soll überprüft werden:<br /> :- welche Anforderungen noch fehlen und welche Funktionen überflüssig oder geändert werden müssen.<br /> :- Usability der Applikation überprüfen und anpassen<br /> :- Design anpassen<br /> <br /> ==Milestone 3 - bis Mitte November 2011==<br /> *;Export von Geschäftsverteilungsplänen als XML-Daten<br /> <br /> ==Milestone 4==<br /> *;Export von Geschäftsverteilungsplänen als in sich geschlossene HTML-Site<br /> <br /> :Hier ist zu prüfen, ob dies wirklich notwendig ist, da über die Benutzeroberfläche des GVP-Moduls diese Ausgabe im Prinzip schon existiert.<br /> <br /> ==Milestone 5==<br /> *;Export von Geschäftsverteilungsplänen als PDF-Dokument<br /> <br /> ==Milestone 6==<br /> *;Überführung eines Geschäftsverteilungsplans nach CityGov.<br /> <br /> *;Stände finalisieren und archivieren.<br /> <br /> :Die Organisationsstruktur von CityGov im Saarland wird über den Z-Finder Import bestimmt. Die Überführung eines Geschäftsverteilungsplans nach CityGov macht nur Sinn, wenn CityGov für die Struktur das führende System ist. Diese würde bedeuten, das zunächst ein Z-Finder Export implementiert werden muss, der den Import ablöst.<br /> :Organisationseinheiten werden auch aus dem LDAP-System und ACUSTIG in CityGov importiert. Dies wäre dann auch nicht mehr möglich.<br /> :Wenn weiterhin Daten aus F-Finder, LDAP und ACUSTIG importiert werden sollen (Mitarbeiter und Produkte) muss überlegt werden, wie das dann realisiert werden soll (Behörden-Schlüssel).<br /> <br /> ==Milestone 7==<br /> *;Bearbeitung der Stammdaten und Aufgabenbereiche innerhalb von CityGov für den gelebten Stand<br /> <br /> &lt;noinclude&gt;<br /> [[Kategorie:Partner]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=GVP_-_Roadmap&diff=5589 2011-07-27T09:29:13Z

<p>Liebold: /* Milestone 2 - bis Ende Oktober 2011 (Abhängig vom Ergebnis der Auswertung) */</p> <hr /> <div>== Milestone 1 - bis Ende September 2011 ==<br /> <br /> *;Benutzeroberfläche zur Erstellung, Bearbeitung und Visualisierung von Geschäftsverteilungsplänen<br /> :In diesem Milestone sollen nur die Grund-Funktionalitäten enthalten sein. Erzeugen von Reports, Export der Stände nach CityGov, usw. sind hier noch nicht enthalten. Mit diesem Stand soll überprüft werden, ob die Art der Applikation den Anforderungen entspricht. <br /> <br /> *;Funktionsumfang <br /> :- der &quot;gelebte&quot; Stand muss nicht angelegt werden, er ist immer verfügbar (wenn Rechte vorhanden) und spiegelt den aktuellen Stand in CityGov wieder. Dieser Stand ist nicht über das GVP-Modul editierbar. <br /> :- Neue Stände können durch kopieren eines existierenden Standes neu angelegt werden. <br /> :- In einem angelegtem Stand können Organisationseinheiten über die Baumansicht angelegt, verschoben und gelöscht werden (Drag&amp;amp;Drop und Context-Menü) <br /> :- Eine in der Baumansicht ausgewählte Organisationseinheit kann über den 'Blatt'-Tab angesehen werden. <br /> :- Eine in der Baumansicht ausgewählte Organisationseinheit kann über den 'Bearbeitung'-Tab bearbeitet werden. (Stammdaten, Aufgabenbereiche)<br /> <br /> ==Milestone 2 - bis Ende Oktober 2011 (abhängig vom Ergebnis der Auswertung)==<br /> *;Feedback-Auswertung des Saarlandes - Erweiterung der Funktionalität<br /> <br /> :Zusammen mit dem Saarland soll überprüft werden:<br /> :- welche Anforderungen noch fehlen und welche Funktionen überflüssig oder geändert werden müssen.<br /> :- Usability der Applikation überprüfen und anpassen<br /> :- Design anpassen<br /> <br /> ==Milestone 3 - bis Mitte November 2011==<br /> *;Export von Geschäftsverteilungsplänen als XML-Daten<br /> <br /> ==Milestone 4==<br /> *;Export von Geschäftsverteilungsplänen als in sich geschlossene HTML-Site<br /> <br /> :Hier ist zu prüfen, ob dies wirklich notwendig ist, da über die Benutzeroberfläche des GVP-Moduls diese Ausgabe im Prinzip schon existiert.<br /> <br /> ==Milestone 5==<br /> *;Export von Geschäftsverteilungsplänen als PDF-Dokument<br /> <br /> ==Milestone 6==<br /> *;Überführung eines Geschäftsverteilungsplans nach CityGov.<br /> <br /> *;Stände finalisieren und archivieren.<br /> <br /> :Die Organisationsstruktur von CityGov im Saarland wird über den Z-Finder Import bestimmt. Die Überführung eines Geschäftsverteilungsplans nach CityGov macht nur Sinn, wenn CityGov für die Struktur das führende System ist. Diese würde bedeuten, das zunächst ein Z-Finder Export implementiert werden muss, der den Import ablöst.<br /> :Organisationseinheiten werden auch aus dem LDAP-System und ACUSTIG in CityGov importiert. Dies wäre dann auch nicht mehr möglich.<br /> :Wenn weiterhin Daten aus F-Finder, LDAP und ACUSTIG importiert werden sollen (Mitarbeiter und Produkte) muss überlegt werden wie das dann realisiert werden soll (Behörden-Schlüssel).<br /> <br /> ==Milestone 7==<br /> *;Bearbeitung der Stammdaten und Aufgabenbereiche innerhalb von CityGov für den gelebten Stand<br /> <br /> &lt;noinclude&gt;<br /> [[Kategorie:Partner]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=GVP_-_Roadmap&diff=5588 2011-07-27T09:28:43Z

<p>Liebold: /* Milestone 7 */</p> <hr /> <div>== Milestone 1 - bis Ende September 2011 ==<br /> <br /> *;Benutzeroberfläche zur Erstellung, Bearbeitung und Visualisierung von Geschäftsverteilungsplänen<br /> :In diesem Milestone sollen nur die Grund-Funktionalitäten enthalten sein. Erzeugen von Reports, Export der Stände nach CityGov, usw. sind hier noch nicht enthalten. Mit diesem Stand soll überprüft werden, ob die Art der Applikation den Anforderungen entspricht. <br /> <br /> *;Funktionsumfang <br /> :- der &quot;gelebte&quot; Stand muss nicht angelegt werden, er ist immer verfügbar (wenn Rechte vorhanden) und spiegelt den aktuellen Stand in CityGov wieder. Dieser Stand ist nicht über das GVP-Modul editierbar. <br /> :- Neue Stände können durch kopieren eines existierenden Standes neu angelegt werden. <br /> :- In einem angelegtem Stand können Organisationseinheiten über die Baumansicht angelegt, verschoben und gelöscht werden (Drag&amp;amp;Drop und Context-Menü) <br /> :- Eine in der Baumansicht ausgewählte Organisationseinheit kann über den 'Blatt'-Tab angesehen werden. <br /> :- Eine in der Baumansicht ausgewählte Organisationseinheit kann über den 'Bearbeitung'-Tab bearbeitet werden. (Stammdaten, Aufgabenbereiche)<br /> <br /> ==Milestone 2 - bis Ende Oktober 2011 (Abhängig vom Ergebnis der Auswertung)==<br /> *;Feedback-Auswertung des Saarlandes - Erweiterung der Funktionalität<br /> <br /> :Zusammen mit dem Saarland soll überprüft werden:<br /> :- welche Anforderungen noch fehlen und welche Funktionen überflüssig oder geändert werden müssen.<br /> :- Usability der Applikation überprüfen und anpassen<br /> :- Design anpassen<br /> <br /> ==Milestone 3 - bis Mitte November 2011==<br /> *;Export von Geschäftsverteilungsplänen als XML-Daten<br /> <br /> ==Milestone 4==<br /> *;Export von Geschäftsverteilungsplänen als in sich geschlossene HTML-Site<br /> <br /> :Hier ist zu prüfen, ob dies wirklich notwendig ist, da über die Benutzeroberfläche des GVP-Moduls diese Ausgabe im Prinzip schon existiert.<br /> <br /> ==Milestone 5==<br /> *;Export von Geschäftsverteilungsplänen als PDF-Dokument<br /> <br /> ==Milestone 6==<br /> *;Überführung eines Geschäftsverteilungsplans nach CityGov.<br /> <br /> *;Stände finalisieren und archivieren.<br /> <br /> :Die Organisationsstruktur von CityGov im Saarland wird über den Z-Finder Import bestimmt. Die Überführung eines Geschäftsverteilungsplans nach CityGov macht nur Sinn, wenn CityGov für die Struktur das führende System ist. Diese würde bedeuten, das zunächst ein Z-Finder Export implementiert werden muss, der den Import ablöst.<br /> :Organisationseinheiten werden auch aus dem LDAP-System und ACUSTIG in CityGov importiert. Dies wäre dann auch nicht mehr möglich.<br /> :Wenn weiterhin Daten aus F-Finder, LDAP und ACUSTIG importiert werden sollen (Mitarbeiter und Produkte) muss überlegt werden wie das dann realisiert werden soll (Behörden-Schlüssel).<br /> <br /> ==Milestone 7==<br /> *;Bearbeitung der Stammdaten und Aufgabenbereiche innerhalb von CityGov für den gelebten Stand<br /> <br /> &lt;noinclude&gt;<br /> [[Kategorie:Partner]]<br /> &lt;/noinclude&gt;</div>

Liebold https://wiki.sitepark.com/index.php?title=GVP_-_Roadmap&diff=5587 2011-07-27T09:28:22Z

<p>Liebold: /* Milestone 6 */</p> <hr /> <div>== Milestone 1 - bis Ende September 2011 ==<br /> <br /> *;Benutzeroberfläche zur Erstellung, Bearbeitung und Visualisierung von Geschäftsverteilungsplänen<br /> :In diesem Milestone sollen nur die Grund-Funktionalitäten enthalten sein. Erzeugen von Reports, Export der Stände nach CityGov, usw. sind hier noch nicht enthalten. Mit diesem Stand soll überprüft werden, ob die Art der Applikation den Anforderungen entspricht. <br /> <br /> *;Funktionsumfang <br /> :- der &quot;gelebte&quot; Stand muss nicht angelegt werden, er ist immer verfügbar (wenn Rechte vorhanden) und spiegelt den aktuellen Stand in CityGov wieder. Dieser Stand ist nicht über das GVP-Modul editierbar. <br /> :- Neue Stände können durch kopieren eines existierenden Standes neu angelegt werden. <br /> :- In einem angelegtem Stand können Organisationseinheiten über die Baumansicht angelegt, verschoben und gelöscht werden (Drag&amp;amp;Drop und Context-Menü) <br /> :- Eine in der Baumansicht ausgewählte Organisationseinheit kann über den 'Blatt'-Tab angesehen werden. <br /> :- Eine in der Baumansicht ausgewählte Organisationseinheit kann über den 'Bearbeitung'-Tab bearbeitet werden. (Stammdaten, Aufgabenbereiche)<br /> <br /> ==Milestone 2 - bis Ende Oktober 2011 (Abhängig vom Ergebnis der Auswertung)==<br /> *;Feedback-Auswertung des Saarlandes - Erweiterung der Funktionalität<br /> <br /> :Zusammen mit dem Saarland soll überprüft werden:<br /> :- welche Anforderungen noch fehlen und welche Funktionen überflüssig oder geändert werden müssen.<br /> :- Usability der Applikation überprüfen und anpassen<br /> :- Design anpassen<br /> <br /> ==Milestone 3 - bis Mitte November 2011==<br /> *;Export von Geschäftsverteilungsplänen als XML-Daten<br /> <br /> ==Milestone 4==<br /> *;Export von Geschäftsverteilungsplänen als in sich geschlossene HTML-Site<br /> <br /> :Hier ist zu prüfen, ob dies wirklich notwendig ist, da über die Benutzeroberfläche des GVP-Moduls diese Ausgabe im Prinzip schon existiert.<br /> <br /> ==Milestone 5==<br /> *;Export von Geschäftsverteilungsplänen als PDF-Dokument<br /> <br /> ==Milestone 6==<br /> *;Überführung eines Geschäftsverteilungsplans nach CityGov.<br /> <br /> *;Stände finalisieren und archivieren.<br /> <br /> :Die Organisationsstruktur von CityGov im Saarland wird über den Z-Finder Import bestimmt. Die Überführung eines Geschäftsverteilungsplans nach CityGov macht nur Sinn, wenn CityGov für die Struktur das führende System ist. Diese würde bedeuten, das zunächst ein Z-Finder Export implementiert werden muss, der den Import ablöst.<br /> :Organisationseinheiten werden auch aus dem LDAP-System und ACUSTIG in CityGov importiert. Dies wäre dann auch nicht mehr möglich.<br /> :Wenn weiterhin Daten aus F-Finder, LDAP und ACUSTIG importiert werden sollen (Mitarbeiter und Produkte) muss überlegt werden wie das dann realisiert werden soll (Behörden-Schlüssel).<br /> <br /> ==Milestone 7==<br /> '''Bearbeitung der Stammdaten und Aufgabenbereiche innerhalb von CityGov für den gelebten Stand'''<br /> <br /> &lt;noinclude&gt;<br /> [[Kategorie:Partner]]<br /> &lt;/noinclude&gt;</div>

Liebold