Questions & Answers

SOLVED
abiegel
New Creator

PageRefFolder Black/White-Listing in Delta Generierung

Jump to solution

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();

0 Kudos
1 Solution

Accepted Solutions
mbergmann
Crownpeak employee

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

View solution in original post

0 Kudos
7 Replies
abiegel
New Creator

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);

}

}

0 Kudos
mbergmann
Crownpeak employee

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

0 Kudos

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รฉ

0 Kudos

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

0 Kudos

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รฉ

0 Kudos

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รฉ

0 Kudos

Hallo Michael,

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

GruรŸ Andrรฉ

0 Kudos

Type a product name