PageRefFolder Black/White-Listing in Delta Generierung

[abiegel]

Hallo,

ich würde gerne eine Delta-Generierung auf verschiedene PageRefFolder einschränken. Ich habe nun gesehen, dass einem ChangeSet ein GenerateTask übergeben werden kann und dass dieser eine Startknoten Liste verwaltet. Die Konsequenz ist die Fragestellung,  wie komm ich an den GenerateTask dran ?

Außerdem hab ich das Gefühl, dass dieser Task eigentlich der nächste Auftragschritt sein könnte (Danach folgt der normale GenerierungsTask) und ich somit auf dem völlig fälschen Pfad sein könnte.

Kann mir jemand einen Hinweis geben, ob ich auf dem richtigen Weg bin und wie ich den GenerateTask korrekt instanziiere ?

Gruß André

ScheduleContext context = null;

/**

* refname of a pagereffolder , a child of root

*

* >root

*            ----> whiteListedPageRefFolder

*/

String  refname = "whiteListedPageRefFolder_refname";

IDProvider prf = context.getProject().getUserService().getStore(Type.SITESTORE, false).getStoreElement(refname, UidType.SITESTORE_FOLDER);

DeltaGeneration deltaGeneration = DeploymentUtil.createDeltaGeneration(context);

DeltaGeneration.ChangeSet changeSet ;

// changeset only allows to set Level and Dependency Rules

changeSet = deltaGeneration.calculateChangeSet();

// How to instantiate that thing ?

GenerateTask generationTask  =null; 

// is that needed  ?

generationTask.setStartnodesDefinableByUser(true);

// documentations states that it is modifiable

generationTask.getStartNodes().clear();

generationTask.getStartNodes().add(prf);

changeSet.configureGenerateTask(generationTask);

  changeSet.configureGenerateTask();

[abiegel]

Upate:

Der Ansatz klappt nicht. Ich habe, wie bereits angedeutet versucht, bei der Erzeugung des Deltas die Startknoten zu setzen. Allerdings endet dies in eine Generierung des Teilbaumes. Der Code dazu ist :

import de.espirit.firstspirit.access.schedule.*;

import java.util.List;

import de.espirit.firstspirit.access.store.IDProvider;

import de.espirit.firstspirit.access.store.IDProvider.UidType;

import de.espirit.firstspirit.access.store.Store.Type;

List tasks = context.getTasks();

String refname = "whiteListed";

IDProvider prf = context.getProject().getUserService().getStore(Type.SITESTORE, false).getStoreElement(refname,UidType.SITESTORE_FOLDER);

deltaGeneration =DeploymentUtil.createDeltaGeneration(context);

DeltaGeneration.ChangeSet changeSet ;

changeSet = deltaGeneration.calculateChangeSet();

for (ScheduleTask scheduleTask : tasks) {

if (scheduleTask instanceof GenerateTask) {

GenerateTask task = (GenerateTask) scheduleTask;

task.setStartnodesDefinableByUser(true);

task.getStartNodes().clear();

task.getStartNodes().add(prf);

changeSet.configureGenerateTask(task);

}

}

[mbergmann · Accepted solution]

Hallo André,

der Trick liegt hier in der Reihenfolge, da gibt es wohl ein Missverständnis wie das Ganze funktioniert.

Das Changeset kennt (abhängig von den Regeln die man vorher der DeltaGeneration mitgegeben hat) am Ende erstmal alle Knoten, die neu generiert werden müssen. Deren Menge wird berechnet auf Basis aller Änderungen im Projekt an den verschiedensten Elementen (Inhaltsseiten, Templates, Datensätze, Medien, Seitenreferenzen usw.) seit dem letzten Aufruf von createDeltaGeneration im aktuellen Auftrag. Hier ist wichtig zu verstehen, dass sich das "im aktuellen Auftrag" eben nicht nur auf die aktuelle Instanz des Auftrages bezieht die gerade läuft, sondern eben auch auf vorherige Läufe desselben Auftrages.

Die Information, ab welcher Revision Änderungen berücksichtigt werden sollen, steckt in der Auftragsvariablen #deltaGeneration.last_execution, deren Name ist definiert in der Konstanten DeltaGeneration.DELTA_GENERATION_LAST_EXECUTION.

Zusammen mit den auf der DeltaGeneration gesetzten Regeln, welche Abhängigkeiten zu berücksichtigen sind (dependencyRules/levelRules), entsteht dann quasi eine Liste von Sitestore-Ordnern, Seitenreferenzen und ggf. Medien, auf die sich diese Änderungen gemäß dieser Regeln "auswirken".

Ablauf des calculateChangeSet in Kurzform:

1. Ermittlung aller geänderten Objekte im Projekt seit der Revision gemäß #deltaGeneration.last_execution
2. Ermittlung aller neu zu generierenden Knoten (d.h. Strukturordner, Seitenreferenzen usw.) basierend auf den geänderten Objekten unter Berücksichtigung der definierten "Abhängigkeitsregeln"

Das changeSet.configureGenerateTask() macht dann letztlich nichts anderes, als diese Knoten dem nächsten (d.h. dem nächsten auf den Script-Task folgenden) Generierungstask hinzuzufügen (oder dem übergebenen wenn man die Variante mit Parameter benutzt). Eine Auswertung von bereits vorhandenen Knoten im Generierungstask findet nicht statt. Insbesondere auch keine Einschränkung auf Basis der vorhandenen - denn der Sinn ist es ja gerade, zusätzliche zu generierende Knoten hinzuzufügen.

Was Du also höchstens machen kannst: Aus Deiner Sicht "überflüssige" Knoten nach dem Aufruf von .configureGenerateTask(...) wieder aus dem Generierungstask zu entfernen.

Zu beachten ist dabei aber, dass diese "Manipulation" beim nächsten Lauf nicht berücksichtigt wird. Insbesondere wenn Du im selben Auftrag mal die eine und mal die andere Einschränkung machen willst, wird das Delta immer nur zum letzten Aufruf von DeploymentUtil.createDeltaGeneraion() berechnet, solange Du da nicht eingreifst. D.h. die von Dir "rausgeworfenen" Knoten würden - solange sie nicht durch eine erneute Änderung doch wieder generiert werden müssten - nicht generiert bzw. in den Generierungstask gelegt. Das Eingreifen ist grundsätzlich möglich durch Manipulation der Auftragsvariablen #deltaGeneration.last_execution, deren Name ist definiert in der Konstanten DeltaGeneration.DELTA_GENERATION_LAST_EXECUTION.

Ich hoffe das hilft Dir ein wenig 😉

Viele Grüße

Michael

[abiegel]

Hallo Michael, 

vielen vielen Dank, dass du das ganze Thema klarstellst. Somit besteht meine Option also die Startknoten nach dem configurateGenerateTask zu bereinigen. Es scheinen auch alle Arten von Store-Objekten betroffen zu sein (Site, Page, Media). Können mir da auch Template und Global-Store Elemente entgegen kommen ?

Leider wird dies dann kein 2 Zeiler mehr , weil ich alle enthaltenden Knoten mittels Backtracking auf eine eventuelle Relevanz überprüfen muss.

Gruß André

[mbergmann]

Hallo André,

nein, in den Startknoten können ja nur "generierbare" Knoten liegen. Also insbesondere keine Pages. Also nur Sitestore-Knoten und ggf. Medien(ordner) - wobei ich bei den Medien gerade nicht sicher bin - ich würde mich erstmal auf die Sitestore-Elemente konzentrieren.

Was ist denn eigentlich genau der Anwendungsfall dahinter?

Viele Grüße

Michael

[abiegel]

Hallo Michael,

ob ich schon PageStore Elemente gesehen habe, weiß ich grade nicht, aber Mediastore Elemente habe ich 100% schon gesehen..

Der Anwendungsfall ist die Restriktion auf KindsOrdner des Root. Die Begründung liegt einerseits darin einen kleinen WhiteListed-Bereich dediziert (schnell ) generieren zu können. Der BlackListed-Bereich ist nicht über Delta adequat umsetzbar.

Gruß André

[abiegel]

Hallo Michael,

one more thing ...

Um die Filterung der Generierungen nun mit den anderen Aufträgen zu teilen , muss ich nun die deltaGeneration.last_execution​ in die anderen Aufträge setzen ... Geht dies mit dem ScheduleContext ? Ich muss ja nun aus meinem Context irgendwie in die anderen Schedules.

Gruß André

[abiegel]

Hallo Michael,

muss man eigentlich noch was beachten bzgl der lastDeltaRevisionid  wenn man die Tasks manuell bearbeitet ?  wird dies noch automatisch gesetzt ?

Gruß André