Search the FirstSpirit Knowledge Base
Hallo Community,
In unserem Projekt benötigen wir in den Metadaten Informationen über das zugrunde liegende Medienelement (z.B. Datei-Name, Extension, Dateigröße, FSID, ...). Hierzu haben wir eine Reihe an ValueServices implementiert, welche die entsprechenden Werte über einen ModelListener ermitteln. Die ValueServices binden wir klassisch per Schedule ein:
<RULE>
<SCHEDULE id="fileSizeId" service="GetFileSize"/>
<DO>
<PROPERTY name="VALUE" source="md_filesize"/>
</DO>
</RULE>
Für im Nachhinein neu hinzugefügte Medien funktioniert das auch so weit.
Problematisch wird es, wenn man einen ValueService im Nachhinein implementiert und die Änderung dann auf alle bestehenden Elemente ausführen möchte.
Meine Versuche, per Script oder Executable über den Media Store zu iterieren, eine Änderung an den Metadaten vorzunehmen und diese wieder zurückzunehmen und anschließend zu speichern, bringt leider nicht den gewünschten Erfolg, dass die ValueServices getriggert werden und die Metadaten befüllen.
iterate(StoreElement root) {
for (media : root.getChildren()) {
if (!media.isFolder() && media instanceof Media) {
try {
isReleased = media.isReleased();
media.setLock(true, false);
metaFormData = media.getMetaFormData();
// change a text value temporarily
value = metaFormData.get(null, "md_page_type").get();
metaFormData.get(null, "md_page_type").set(value+"_changed");
media.setMetaFormData(metaFormData);
media.save();
// and restore the original value
metaFormData.get(null, "md_page_type").set(value);
media.setMetaFormData(metaFormData);
media.save();
if (isReleased) {
media.release();
}
media.setLock(false, false);
} catch (LockException e) {
Logging.logError(EXCEPTION + media, e, LOGGER);
} catch (ElementDeletedException e) {
Logging.logError(EXCEPTION + media, e, LOGGER);
}
}
}
}
Daher meine Frage:
Besteht eine Möglichkeit, die ValueServices per Script oder Modul Aufruf zu triggern, dass diese den gültigen Wert in die Metadaten speichern?
Oder gibt es eine andere Möglichkeit als ValueServices, an Informationen des jeweiligen StoreElements in den Metadaten Formularen / Regeln zu kommen?
Hallo Lenz,
in der neuesten Doku steht es etwas expliziter als früher:
"Externe Services sind im Rahmen der Regelauswertung (im <SCHEDULE/>-Abschnitt) nur verfügbar, wenn ein Formular interaktiv von einem Redakteur bearbeitet wird.
Diese Regeln greifen nicht, wenn Operationen zum Lesen, Speichern oder Freigeben per API ausgeführt werden, z. B. in Executables oder Beanshell-Skripten.
Validierungen mit den Restriktionsstufen scope="RELEASE" bzw. scope="SAVE" in Verbindung mit <SCHEDULE/> eignen sich damit ausschließlich für redaktionelle Aufgaben (ähnlich wie die Eigenschaft EDITABLE) und nicht dazu, die Gültigkeit von Inhalten technisch sicherzustellen."
Kannst Du vielleicht erklären, warum ihr die Werte, die sich letztlich auch über das Medium selber ermitteln lassen, überhaupt nochmal separat in den Metadaten braucht?
Grundsätzlich wäre ein anderer (meiner Meinung nach besserer) Weg die Nutzung eines UploadHooks. Der funktioniert auch beim Ansprechen per API und wird auch gefeuert wenn man an der Mediendatei etwas ändert (d.h. nicht nur beim Anlegen sondern auch beim Hochladen neuer Varianten für die Auflösungen). D.h. in Verbindung mit einem UploadHook müsste der "Trick" mit dem nachträglichen Bearbeiten (für vorhandene Medien) dann funktionieren, wobei der Hook nur greift wenn man tatsächlich das Bild-Objekt per setPicture(...) ändert. Hier sollte es aber reichen, dem Medium sein eigenes Bild erneut "vorzuwerfen".
Viele Grüße
Michael
Hallo Lenz,
in der neuesten Doku steht es etwas expliziter als früher:
"Externe Services sind im Rahmen der Regelauswertung (im <SCHEDULE/>-Abschnitt) nur verfügbar, wenn ein Formular interaktiv von einem Redakteur bearbeitet wird.
Diese Regeln greifen nicht, wenn Operationen zum Lesen, Speichern oder Freigeben per API ausgeführt werden, z. B. in Executables oder Beanshell-Skripten.
Validierungen mit den Restriktionsstufen scope="RELEASE" bzw. scope="SAVE" in Verbindung mit <SCHEDULE/> eignen sich damit ausschließlich für redaktionelle Aufgaben (ähnlich wie die Eigenschaft EDITABLE) und nicht dazu, die Gültigkeit von Inhalten technisch sicherzustellen."
Kannst Du vielleicht erklären, warum ihr die Werte, die sich letztlich auch über das Medium selber ermitteln lassen, überhaupt nochmal separat in den Metadaten braucht?
Grundsätzlich wäre ein anderer (meiner Meinung nach besserer) Weg die Nutzung eines UploadHooks. Der funktioniert auch beim Ansprechen per API und wird auch gefeuert wenn man an der Mediendatei etwas ändert (d.h. nicht nur beim Anlegen sondern auch beim Hochladen neuer Varianten für die Auflösungen). D.h. in Verbindung mit einem UploadHook müsste der "Trick" mit dem nachträglichen Bearbeiten (für vorhandene Medien) dann funktionieren, wobei der Hook nur greift wenn man tatsächlich das Bild-Objekt per setPicture(...) ändert. Hier sollte es aber reichen, dem Medium sein eigenes Bild erneut "vorzuwerfen".
Viele Grüße
Michael
Hallo Michael,
Danke für das ausführliche Feedback.
Zur Erklärung des Anwendungsfalls:
Wir verwenden im Projekt einen Solr Adapter, der Automatisch Inhalte aus FirstSpirit indiziert. Für die gezielte Indizierung von eigenen Attributen für Medien verwendet dieser das Metadaten Template, weslab wir die Informationen dort benötigen.
Ich habe alternativ jetzt das Script in einen Executable-Aufruf verschoben, welcher gezielt die Felder in den Metadaten befüllt, und hierbei die gleichen Funktionen zur Werteermittelung wie die ValueServices / UploadHooks benutzen. Da es sich hier lediglich um ein Maintenance Script für nachträgliche Änderungen handelt, ist es für den Anwendungsfall so erstmal ausreichend.
Eine Implementierung per Upload Hook hatten wir ebenfalls in Betracht gezogen, bzw. an anderer Stelle auch schon umgesetzt. Mir war allerdings nicht klar, dass der Upload per Api vorgetäuscht werden kann. Ich werde unsere ValueService basierte Implementierung für diesen Anwendungsfall dann vollständig auf UploadHooks umstellen.
Vielen Dank für Deinen Input!
Lenz