aVogt
Returning Creator

historische Daten eines datensatz ermitteln

Hallo,

in userem System wird keine Freigabe verwendet (also wenn etwas gespeichert wird, wird es auch veröffentlicht).

Nun soll jedoch in einer Datenquelle ein Bearbeitungsstand möglich sein und dieser erst "bei Freigabe" veröffentlicht werden.

Nun habe ich mir folgendes überlegt (ist nicht toll, aber es sollte die Anforderung erfüllen).

Bei der Pflege de Datensatzes gibt es ein Eingabefeld "nicht veröffentlichen", wenn das gesetzt ist, wird der aktuelle Stand nicht veröffentlicht.

Der Stand des Datensatzes, der veröffentlicht werden soll, hat das Merkmal "nicht veröffentlichen" nicht gesetzt.

Also will ich über die Historie iterieren (ich hoffe, die kommt geordnet an - also die letzte Änderung als erstes und das "Anlegen" des Datensatzes als letztes):

$CMS_FOR(PRListEntity,#row.getSession().getHistory(#row.getKeyValue()))$

     [Wenn Merkmal das erste Mal nicht gesetzt, merke dir PRListEntity]

$CMS_END_FOR$

Das scheint zu funktionieren.

Nun habe ich bei der Pflege der Datensätze u.a. eine "CMS_INPUT_CONTENTAREALIST". Die Elemente (eingefügt mit <TEMPLATE .../>) dieser Liste werden z.T. bei bestimmten Reihenfolgen/Anzahlen noch formatiert - somit kann ich das nicht direkt in dem <TEMPLATE .../> vornehmen.

Wenn ich in der Tabellenvorlage über den Bezeichner der ContentAreaList von dem "aktuell freigegebenen" Datensatz gehe, kann ich über die Elemente iterieren und die notwendigen Formatierungen vornehmen.

=> $CMS_FOR(item,cs_ctlist)$ (liefert: de.espirit.firstspirit.client.access.editor.ContentAreaListValueImpl$SectionListImpl)

Wenn ich nun von dem historieschen Stand dies auch machen möchte, klappt das nicht.Da bekomme ich einen EditorWrapper

Nun sollte man die Daten ja über das Formular der Datenquelle holen (Content2 = contentstore.getContent2ByName(refernznameDerdatenquelle);

, aber wie komme ich da mit der CMS_Syntax ran?

Hat jemand eine Idee?

0 Kudos
5 Replies
aVogt
Returning Creator

Habs nun gefunden...

$CMS_SET(FPDetailList,#global.userService.store(class("de.espirit.firstspirit.access.store.Store$Type").CONTENTSTORE,true).getContent2ByName("frderprogrammprogramm").getDataObject(ent).get("cs_ctlist").getEditor().get(#global.language))$

frderprogrammprogramm = Name der Datenquelle

ent = historische Version des Datensatzen (Enity)

cs_ctlist = FormularfeldName

ist das der richtige Weg, oder gibts was günstigeres?

=====

Edit:

Ich habe ein neues Problem. In der Vorschau über den JavaClient funktioniert es wie gewünscht. Wird die Seite veröffentlich funktioniert das nicht. Die Vorschau liefert ein anderes Ergebnis als die Veröffentlichung!

Die historische Version, von der ich die Daten veröffentlichen möchte holen ich mir per:

$CMS_FOR(PRListEntity,#row.getSession().getHistory(#row.getKeyValue()))$
     $CMS_IF(!PRListEntity.getValue("stopDeploy")$
          [merke dir diese Entity]
     $CMS_END_IF$
$CMS_END_FOR$

Nun bekomme ich z.B. die Entity (PRListEntity ausgegeben)
     EntityImpl@6f8dd73b{Programm,TEMPORAL_INVALID,FS_ID=25154,FS_VALID_FROM=1307708965358,FS_VALID_TO=13...}
bei dieser liefert die Abfrage von "stopDeploy"
     bei der Vorschau im JavaClient: false
     nach der Generierung/Veröffentlichung: true

Die Entity ist bei Vorschau und Generierung identisch (zumindest was die Ausgabe von "PRListEntity" betrifft). Trotzdem erhalte ich unterschiedliche Ergebnisse.

Woran kann das liegen? Was habe ich falsch gemacht?

0 Kudos
aVogt
Returning Creator

Ich hab nun eine Methode gefunden:

mit

     $CMS_FOR(PRListEntity,schema.getSession(true).getInvalidEntities(#row.getKeyValue() ) )$

klappt es. Damit kommen auch nach der Generierung die richtigen Ergebnisse raus.

Das andere verhalten wurde als Bugverdacht (ID: 105015) aufgenommen.

Da ich in der Vorlage die FOR-Schleife nicht vorzeitig beenden kann, könnte man auch ein Script schreiben (da kann ich die Schleife verlaffen).

Gibt es Erfahrungen, was performanter ist, die Vorlage oder ein Script? Oder muss/sollte man das selbst herausfinden (über Zeitausgaben)?

Die Vorlage könnte man noch dahingehend anpassen, dass nachdem der erste Datensatz gefunden wurde die Prüfung nicht mehr durchgeführt wird.

$CMS_SET(nfg,false)$

$CMS_FOR(PRListEntity,schema.getSession(true).getInvalidEntities(#row.getKeyValue() ) )$

     $CMS_IF(! nfg)$

          //Datensatz prüfen, ob er der gewünschte ist. wenn ja =>  $CMS_SET(nfg,true)$

     $CMS_END_IF$

$CMS_END_FOR$

0 Kudos

Insgesamt ist das kein Weg, den ich zur Nachahmung empfehlen kann. Zunächst ist das Verhalten der angesprochenen Methode(n) nur für "aktuelle" Sessions definiert. Und die resultierenden DB-Abfragen sind laufzeitintensiv, was normalerweise kein Problem ist. Aber in der Generierung schon zu einem werden kann..

Peter
0 Kudos

Wie sollte man sonst die historischen Datensätze ermitteln?

Selbst wenn die Freigabe genutzt wird, bringt dass nicht so viel, da angegeben werden soll wann (welcher Tag und eine von drei Uhrzeiten) eine Seite veröffentlicht werden soll. Hintergrund ist, dass bestimmte Förderprogramme oder Änderungen in Programmen erst zu einem bestimmten Stichtag veröffentlicht werden sollen.

Die Generierung läuft noch in einem annehmbaren Zeitrahmen ab (es wird nicht bei jeder Seite nach der Historie gesehen, sondern nur bei einigen, die ein bestimmtes Merkmal haben und wenn die "terminierte Veröffentlichung" durch ist, wird das Merkmal zurückgesetzt, so dass die Seite normal veröffentlciht wird).

Und wenn die Fachabteilung dass so wünscht, muss sie halt damit leben, dass die Generierung etwas länger dauert.

0 Kudos

Es gibt keinen anderen Weg. Es war mir nur wichtig, auf die "Nebenwirkungen" hinzuweisen, damit zukünftige Leser diese bei ihrer Entscheidung über den Einsatz der Lösung berücksichtigen können.

Peter
0 Kudos