- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
PageRefFolder Black/White-Listing in Delta Generierung
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();
- Labels:
-
Developers
-
Project Usage
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
- Ermittlung aller geรคnderten Objekte im Projekt seit der Revision gemรคร #deltaGeneration.last_execution
- 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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);
}
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
- Ermittlung aller geรคnderten Objekte im Projekt seit der Revision gemรคร #deltaGeneration.last_execution
- 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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รฉ
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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รฉ
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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รฉ
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hallo Michael,
muss man eigentlich noch was beachten bzgl der lastDeltaRevisionid wenn man die Tasks manuell bearbeitet ? wird dies noch automatisch gesetzt ?
Gruร Andrรฉ

