CMS_INPUT_DATE Vorbelegung bei OnRelease Regel
Author: pstute
Publication Date: 2/15/2019 7:17
Hallo Community,
ich habe folgende Konstellation:
<CMS_INPUT_DATE name="tt_startdate" hFill="yes" mode="datetime" noBreak="yes" singleLine="no" useLanguages="no">
<LANGINFOS>
<LANGINFO lang="*" label="Startdatum"/>
</LANGINFOS>
</CMS_INPUT_DATE>
<RULE>
<WITH>
<NOT>
<PROPERTY name="EMPTY" source="tt_startdate"/>
</NOT>
</WITH>
<DO>
<VALIDATION scope="RELEASE">
<PROPERTY name="VALID" source="tt_startdate"/>
<MESSAGE lang="*" text="Dieses Feld darf nicht leer sein!"/>
</VALIDATION>
</DO>
</RULE>
Beim Anlegen eines Datensatzes ist das Feld tt_startdate ein Pflichtfeld bei onRelease.
Wenn der Redakteur nun einfach nur einen Datensatz anlegt ohne das Feld manuell mit einem Datum zu belegen und aus dem Editiermodus herausgeht, wird automatisch in das Feld tt_startdate der Standardwert 01.01.1970 01:00 vorbelegt.
Dadurch wird der Sinn der Validierung ausgeschaltet, da der Redakteur ja daran erinnert werden soll, das Datum zu setzten bevor er frei gibt. Wenn allerdings nun das Standarddatum eingetragen wurde, könnte der Redakteur den Datensatz ohne erneute Prüfung mit dem Standarddatum freigeben.
Laut Dokumentation zu CMS_INPUT_DATE:
Im Modus date wird zu dem Datum, das der Redakteur auswählt, standardmäßig die Uhrzeit "00:00" (UTC) gespeichert, im Modus time wird zu der Uhrzeit, die der Redakteur auswählt, das Datum "01.01.1970" gespeichert. Diese Informationen werden allerdings in der Eingabekomponente nicht visualisiert.
Habe ich beim Anlegen etwas übersehen damit das Standarddatum nicht eingetragen wird?
Viele Grüße,
Patricia
-
Author: hbarthel - 2/15/2019 19:35
Wie ist die zugehörige Spalte im DB-Schema definiert?
0 -
Author: pstute - 2/18/2019 7:16
Hallo Heiko,
hier die Referenzierung und die Tabelle:
Noch zur FS-Version: 2018-09
Viele Grüße,
Patricia
0 -
Author: hbarthel - 2/18/2019 14:33
Es klingt so, als hättest du startDate als Pflichtfeld (also NOT NULL) in der DB definiert, auch wenn ich das im Screenshot jetzt nicht erkenne (müsste rot dargestellt sein).
0 -
Author: pstute - 2/19/2019 5:49
Hi,
wenn ich mir die Tabelle auf DB-Ebene ansehe sind die Spalten als IS_NULLABLE = YES eingetragen.
Viele Grüße,
Patricia
0 -
Author: hbarthel - 2/19/2019 7:41
Hallo Patricia,
ich habe das Verhalten mit der integrierten Derby und einer externen Oracle-DB nur nachstellen können, wenn die Spalte als Pflichtfeld deklariert ist. Welches DBMS benutzt Du? Und um ganz sicher zu gehen: kannst du mal das FS-DB-Schema extern bearbeiten (Schema in edit-mode, dann Kontextmenü auf dem Schema-Knoten im Templatestore -> edit externally) und die Tabellendefinition hier posten. Sowas hier:
<xs:element dbName="STARTDATE" javaType="java.util.Date" name="startDate" nullable="1" type="xs:date"/>
Du hast nicht aus Versehen einen default im Formular eingestellt (dann müsste das Feld aber auch schon beim Öffnen befüllt sein und nicht erst beim Speichern hintenrum befüllt werden)?
Gruß Heiko
0 -
Author: pstute - 2/19/2019 7:47
Hi,
hier der Auszug aus dem DB-Schema:
<xs:element dbName="TT_ENDDATE" javaType="java.util.Date" name="tt_enddate" nullable="1" type="xs:date"/>
<xs:element dbName="TT_STARTDATE" javaType="java.util.Date" name="tt_startdate" nullable="1" type="xs:date"/>
Wir benutzen folgendes:
Oracle DB 11.2.0.2.0
Treiber 12.2.0.1.0
Als Default-Wert ist nichts hinterlegt.
Viele Grüße,
Patricia
0 -
Author: hbarthel - 2/19/2019 7:58
Dann habe ich keine Idee mehr und bin gespannt zu erfahren, was die Ursache ist/war, wenn du das gelöst hast.
Ich glaube, ich würde jetzt erstmal probeweise ein Spielprojekt anlegen und das mal isoliert versuchen nachzustellen.
0 -
Author: hoebbel - 2/21/2019 8:13
Hallo Patricia,
Wir benutzen folgendes:
Oracle DB 11.2.0.2.0
Treiber 12.2.0.1.0
es könnte daran liegen, dass ein Oracle 12 Treiber mit einer Oracle 11 Datenbank genutzt wird. Es kann auch an der Datenbank-Konfiguration liegen.
Man kann jetzt entweder versuchen, die Ursache zu ermitteln, oder man reagiert einfach pragmatisch auf das aktuelle Verhalten, indem man die entsprechenden Datumseinträge ebenfalls als "nicht korrekt" interpretiert.
Dazu könnte an die Regel so anpassen, dass der 1.1.1970 auch als Fehler angesehen wird, z.B. so:
<RULE>
<WITH>
<NOT>
<OR>
<PROPERTY name="EMPTY" source="tt_startdate"/>
<LESS_THAN>
<PROPERTY name="VALUE" source="tt_startdate"/>
<DATE>1971-01-02 12:00:00</DATE>
</LESS_THAN>
</OR>
</NOT>
</WITH>
<DO>
<VALIDATION scope="RELEASE">
<PROPERTY name="VALID" source="tt_startdate"/>
<MESSAGE lang="*" text="Ein gültiges Datum wird benötigt!"/>
</VALIDATION>
</DO>
</RULE>
Das würde alle Datumseinträge vor dem 2.1.1970 als fehlerhaft interpretieren [damit werden dann auch alle unterschiedlichen Zeitzonen abgedeckt, falls es Redakteure gibt, die in anderen Zeitzonen arbeiten]. Hat aber natürlich den Nachteil, dass der Redakteur entsprechende Datensätze nicht freigeben kann, wenn ein Datum vor 1970 tatsächlich benötigt wird. In dem Fall wäre es sinnvoller, die Ursache des Problems zu ermitteln.
Viele Grüße,
Holger
0
Vous devez vous connecter pour laisser un commentaire.
Commentaires
8 commentaires