From:Guido Flohr
Date:31.1.03 15:59
Subject:Expiry/AutoPublish in 3 Wochen
Reply-To:<imperia-users@imperia.de>
Attachments:[Source] unknown-1.pgp (application/pgp-signature)
Hallo,

eine aktuelle Supportanfrage, deren Lösung eine Antwort auf eine FAQ
ist. To whom it may concern ...

Problem: Das Expiry-Datum wird von Imperia mit dem Wert »in zwei Jahren«
initialisiert, egal, ob das im Meta-File passiert, oder über ein
Expiry-Plug-In geschieht. Beim Publish-Datum existiert ein analoges
Problem; die Lösung ist sinngemäß die selbe.

Tatsächlich benutzt Imperia die Regel »in zwei Jahren, falls Metafeld
'expiry_date' noch nicht gesetzt«. Der Trick besteht jetzt also darin,
das Feld geeignet zu initialisieren. Das lässt sich erreichen, indem
man im Workflow vor das Plug-In »Meta-Edit« ein Plug-In »Meta-Setter«
setzt, für den 4-Augen-Workflow also so:

	+----+  +----+  +----+  +----+
        |    |  |    |  |    |  |    |
	| MS +--+ ME +--+ ED +--+ AP |
	|    |  |    |  |    |  |    |
	+----+  +----+  +----+  +----+
         (4)     (1)     (2)     (3)

MS (Meta-Setter), ME (Meta-Edit), ED (Edit/Bearbeiten), 
AP (Approval/Genehmigung). Die Zahlen in Klammern kommen nachher
noch.

Das Meta-Setter-Plug-In muss jetzt noch konfiguriert werden:

    +-------------+-------------------------------------------------+
    | expiry_date | <!--Xstrftimeoff:3W:C:%Y-%02m-%02d %02H:%02M--> |
    +-------------+-------------------------------------------------+

Was passiert hier jetzt? Okay, »expiry_date« wird gesetzt, und zwar
mit Hilfe des Template-Konstrukts »Xstrftimeoff« (ist erschöpfend
im Programmierhandbuch dokumentiert).

Ganz kurz, die Syntax ist prinzipiell

	<!--Xstrftimeoff:OFFSET:LOCALE:FORMAT-->

Fangen wir beim eher unwichtigen an. Für LOCALE muss eine auf dem
System installierte Locale (in Windows-Lingo »Ländereinstellung«)
angegeben werden. Leider ist das völlig systemabhängig, gehört
auch nicht hierhin, aber die Locale »C« gibt es *immer*, das ist
nämlich einfach der Default-Wert, mehr oder weniger die Einstellung
für USA/Englisch. Wichtig ist das z. B., wenn man Monatsnamen oder
Wochentage in einer anderen Sprache als Englisch ausgeben will.
Brauchen wir hier nicht, also sind wir mit »C« zufrieden, das gibt
es überall.

OFFSET bestimmt die Distanz zum aktuellen Datum. Wir benutzen hier
»3W« also 3 Wochen. Genausogut ginge auch

	5m  - fünf Minuten
	1h  - eine Stunde
	2D  - zwei Tage
	3W  - drei Wochen
	5M  - fünf Monate
	17Y - 17 Jahre
	...
	2Y3M4W5D6H7M - zwei Jahre und drei Monate und ...

Achtung: Das ist case-sensitiv (weil months und minutes beide
mit M anfangen).

Das FORMAT ist ebenfalls ein bisschen systemabhängig, es besteht
aus beliebigem Text mit Platzhaltern, die mit einem Prozentzeichen
anfangen. Genaueres kriegt man normalerweise mit dem Kommando
»man strftime« oder auch »man date« raus. Brauchen wir hier aber
auch nicht. Wir nehmen:

	%Y-%02m-%02d %02H:%02M

lies als

	JAHR-MONAT-TAG STUNDEN:MINUTEN

also exakt das Format, das Imperia für Publish-/Expiry-Date erwartet.

Und schon geht's, die Voreinstellung stimmt. Ob man den Redakteur das
Datum jetzt überhaupt noch verändern lässt (also nur die Voreinstellung
bestimmt, oder aber das Meta-Feld nicht editierbar macht), hängt von
den Umständen ab. Denkbar wäre auch, den Redakteur eine Auswahl treffen
zu lassen:

	Wann soll das Dokument verschwinden:

		1 Woche
		4 Wochen
		6 Monate
		1 Jahr

Abhängig von der Auswahl setzt man dann ein Metafeld »offset« (oder
was man will) und verbrät das dann nochmal in der Xstrftime-Geschichte.

So weit, so gut, in der Realität stößt man jetzt auf ein weiteres
Problem, dass gar nichts mit dem Datum, sondern nur mit dem Workflow
zu tun hat: In allen Rubriken ist der Eingangspunkt des Workflow
abgespeichert. Nochmal hochscrollen, da stehen ja Nummern unter dem
stilisierten Grid-Snapshot. Man sieht, dass der alte Workflow den
Eingang mit der Nummer 1 hatte, jetzt haben wir vorne einen Meta-Setter
eingefügt, der kriegt die nächste freie Nummer 4 und wird so abgespeichert.

Wenn wir jetzt einfach ein neues Dokument erzeugen, wird der Workflow
gelesen, in der Rubrik ist Nummer 1 als Eingang abgespeichert, und
schon gibt es einen Fehler:

	Workflow-Schritt Nummer 1 ist kein Eingang

Nochmal hochscrollen, da hat Imperia einfach recht. Mit der Maus hilft
jetzt nur eins: Durch *alle* Rubriken gehen, und überall den richtigen
Workflow-Eingang auswählen, und dann neu abspeichern. 

Ja, ab 100 Rubriken kriegt irgendjemand dafür Prügel, im Zweifel
Imperia. Was tun? Vielleicht hat jemand ja meinen Rat befolgt, und
fügt in jedes Template immer einen Aufruf für ein allgemeines
Code-Include (am besten eins in HTML *und* eins in Perl). Dann hat
man schon gewonnen, weil es völlig ausreicht, das Konstrukt aus
dem Meta-Setter ins Template (in dem Fall unser Codeinclude
»general.htms« zu schreiben):

	<INPUT TYPE="HIDDEN" NAME="IMPERIA:expiry_date" VALUE="<!--Xstrftimeoff:.....--> >

Okay, nächstes Mal denken wir dran. Aber dieses Mal? Am einfachsten
ist es dann wohl, die Workflow-Datei ausnahmsweise nicht mit dem
Grid, sondern mit einem Text-Editor zu bearbeiten. In den Rubrikinformationen
merkt sich Imperia die *Nummer* des Eingangs, wenn wir die Plug-Ins
im Workflow von Hand umsortieren, ist also alles in Ordnung, wir
müssen nur zusehen, dass der Eingang wieder die alte Nummer 1 hat.

Also sucht man sich aus »site/workflow/data« die passende Datei
raus (bitte in einem *anderen* Verzeichnis ein Backup der Datei
machen), und fummelt mal von Hand dran rum. Scharfes Hingucken sollte
dafür eigentlich schon reichen, aber wer auf Nummer Sicher gehen
will:

Innerhalb des Elements <steps> sind Unterelemente <step> enthalten
(die Reihenfolge in der XML-Datei ist völlig gleichgültig). Jeder
<step> hat ein Attribut »id«, eine durchlaufende Nummerierung. In
unserem Beispiel ändern wir einfach die »id« von Step Nummer 4
in 1, und die vom alten Step Nummer 1 in 4.

Reicht noch nicht ganz: Damit das Grid weiß, von wo nach wo die
Linien gezogen werden, gibt es für jeden Ausgang ein Element <output>.
Dieses Element hat ein Attribut »destination«, das angibt, zu
welchem anderen Step (referenziert über das Attribut »id«) die
Verbindung gehen soll. Voher gab es diese Verbindungen:

	1 -> 2
	2 -> 3

Nach dem ersten Schritt (also noch bevor wir die XML-Datei von
Hand angepackt haben) wurde vorne Schritt 4 eingefügt, Ergebnis:

	4 -> 1
	1 -> 2
	2 -> 3

Jetzt vertauschen wir die Schritte 4 und 1, im Ergebnis muss es
also so aussehen:

	1 -> 4
	4 -> 2
	2 -> 3

Wer jemals eine XML-Datei im Quelltext gesehen hat, kriegt das schon
hin. Danach sollte man die Datei vorsichtshalber nochmal im Grid
laden (Java-Console anschalten, um evtl. Syntax-Fehler zu erkennen)
und gucken, dass das Grid sich den neuen Workflow unterschieben lassen
hat.

Viel Spaß beim Rumprobieren!

Guido
-- 
Imperia AG, Development
Leyboldstr. 10 - D-50354 Hürth - http://www.imperia.de/

Thread (Expiry/AutoPublish in 3 Wochen)
  • 31.1.03 15:59, Guido Flohr

© 2001, 2002 marchive.pl Christian Lackas

[HOME]   [MARCHIVE]   [INDEX]   [IMPERIA]   [IMPRESSUM]   [DELTA]