C_Klingbeil
I'm new here

Dateiendung einer Seite manipulieren

Hallo Community,

gibt es eine Möglichkeit, die Dateiendung einer Seite zu manipulieren? Die getter Methode habe ich ja über #global.page.getExtension(), aber ich finde in der API beim ContentProducer keinen setter für die Extension. Gibt es die setExtension Methode trotzdem? Irgendwie muss eine Section ja die Extension einer Page überschreiben können.

Anwendungsfall:

Eine Seitenvorlage beinhaltet eine Textarea, in die der Projektadmin ini-, xml-, xsd-, ...-Code einfügen kann (Stichwort Robots, RegEx, CacheManager...). Über einen Radio-Button wollten wir die Zielextension bestimmen, damit wir nicht für jeden Dateityp eine eigene Seitenvorlage oder einen Absatz mit der benötigten Extension (kommt aufs Gleiche raus) anlegen müssen.

Viele Grüße,

C. Klingbeil

7 Replies
gockel
Crownpeak employee

Für diese Anforderung gibt es eine Einstellmöglichkeit der Dateiendung im Template:

* Register einer Seitenvorlage

* Register einer Absatzvorlage

0 Kudos
C_Klingbeil
I'm new here

Das ist klar, aber

... Über einen Radio-Button wollten wir die Zielextension bestimmen, damit wir nicht für jeden Dateityp eine eigene Seitenvorlage oder einen Absatz mit der benötigten Extension (kommt aufs Gleiche raus) anlegen müssen...

Das war meine Frage. Ansonsten habe ich x Kopien der Absatz- / Seiten-Vorlage, die ich alle warten muss. Und das ausschließlich für die Unterscheidung der Dateiendung??? Das halte ich nicht für sehr zweckmäßig...

Aber vielleicht gibt es noch eine bessere Umsetzung für unseren Anwendungsfall?

0 Kudos

Alternativ könnte man auch überlegen ein entsprechendes FirstSpirit-Modul zu bauen, zum Beispiel ein Webapplikation. Dann könnte der Projektadmin die Dateien in der Adminkonsole bearbeiten, wie das zum Beispiel bei FS Security gemacht wird.

Der klassische Weg, ohne FirstSpirit wäre die Dateien in ein VCS zu überführen und die dann per geeignetem Auftragsskript an die richtige Stelle zu kopieren.

0 Kudos
hoebbel
Crownpeak employee

Hallo Frau Klingbeil,

das Problem ist ja zweigeteilt. Zum Einen muss die Endung der entsprechenden Dateien geändert werden, zum Anderen müssen die Links auf die entsprechenden Dateien die geänderte Endung berücksichtigen.

Bei den Links muss dann noch zwischen manuellen Links (Linktemplates) und automatischen Links (Navigationen) unterscheiden werden. In beiden Fällen müsste dann abgefragt werden, ob die Zielseite die "normale" Endung hat oder ob diese Endung geändert wurde. Da Sie schreiben, dass die entsprechende Eingabekomponente in der Seitenvorlage liegt, ist das noch einigermaßen performant lösbar. {Bei der Erzeugung jedes Links muss überprüft werden, ob die Endung der Zielseite überschrieben wurde}. Diesen Teil der Aufgabe sehe ich als gut lösbar an.

Bleibt nur noch die eigentliche Umbenennung der Endungen. Hier sehe ich erst einmal keine einfache Lösung. Das Beste, was mir auf Anhieb einfällt, wäre folgender Ansatz:

- Ich erzeuge eine Textdatei, in dem alle Seiten aufgelistet werden (inkl. neuer Zielextension).

Ich würde die Textdatei direkt als Shellskript erzeugen.

Für den Inhalt der Textdatei gibt es zwei Möglichkeiten. Entweder iterieren Sie über den gesamten Sitestore und holen sich die geänderten Seiten (sollten Sie nur bei sehr kleinen Projekten in Erwägung ziehen) oder besser Sie holen sich die entsprechende Vorlage und von der alle Verwendungen [im Freigabestand]. Anhand dieser Verwendungen können Sie dann die entsprechende Umwandlungsliste zusammenstellen. Das Ganze müsste mit FirstSpirit Syntax (also ohne den Einsatz von Skripten) funktionieren.

Dann brauchen Sie in dem Auftrag noch eine Skriptaktion, die das entsprechende Skript ausführt (Beispiel: Veröffentlichen ohne Sprachverzeichnis)

Jetzt müssen Sie nur noch sicherstellen, dass es keine Veröffentlichung gibt, wenn das Skript nicht sauber durchläuft, da Sie ansonsten tote Links hätten.

Insgesamt gefällt mir diese Lösung eigentlich nicht, aber etwas Besseres [abgesehen von der Erzeugung eines eigenen URL Creators Re: Eigenes UrlCreator Modul erstellen, welches aber mit freigegebenen API Mitteln nicht möglich ist] ist mir nicht eingefallen.

Viele Grüsse aus Dortmund,

  Holger Höbbel

0 Kudos
Peter_Jodeleit
Crownpeak employee

Anwendungsfall:

Eine Seitenvorlage beinhaltet eine Textarea, in die der Projektadmin ini-, xml-, xsd-, ...-Code einfügen kann (Stichwort Robots, RegEx, CacheManager...).

Wieso wird keine Datei in der Medienverwaltung dafür benutzt?

Peter


Wieso wird keine Datei in der Medienverwaltung dafür benutzt?

Dafür müsste man für alle Redakteure den Upload von ini-, xsd-, etc-Files erlauben. Das ist aber von der Security nicht erlaubt. Auf ein Template könnte man die Berechtigung auf die Administratorengruppe beschränken. Oder gibt es beim Medien-Upload doch eine Einschränkung der Berechtigung (für die erlaubten Medientypen) auf Benutzergruppen-Ebene, die ich nicht kenne?

0 Kudos

Eventuell könnte diese Aufgabe auch von einem Servlet bzw. einem Equivalent übernommen werden. Die Seite wird beispielsweise als jsp generiert und je nach Selektion dem Anforderer als xml, dtd oder ini zurückgegeben.

0 Kudos