Objekt-IDs auch im ContentCreator finden

Hallo,

ich beziehe mich auf Suche nach Objekt-ID im WebClient?

Wir haben häufiger den Anwendungsfall, dass auch Redakteure mit wenig technischem Verständnis Objekt-IDs (hauptsächlich von Seiten) benutzen wollen/müssen. Im SiteArchitect gibt es die spezielle Suche nach ID, die globale Suche findet aber die IDs nicht. Im ContentCreator kann man überhaupt nicht nach Seiten-IDs suchen, bzw. sie werden nicht gefunden.

Auch wenn nicht alle Redakteure technische IDs brauchen, sollten sie aber welche finden können, wenn sie gezielt danach suchen. Deswegen wünsche ich mir eine Erweiterung des Suchreports im ContentCreator, der auch die Suche nach Objekt-IDs ermöglicht.

Grüße

Matthias

4 Comments
matthiasforberg
Occasional Collector

Hallo nochmal,

es freut mich, dass so viele Leute für diese Idee gestimmt haben. Heute habe ich gelernt, dass das tatsächlich schon geht und sogar in der ODFS steht, bloß etwas versteckt - deswegen bin ich offensichtlich nicht der einzige der es nicht kannte.

Also im ContentCreator (und auch in der globalen Suche im SA) kann man durch Eingabe von z.B. "fs.id=4711" eine Seite (oder ein anderes Objekt, Bild etc.) direkt finden. "fs.uid=mypage" findet den Referenznamen.

Ich vermute, damit ist meine Anfrage hinfällig - oder fällt jemandem noch ein nicht abgedeckter Fall ein?

Grüße
Matthias

wildenh
I'm new here

Hallo zusammen,

wir haben in unserem Projekt gerade das gleiche Problem. Redakteure haben Probleme mit der Freigabe und bekommen unter anderem die ID angezeigt.

Damit können Sie, ohne den Hinweis auf "fs.uid" zunächst mal nichts anfangen.

Das Problem ist natürlich, dass diese Redakteure

  1. nicht in die entsprechende Hilfe schauen würden
  2. sich soetwas auch nicht merken könnten.

Aus unserer Sicht wäre es also auch sinnvoll, dass diese Art Filter auch optisch ergänzt wird.

Z.B. als zusätzliche Checkbox wie sie es für "Meine Elemente" gibt.

mbergmann
Crownpeak employee
Crownpeak employee

Hallo,

mit einem Mini-Script bekommt man das gut hin. Das wäre übrigens einer der wenigen Fälle, wo ich sagen würde dass ein BSH-Script "vertretbar" wäre und man nicht zwingend ein Executable bzw. Modul bauen muss 😉

Falls es allerdings schon ein "allgemeines" Modul im Projekt gibt, wäre hier die Empfehlung das dort einzubauen (dann als Plugin).

Meine (schnelle) Lösung per BSH-Script sieht so aus:

1. Menüscript "Search by ID" erstellen mit folgender Sichtbarkeitsregel / Einblendelogik:

import de.espirit.firstspirit.access.BaseContext;

return context.is(BaseContext.Env.WEBEDIT);

2. Formular des Scripts

<CMS_MODULE>

  <CMS_INPUT_NUMBER name="sc_id" type="long">

    <LANGINFOS>

      <LANGINFO lang="*" label="ID"/>

    </LANGINFOS>

  </CMS_INPUT_NUMBER>

</CMS_MODULE>

3. Code des Scripts

import de.espirit.firstspirit.agency.OperationAgent;

import de.espirit.firstspirit.webedit.server.ClientScriptOperation;

import de.espirit.firstspirit.webedit.client.api.Report;

formData = context.showForm();

  if(formData==null) {

  return;

}

Long id = formData.get(null, "sc_id").get();

scriptOp = context.requireSpecialist(OperationAgent.TYPE).getOperation(ClientScriptOperation.TYPE);

String js = "top.WE_API.Report.show(\"Search\",{\"Pattern\":\"fs.id="+id+"\"},true);";

scriptOp.perform(js,false);

Im CC steht das Script dann unter "Aktionen" zur Verfügung. Es öffnet sich dann ein Formular in das man die ID einträgt. Beim "Speichern" wird eine Such-Query zusammengebaut und damit die FS-Suche aufgerufen.

Wenn man statt des "showForm" im Script den FormsAgent nutzt, könnte man den Dialog noch etwas passender machen (insb. den Button "Speichern" durch "Suchen" ersetzen).

Wichtig: Das geht aktuell nur im CC, da nur dort die FirstSpirit-Reports über die WE_API getriggert werden können - die reine Java-API kann nur eigene (also zusätzlich implementierte Reports) öffnen.

Viele Grüße

Michael

kohlbrecher
Crownpeak employee
Crownpeak employee

Hallo Matthias,

vielen Dank für deine Idee zur Verbesserung von FirstSpirit. Es ist uns wichtig, aus den Erfahrungen unserer Kunden und Partner zu lernen. Aus diesem Grund schätzen wir Feedback und freuen uns über jede Anregung.

Wir haben das Thema noch einmal evaluiert, haben aber keine Pläne, es in absehbarer Zukunft zu bearbeiten. Wie Michael oben bereits beschrieben hat, lässt sich das mittels eines Skripts gut lösen.

Detaillierte Informationen bezüglich des Auswahlprozesses der Requests, die wir umsetzen, haben wir in unserer Features Policy zusammengefasst.

Viele Grüße

Jan