Längenprüfung (name="LENGTH") von CMS_INPUT_NUMBER

0 Kudos

Hallo zusammen,

ich wollte ein Eingabefeld definieren, in welchem nur eine 10-stellige Nummer zugelassen ist und hatte entsprechend eine CMS_INPUT_NUMBER Eingabekomponente definiert, welches ich über die Regeln ON_SAVE validieren wollte, da dies anschließend in Datenquellen eingepflegt werden kann. Dies wäre besonders bei Artikel-, oder Produktnummern interessant, die eine feste Länge haben.

Nun hatte ich folgende Regeln aufgebaut:

<ON_SAVE>

      <WITH>

           <EQUAL>

                <PROPERTY source="tt_xvariable" name="LENGTH" />

                <NUMBER>10</NUMBER>

           </EQUAL>

      </WITH>

      <DO>

           <VALIDATION>

                <PROPERTY source="tt_xvariable" name="VALID" />

                <MESSAGE lang="*" text="bitte eine 10-stellige Nummer eintippen" />

           </VALIDATION>

      </DO>

</ON_SAVE>

Welche leider nicht gegriffen hat, da ich die Länge von dem CMS_INPUT_NUMBER nicht abfragen konnte, sondern nur den VALUE.

Aber weil ja auch Werte wie "0000000001" zugelassen sind, jedoch keine "1" konnt ich keinen Bereich an Zahlen definieren, die in

der Regel von 0000000001 bis 9999999999 abgefangen werden können, weil im CMS_INPUT_NUMBER 0000000001 = 1 ist.

Nun fange ich die 10-stellige Nummer folgendermaßen ab:

<ON_SAVE>
<WITH>
<MATCHES regex="[0-9]{10}">
<PROPERTY source="tt_xvariable" name="VALUE" />
</MATCHES>
</WITH>
<DO>
<VALIDATION>
<PROPERTY source="tt_xvariable" name="VALID" />
<MESSAGE lang="*" text="bitte eine 10-stellige Nummer eintippen" />
</VALIDATION>
</DO>

    </ON_SAVE>

Nur leider ist diese Eingabekomponente keine INPUT_NUMBER mehr, sondern eine INPUT_TEXT Eingabe und auch der Datentyp in der Datenbank ist entsprechend zu einem String geworden, anstelle eines Integer.

Eine Längenprüfung für INPUT_NUMBER wäre an dieser Stelle sehr hilfreich gewesen, damit der richtige Datentyp verwaltet werden kann.

4 Comments
StefanSchulz
I'm new here

Eine zehnstellige Ziffernfolge ist in diesem Zusammenhang aber doch keine Zahl. Dann müsste die Komponente ja auch wissen, dass die gespeicherte Zahl um entsprechende Nullen nach vorne aufgefüllt wird, damit der Wert für die Regeln wieder gültig ist. Oder speichert die Datenbank hier führende Nullen bei Zahlentypen?

Wieso ist die Textkomponente hier nicht ausreichend? Eine Umwandlung in eine Zahl kann ja an den Nutzerstellen vorgenommen werden, oder nicht? Wird der Typ Zahl in diesem fall fachlich überhaupt benötigt?

Domberg
Occasional Observer

Zumindest wäre in dem Template die Bezeichnung der Eingabekomponente korrekter, bzw wüsste man, um welche Art Daten es sich handelt, ohne die Regel zu analysieren. In MySQL gibt es ja auch den INT(10) Zerofill. Außerdem wird schon bei der Eingabe jegliche Art von Sonderzeichen und Buchstaben nicht zugelassen, da die Eingabe erst gar nicht stattfindet und wirft keine Warnung aus.

So könnte man einheitlicher mit den o.g. Artikelnummern etc. arbeiten. In einer Abfrage könnte man beispielsweise auch Artikel von Nr. xxxx100000 bis Nr. xx20000000 abfragen. Dies kann man auch umgehen, jedoch wäre es ein Umweg.

Die Speicherung von Integer mit vorangehenden Nullen habe ich gerade mal getestet und dort werden diese auch abgeschnitten.

pjodeleit
e-Spirit employee

Geht es dir um die Darstellung des Wertes? Dann kannst du doch den Parameter "format" in der Konfiguration benutzen und (wenn benötigt) in der generierten Seite auch entsprechend ausgeben. Oder übersehe ich etwas?

kohlbrecher
e-Spirit employee

Hallo Dominik,

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 und wie Stefan und Peter bereits geschrieben haben, gibt es Möglichkeiten, wie deine Idee auch ohne Anpassungen in FirstSpirit umgesetzt werden können. Daher gibt es keine Pläne, es in absehbarer Zukunft zu bearbeiten. Daher können wir deinen Feature Request zum aktuellen Zeitpunkt leider nicht berücksichtigen.

Genauere Information zum Auswahlprozess der Verbesserungen die wir umsetzen findest du in unserer Features Policy.

Viele Grüße

Jan