Changelog 2.1.0: Unterschied zwischen den Versionen

Version vom 23. September 2009, 14:17 Uhr

Release Notes

Neuimplementierung der Abhängigkeitsprüfung. Alle Abhängigkeiten werden nun während der Generierung einer Seite erfasst. Die Seite wird nur neu generiert, wenn sich Daten geändert haben, die von der Seite verwendet wurden. Daraus ergibt sich, das es nicht mehr relevant ist mit welchem Link-Type (link, systemlink, navlink) Elemente miteinander verknüpft werden. Siehe Dependencies-Service, LinkTree-Service
Löschen von depublizierten Seiten erfolgt unmittelbar nach Prüfung aller Abhängigkeiten. Der unter Umständen hohe Zeit-Versatz zwischen dem Depublizieren und den tatsächlichen löschen der Seite durch Scheduler-Mechanismen wurde mit der neuen Abhängigkeitsprüfung deutlich reduziert.
Das sequenzielle publizieren einzelner Artikel konnte aufgrund der neuen Abhängigkeitsprüfung aufgehoben werden. Das generieren von Artikeln kann nun parallel erfolgen.
Abhängigkeiten über mehrere Links hinweg können nun erkannt werden. Wird innerhalb eines Templates auf z.B. mylink.systemlink.mylist[2].mylink.systemlink.mytext zugegriffen wird der entsprechende Artikel nun auch generiert, wenn sich mytext geändert hat.
Neues Attribut referrerLinks für Article, Resource, Media
Neues Attribut publishedIn für Article, Resource, Media
Neues Attribut convert für sp:print
Neue Methode convert() für String
Implementation ein Schnittstelle für die Virtuelle Verwaltung (City Gov 3) zum Bürgerservice der Firma TSA

Anmerkungen

Wir empfehlen diese Update von Sitepark durchführen zu lassen.

Aktionen nach dem Update

Nach dem Update auf Version 2.1.0 müssen alle Seiten neu generiert werden, damit alle Daten für die neue Abhängigkeitsprüfung zu Verfügung stehen. Wird die Generierung aller Seiten nicht ausgeführt, werden die Seiten bei abhängigen Änderungen nicht automatisch aktualisiert.

Suchabfragen für neue Abhängigkeitsprüfung

Durch die neue Abhängigkeitsprüfung werden nicht mehr nur die Suchabfragen überwacht, die am Artikel mit dem Type query gespeichert wurden, sondern alle mit sp:collection während der Generierung ausgeführten Suchabfragen.

Sind die Seiten eines Systems so aufgebaut, das für viele Seiten beim Generieren eine Suchabfrage ausgeführt werden muss, steigt die Anzahl der in regelmäßigen Abständen zu prüfenden Suchabfragen im Vergleich zur Version 2.0.x. Üblicherweise sind dies Suchabfragen, die Artikel suchen, die auf den gerade zu generierenden Artikel verlinken.

Sitepark empfiehlt in diesen Fällen die Suchabfragen durch die Funktionalität des neuen Attributes referrerLinks für Article, Resource, Media zu ersetzen. Dieses Attribut liefert alle Links, die auf den entsprechenden Artikel verweisen. Die Links werden über das IDLink-Objekt beschrieben.

Attribut 'Id'

Bis Version 2.0.x wurde <object>.Id mit grossem I toleriert. Dies ist ab Version 2.1 nicht mehr möglich. Sollten Templates diese Variante verwenden, muss diese durch <object>.id ersetzt werden.

Paradigmenwechsel

Sitepark hat wie oben beschrieben der Version 2.1 ein neues Verfahren implementiert, mit dem künftig Abhängigkeiten innerhalb des CMS erkannt werden. Bis zur Version 2.0.x wurden Abhängigkeiten zwischen Artikeln ausschließlich über den Eingabebereich eines Templates - in der Regel also innerhalb von <sp:io type="in"></sp:io> hergestellt. Suchabfragen und interne Links, die einer Überwachung unterliegen sollen, mussten dort angelegt werden. Mit der Version 2.1 wurde diese Funktionalität vollständig in den Ausgabebereich der Templates verlegt. Das bedeutet, dass fortan Abhängigkeiten zwischen Artikeln ausschließlich dadurch hergestellt und erkannt werden, dass ein Artikel während des Publikationsprozesses auf Inhalte eines anderen zugreift. Verknüpfungen und Suchabfragen, die im Eingabebereich eines Artikels angelegt wurden, führen damit nun nicht mehr automatisch zu wechselseitigen Abhängigkeiten. In der Praxis erwartet Sitepark durch diese Änderung des Systemverhaltens keine negativen Auswirkungen auf den Betrieb bestehender Systeme, da üblicherweise zu einer Verknüpfung im Eingabebereich eine entsprechende Ausgabe gehört.

@@ Zeile 26: / Zeile 26: @@
 Sitepark empfiehlt in diesen Fällen die Suchabfragen durch die Funktionalität des neuen Attributes <code>referrerLinks</code> für [[Article]], [[Resource]], [[Media]] zu ersetzen. Dieses Attribut liefert alle Links, die auf den entsprechenden Artikel verweisen. Die Links werden über das [[IDLink]]-Objekt beschrieben.
+=====Attribut 'Id'=====
+Bis Version 2.0.x wurde <code><object>.Id</code> mit grossem <code>I</code> toleriert. Dies ist ab Version 2.1 nicht mehr möglich. Sollten Templates diese Variante verwenden, muss diese durch <code><object>.id</code> ersetzt werden.
 =====Paradigmenwechsel=====
 Sitepark hat wie oben beschrieben der Version 2.1 ein neues Verfahren implementiert, mit dem künftig Abhängigkeiten innerhalb des CMS erkannt werden. Bis zur Version 2.0.x wurden Abhängigkeiten zwischen Artikeln ausschließlich über den Eingabebereich eines Templates - in der Regel also innerhalb von <code><sp:io type="in"></sp:io></code> hergestellt. Suchabfragen und interne Links, die einer Überwachung unterliegen sollen, mussten dort angelegt werden. Mit der Version 2.1 wurde diese Funktionalität vollständig in den Ausgabebereich der Templates verlegt. Das bedeutet, dass fortan Abhängigkeiten zwischen Artikeln ausschließlich dadurch hergestellt und erkannt werden, dass ein Artikel während des Publikationsprozesses auf Inhalte eines anderen zugreift. Verknüpfungen und Suchabfragen, die im Eingabebereich eines Artikels angelegt wurden, führen damit nun nicht mehr automatisch zu wechselseitigen Abhängigkeiten. In der Praxis erwartet Sitepark durch diese Änderung des Systemverhaltens keine negativen Auswirkungen auf den Betrieb bestehender Systeme, da üblicherweise zu einer Verknüpfung im Eingabebereich eine entsprechende Ausgabe gehört.