Eingabe Validation´s

[Designer]

Hallo!
hab noch eine Frage:
wenn man in einem Feld nur Zahlen erlauben möchte, welche @Function gibt es zur EingabeValidierung.. hab das Feld als TEXT deklariert um auch führende Nullen anzeigen zu können!
-> PLZ- Field
kenne nur die EingabeValdidierung mit @Matches aber da muss man bereits eingeben, wieviele PLZ- Stellen man verlangt und das ist ja variable -> Ausland etc.

Würd mich sehr über Hilfe freuen!

Hättet Ihr sonst noch sinnvolle Input- Validation´s bei Standartforms z.b. Kunde außer Standart wie @Propercase(@Trim(@thisvalue))

würd mich über Tipps und Tricks freuen!
 

[koehlerbv]

Wenn Du auf nur numerische Werte prüfen willst, wäre @IsNumber die von Dir gesuchte Function - diese akzeptiert auch Strings als Wert und gibt wahr zurück, wenn sich der String in eine Zahl verwandeln liesse.

Für Deinen Zweck ist das auf nicht nur ungeeignet, sondern sogar falsch - britische Postleitzahlen kannst Du so zum Beispiel nicht mehr erfassen. M.E. lassen sich internationale PLZs über eine einfache Eingabevalidierung überhaupt nicht überprüfen.

Bernhard

[Designer]

oh, dann werde ich am besten auf eine EingabeValidation verzichten!
Vielen Dank!

[y20frank]

M.E. lassen sich internationale PLZs über eine einfache Eingabevalidierung überhaupt nicht überprüfen.

HA (!) bin daran auch gerade am rumdoktoren, DAS ist wirklich ein Prob ohne Ende! Versuche grade unseren Anschiften-Bestand (mit ca. 3 Mio Aderssen aus dem In- und Ausland) auf ein bestimmtes Niveau gerade zu ziehen, aber das ist ein gewaltiges, IMHO nicht zu bewältigendes Problem. Habe Anschriften aus Papua Neu Guinea, England, Sri Lanka, Zimbawe, Mali, USA, England, Malawi, New Zealand, Tuvalu, Österreich, Schweiz, Brasilien und wie sie alle heißen... *heul* und wie soll ich die auch nur ansatzweise auf eine gewisse Plausibilität prüfen,um gleiche Personen systemtechnisch zu "vereinen" - na ja, daran scheitere "ich" wohl gerade... ;-)

Man müsste quasi im Script erstmal den Land-Code abfangen um dann individuell eine Plausi auf gültige Postfachformate u.a. länderspezifische Formate einzugehen...  *puh*

[koehlerbv]

Jo, "puh". Das Thema ist extrem komplex.

Ein Weg könnte wirklich darüber gehen, die "Gesamtsituation zu verbessern", in dem man bekannte Regeln für bestimmte Länder für die Evaluierung benutzt - so, wie Du schon geschrieben hast. Sind die Regeln nicht bekannt oder (noch nicht) programmatisch berücksichtigt, fallen diese hinten herunter, wenigstens die anderen werden geprüft.

Dann folgt - allein für das Thema PLZ - das nächste Problem:
Die PLZ lautet PE28 2LU, das Land ist Grossbritannien. Ist diese PLZ syntaktisch okay ? Ja. Gibt es diese PLZ ? Ja, die gibt es (muss man aber irgendwo erstmal abgreifen !). Gehört diese PLZ zum Ort Portsmouth ? NEIN - das stimmt jetzt nicht.

Selbes Spiel für Deutschland: PLZ = 83312. Ist diese PLZ syntaktisch okay ? Ja. Gibt es die ? NEIN ! Was passiert, wenn mir mit dieser PLZ einen Brief schreibt ? Er wird trotzdem ankommen, zumindest mit sehr hoher Wahrscheinlichkeit. Gleiches wird passieren, wenn als PLZ nur 833 verwendet wird. Der Brief geht vielleicht einen Tag länger.

Das Problem ist aus meiner Sicht auf syntaktischer Ebene das geringste - die Plausibilität an sich stellt das Riesenproblem dar. Hinzu kommt das organisatorische Problem (Sorgfalt bei der Erfassung, Zwang zu bekannt gewordenen Korrekturen usw.).

Bernhard

[jr]

Hallo,

ich nehme an, Du hast im Dokument auch in irgend einer Weise das Land hinterlegt. In diesem Fall würde ich ein Konfigurationsdokument anlegen, dass für jedes Land die Validierung enthält, etwa

DE | @TextToNumber(val) <= 99999
UK | ...

Das Konfigurationsdokument wird dann mit dem Hauptdokument in ein  Berechnet zur Anzeige-Feld (hier sValidation) gelesen und dann in der Eingabevalidierung in der Art

land := @Trim(@Left(sValidation; "|"));
frml := @Trim(@Right(sValidation; "|"));
@If(@Eval(@Replace(sFeldname; land; frml)); @Success; @Failure("..."))

Das Konfigurationsdokument kannst Du dann nach belieben durch alle notwendigen Länder und Validierungen ergänzen.

Gruß,

Joachim

[koehlerbv]

DE | @TextToNumber(val) <= 99999
UK | ...

Joachim, wieder vielen Dank für Deinen Vorschlag - in sehr vielen Fällen wird der vielen, die ihn noch nicht kannten, behilflich sein, um Validierungen mit den R6-Möglichkeiten erheblich flexibler und lesbarer gestalten zu können.

Nur: Deine Formel für UK würde mich jetzt wirklich sehr interessieren 

Zurück zur Frage - ich will es mal provokativ formulieren: Lohnt der Aufwand ? Wir haben ja immer noch die von mir geschilderten Probleme (und das sind noch nicht alle) aus meiner Antwort#4. Wir müssen dabei auch die Probleme der "Gegenseite" (also dem Gilb) verstehen - und dessen Möglichkeiten (!).
Beispiele:
- Ein Brief nach 10439 Siegsdorf braucht drei Tage. Nachvollziehbar: 10439 ist Berlin.
- Ein Brief nach 833 Siegsdorf braucht einen Tag (danke, liebe Software-Entwickler der Post !)
- Ein Brief nach 83313 Siegsdorf (korrekt!) AUSTRIA (ooops - wenn auch nur knapp daneben) braucht genau eine Woche (aus GB). Danke, Post Austria und Post Deutschland - denn die deutschen bekamen als Aufdruck auf den Brief dann auch nur "Irrläufer" (oder so). Aber - es kam an !
- Für mich bis heute der Hammer: Brief an meinen Vater aus den USA. Die denken wohl, Deutschland ist die kleine Alm zwischen Mittelmeer und Nordmeer. Anschrift: "Prof Koehler, Jena." Post ist schlau und gibt Brief zur Schiller-Universität. Die stellen fest: Es gibt drei Professerores dieses Namens in Jena. Der, der nicht mehr zu Uni gehört (emeritiert), bekommt ihn als erster - mein Vater (meine Vermutung: Im Absender stand was von WHO - dann haben es sich die Menschen in der Uni-Poststelle zusammengereimt. Bravo !) Laufzeit: Erstaunlich kurz.
- Und der andere Fall: Ein Brief mit vollkommen korrekter Anschrift (dieser wurde dann erfolgreich als "Beschwerdesendung erneut versendet) geht innerhalb Deutschlands wieder an den Sender zurück. Und die Adressierung war wirklich normgerecht und maschinenlesbar (und es war das x-te Schreiben, was dann mal zum Fehler führte). Beim zweiten Mal hat es dann ja auch geklappt.

Daher: Lohnt der Aufwand ? Zumindest innerhalb einer Eingabevalidierung, meine ich damit.

Bernhard

[Marinero Atlántico]

Ich hab mal nach einer out of the box Komponente gefragt.
http://saloon.javaranch.com/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic&f=1&t=011267

[koehlerbv]

Hallo Axel,

ich wollte die Diskussion jetzt eigentlich mal auf den Stand der Brauchbarkeit bringen und habe das durch umfangreiche Beispiele erläutert. Da wird auch im Saloon der Javaranch am Problem kaum gedeutelt werden können 

Keine Ahnung, wie das heute gerade aktuell im Wettlauf der Wordings heisst, ich sach' jetzt mal: "Nützlichkeit". Und das sagt:

Vorab:
"Designer" hat einen Tipp bekommen, wie man prinzipiell Validierungen baut (in Notes). Vielleicht hat ihm das schon geholfen. Sonst wird er sich wieder melden.

Derzeit diskutieren wir nun das PLZ-Thema, was ich durchaus für spannend halte (derzeit glücklicherweise in einer Situation, in der ich das als allgemeines und nicht als mein eigenes Problem annehmen kann). Ich denke, das wir alle hieraus Gewinn ziehen können - allein schon durch den Austausch der Ideen, Ansätze und Erfahrungen.

Für die von mir bisher bereisten Länder ist es möglich, die PLZ zu normieren, wenn man auf die Anzahl der Zeichen schielt. Deutschland = 5, Dänemark = 4, Autriche - quatre points, äh auch vier Stellen, Russland hat ... wer weiss es ?? Richtig. 6 Stellen.

Ad a) Es ist sehr einfach, sowas programmatisch umzusetzen
Ad b) Es ist sehr schwer, alle Regeln für alle in Frage kommenden Länder zu formulieren (die britische ist sicher auch gegeben, aber erstmal schwer nachvollziehbar und da ist nix mit "GB hat x Stellen für eine PLZ")
Ad c) Eine formal richtig gebildete PLZ muss zu nicht einem einzigen Ort gehören (Beispiel D-83312)
Ad d) Eine falsche, aber ähnliche PLZ kann auch den Postverteilzentren helfen (die haben aus gutem Grund in die grossen und guten System für DIESEN Zweck investiert)
Ad e) Ein Brief mit einer völlig falschen PLZ kommt in fast 100% der Fälle auch an.

Daher nochmal meine Frage: An welcher Stelle bzw. in welcher Situation soll welcher Aufwand betrieben werden ? Das ist doch eher die Frage, und in diesem Zusammenhang auch: Wie wird sichergestellt, dass erkannte Fehler im Datenbestand korrigiert werden ? Hier trifft sich Technik und Organisation (und die Kalkulatoren des berühmten "ROI"  )

Bernhard

[Marinero Atlántico]

Keine Ahnung, wie das heute gerade aktuell im Wettlauf der Wordings heisst, ich sach' jetzt mal: "Nützlichkeit". Und das sagt:

Hallo Bernhard,

Das ist für mich schon durchaus eine ernsthafte Frage. Da eine Menge Anwendungen Postleitzahlen validieren (auch für mehrere Länder), wäre es durchaus sinnvoll, dass irgendjemand das als Komponente anbietet. Und das ist für mich eine interessante Information.
Fast eine Geschäftsidee, wenn es das nicht gibt...
Als in Java und .NET einbindbare Regular Expressions. Per Webservice werden Informationen über Änderungen zur automatisierten Aktualisierung bei den Usern bereitgestellt.
Sinnvoll wäre auch ein Datenbestand, der Orte auf Postleitzahlen Map und gegen den man überprüfen kann, ob der Ort tatsächlich zur PLZ passt.
<amRande>
Marketingabteilungen können sogar Datenbestände kaufen, wo gesetzkonform die Kaufkraft von Adressen - runtergebrochen auf 5 aggregierte Haushalte - überprüft werden kann. Leute mit einer ungünstigen Adresse bekommen von einigen Anbietern keine Hochglanzbroschüren.
</amRande>
Careful 
In Versailles galten 1788 Wordings wie "Liberté - Egalité - Fraternité" auch als neuodische, nutzlose und inhaltsleere Begriffe.   

Axel

[jr]

Guten Morgen,

die oben angegebene Validierungsmöglichkeit mit einem Konfigurationsdokument sollte eine Anregung sein, wie man solche Herausforderungen angehen kann. Reguläre Ausdrücke mit @Matches sind da genau so möglich wie jede andere Überprüfung mit mehreren & und | Verknüpfungen.

Aber Bernhard hat 100%ig Recht, wenn er die Frage aufwirft, ob das überhaupt sinnvoll ist. Ganz allgemein bin ich der Meinung, dass gerade im Bereich Eingabevalidierung viel zu viel Programmiert wird. Wenn ein Wert für andere Berechnungen relevant ist, dann ist die Validierung wichtig und notwendig. Wenn es aber nur um "kosmetische" Dinge geht, dann stellt sich häufig die Frage, ob man da den Benutzer überhaupt aus der Verantwortung nehmen soll. Im Falle der Postleitzahl "denkt" sich der Benutzer ja irgend etwas dabei, wenn er sie eingibt. "D-12345" ist ja zum Beispiel auch eine gültige deutsche Postleitzahl und ein Benutzer, der viele ausländische Adressen benutzt, wird häufig auch für die deutschen Adressen das D- voransetzen.

Der Aufwand um alle Eventualitäten abzufangen steht häufig in keiner Relation zum tatsächlichen Nutzen.

Eine andere Diskussion ist es, wenn ein solcher Wert in einer kategorisierten Ansicht auftaucht, denn es ist ärgerlich und wenig hilfreich, wenn Adressen mit der gleichen PLZ 12345 in 3 verschiedenen Kategorien auftauchen (12345, D-12345, D 12345). In einem solchen Fall würde ich die Validierung tatsächlich konkret machen.

Bei der Volltextsuche dürfte das dann allerdings wieder kein Problem darstellen, da hier mit der richtigen Suchabfrage alle Adressen gefunden werden.

Gruß,

Joachim

[Semeaphoros]

Da zeigt sich aber auch die Problematik von einer anderen Seite:

"D-12345" ist eine gültige deutsche Postleitzahl.

Hm, "deprecated", sollte DE-12345 sein (ISO-konforme Kürzel) und ganz aktuell sollte man umstellen auf

12345 Ortsname
Deuschland

dabei das Land in der Landessprache oder französisch angeben.

Leider finde ich den Link zur vollständigen Info nicht mehr, Axel M. Atlantico hatte schon kürzlich danach gefragt .....