Search the FirstSpirit Knowledge Base
Hallo Community,
ich habe folgende Zeile in einer Verweisvorlage:
$CMS_SET(set_lt_text)$$CMS_VALUE(text,default:"")$$CMS_END_SET$ |
Das Text-Feld dazu ist ein Pflichtfeld:
<CMS_INPUT_TEXT name="text" allowEmpty="no" hFill="yes" singleLine="no" useLanguages="no"> <LANGINFOS> <LANGINFO lang="DE" label="Linkbezeichnung"/> <LANGINFO lang="*" label="Link text"/> </LANGINFOS> </CMS_INPUT_TEXT> |
Nun ist das Feld in manchen Fällen trotzdem nicht gefüllt. Bei der Generierung tritt dann folgender EmptyNotAllowedException Fehler auf:
ERROR 30.05.2012 12:16:57.908 (de.espirit.firstspirit.client.access.link.LinkImpl): cannot set text to ''
de.espirit.firstspirit.access.editor.value.EmptyNotAllowedException: Must not be empty! Editor: text, Type: de.espirit.firstspirit.client.access.editor.TextEditorValueImpl.
Warum ist das so und wie kann ich diese Log-Ausgabe verhindern?
Viele Grüße,
C. Klingbeil
Server-Version: 4.2.468.50982
Hallo Frau Klingbeil,
ich habe das beschriebene Problem aufgenommen. Die interne ID lautet: #119672.
Viele Grüße,
Sascha Rusch
Hallo Frau Klingbeil,
sie müssten den Vorgabewert unter dem Tab "Eigenschaften" der Verweisvorlage definieren. Ich vermute aber, dass "" nicht als Vorgabewert hinterlegt werden kann, da es ja "empty" ist und laut dem Formular nicht erlaubt ist.
Wenn sie aber im Ausgabekanal einen Default-Wert setzen, können sie doch auch ganz auf das allowEmpty="no" verzichten.
Viele Grüße
Thorsten Marx
Hallo Herr Marx,
das ist so nicht ganz richtig. Das allowEmpty="no" zwingt den Redakteur dazu, Pflichtfelder zu füllen und visualisiert das Pflichtfeld durch den roten Rahmen. Des Weiteren werden diese Pflichtfelder in den Workflows geprüft. Also können wir nicht auf allowEmpty="no" verzichten.
Die Wertzuweisung über default:'' soll ja die NullPointerException bei nicht gefüllten Elementen verhindern. Das klappt ja auch. Die Variable text ist nicht NULL. Aber text ist empty, was anscheinend durch allowEmpty="no" nicht sein darf. An dieser Stelle habe ich eine unangenehme Verknüpfung von Formularlogik mit Generierungslogik, die m.E. so nicht sinnvoll ist. Schon gar nicht, weil es ein ERROR und keine WARNING ist, obwohl das System ein Speichern des Leerwerts im Formular zulässt.
Wie verändere ich denn nun sinnvoll meinen Code, dass weder NullPointer noch EmptyNotAllowed Exceptions kommen? Mir fällt hier leider nur die unschöne Lösung über die Wertzuweisung eines einzelnen Spaces ein. Die war aber nicht das Ziel 😞
Viele Grüße,
C. Klingbeil
Das sieht für mich nach einem Bug aus. Kannst du den Trace hier posten?
Tritt das erst seit dem Wechsel zu Version 4.2.468 auf?
Guten Morgen 🙂
Seit wann der Fehler genau auftritt, weiß ich nicht, da er erst kürzlich bemerkt wurde. Es könnte auch die Version vor der 468 gewesen sein. In noch früheren Version war er mit ziemlicher Sicherheit noch nicht vorhanden, denn wir hatten schon Generierungslogs ohne Fehler 😉
Den Stacktrace habe ich angehängt.
Viele Grüße,
C. Klingbeil
Noch eine Frage: Ist die Eingabekomponente "text" im Link-Formular als "nicht leer" definiert? Wenn ja, tritt der Fehler auch auf, wenn man diese Restriktion entfernt? Und wurde das erst "kürzlich" geändert?
Der Trace sieht so aus, als ob dies ein Link ist, der noch im alten Format gespeichert ist und der Wert für das Feld "text" ist leer. Was vom Formular abgewiesen wird...
[EDIT]
Das mit dem "nicht leer" steht ja schon weiter oben, auch das dies so sein soll. Bleibt die Frage, ob erst seit der Umstellung auf "nicht leer" zu dem Fehler kommt. Und eventuell kannst du ja trotzdem probieren, ob der Fehler auch auftritt, wenn man "leer" wieder zulässt.
Hallo Frau Klingbeil,
ich habe das beschriebene Problem aufgenommen. Die interne ID lautet: #119672.
Viele Grüße,
Sascha Rusch
Natürlich tritt der Fehler nicht auf, wenn allowEmpty="yes" definiert ist 😉
Hallo Herr Rusch,
wie schaut denn der Status bei dem Defect aus? Gibt es schon Neuigkeiten?
Viele Grüße,
C. Klingbeil
Hallo Frau Klingbeil,
vielen Dank für Ihre Antwort .
Leider gibt es noch keine Neuigkeiten.
Wenn Sie über die Veröffentlichung der Änderung informiert werden möchten, erstellen Sie bitte ein Helpdesk-Ticket und geben Sie dort bitte die interne ID #119672 an.
Vielen Dank und viele Grüße,
Sascha Rusch