hallo,
wie kann ich prüfen, ob ein richtextfeld leer ist oder nicht, bevor ich das dokument abgespeichert habe?
grüße,
rösing
hallo,
wie kann ich prüfen, ob ein richtextfeld leer ist oder nicht, bevor ich das dokument abgespeichert habe?
grüße,
rösing
Kannst Du meines Wissens nach nur per Script machen, beispielsweise im QuerySave. Oder eben in einer Schaltfläche, je nachdem, was Du vorhast.
die validierung sollte im browser geschehen.
muß ich also doch javascript anwenden.
ich würde es aber lieber serverseitig machen.
schade.
grüße,
rösing
Hallo,
Frage.
Warum willst Du denn kein JavaScript verwenden?
Ist doch weitaus schneller als die Daten erst an den Server senden, pruefen und dann wenn Fehler wieder an den Client mit einer Meldung zurueck und das Dokument erneut anzeigen.
Andreas
Weil es Leute geben mag, die JavaScript grundsätzlich auschalten? Und weil in diesem Falle eine wie auch immer dahintergeschaltete Logik auf die Bretter gehen würde?
ZitatWeil es Leute geben mag, die JavaScript grundsätzlich auschalten? Und weil in diesem Falle eine wie auch immer dahintergeschaltete Logik auf die Bretter gehen würde?
deshalb.
gibt es andere möglichkeiten?
grüße,
rösing
Vor dem Abspeichern: Im Web ohne JavaScript nicht möglich.
Du kannst nur einem WebQuerySave Agenten das Feld prüfen und dann eben eine Fehlermeldung zurückgebenmit der das gerade gespeicherte Dokument neu angezeigt wird.
Wenn du allerdings Feldvalidierungen machen willst im Web solltest du wirklich nicht JavaScript vermeiden.
Und wenn hinter dem Save Button auch JavaScript liegt kann man es ohne aktiviertes JavaScript nicht abspeichern.
Wer dann immer noch meint es deaktivieren zu müssen bei eurer Applikation ist selber schuld
Zitat
Wer dann immer noch meint es deaktivieren zu müssen bei eurer Applikation ist selber schuld
Du gehst in dem Fall davon aus, dass es sich um eine Anwendung handelt, auf die nur hausinterne User zugreifen. Mag schon so sein, ist aber nicht explizit bestätigt.
Hausintern hab ich auch JavaScript an (:würg:), zu Hause aber werd ich den Teufel tun, irgendwem zu vertrauen. Von daher idt die Alternative, Daten zweimal hin und her zu schicken nur auf den ersten Blick krude. Der Sicherheit tuts -je nach Umgebung- definitiv gut. Und seien wir mal ehrlich: bei Leitungen heutigen Standards machts nicht wirklich was aus, oder?
Nein davon gehe ich nicht aus, aber wer wo was eingeben will und nicht mal eine Feldvalidierung per JavaScript zulässt bei dem sehe ich das sehr wohl so.
Klar könnten wir uns immer noch in der Webtseinzeit aufhalten wo alles serverseitig validiert wird, aber ein vernünftiges Userinterface im Web arbeitet nun mal mit JavaScript
also mit JavaScript ist es für den User komfortabler. Allerdings muss dann trotzdem nachmal auf dem Domino geprüft werden, d.h. ich schreib den gleichen Code in 2 verschiedenen Sprachen.
Mittlerweile spar ich mir den JavaScript-Teil und schreib nur noch einen LotusScript-Agenten fürs WebQuerySave. Das Dokument bekommt dann ein Flag, welches sagt, ob die Validierung erfolgreich war oder nicht und dieses Dokument wird gespeichert.
War die Validierung nicht i.O., wird über das Flag das Dokument in allen Ansichten versteckt und der User bekommt angezeigt was nicht i.O. war und einen Link auf sein Dokument im EditMode.
Ein periodischer Agent löscht alle geflagten Dokumente, die älter als x Tage (bei mir 28 Tage) sind.
Ggf. kannst Du dem User auch anzeigen, welche nicht richtig ausgefüllten Dokumente er noch besitzt.
Gruß
Dirk
Zitat
taurec schrieb:
Nein davon gehe ich nicht aus, aber wer wo was eingeben will und nicht mal eine Feldvalidierung per JavaScript zulässt bei dem sehe ich das sehr wohl so.
ROFL! Klar, warum auch den schönen Server belasten, wenn man alles auf den Client abwälzen kann. 16k-DSL und QuadCore-CPUs machens möglich. Ich für meinen Teil habe noch einen 233er Pentium und liebe den Lynx. Und 3k ausgeben, damit ich das tun kann, was ich jetzt für umme tun kann? Ich sehe es absolut nicht ein, dass ich die Arbeit der Anbieter zu machen habe. Davon einmal abgesehen, gab es in der "guten alten Zeit"(TM) kein Sicherheitslücken durch JavaScript, ActiveX, Flash und sonstigen Mumpitz. Wer seine Inhalte nicht so aufbereiten kann, dass sie ohne Zutun des Clients abruf- und/oder verarbeitbar sind und/oder auf viel Bunt setzten muss, der hat ganz andere Probleme, als die Eingabevalidierung-
Zitat
Klar könnten wir uns immer noch in der Webtseinzeit aufhalten wo alles serverseitig validiert wird, aber ein vernünftiges Userinterface im Web arbeitet nun mal mit JavaScript
Zuerst hieß das Ding einfach nur ARPANet und es haben sich nur Profis drin getummelt. Dann hieß es irgendwann Internet und die ersten DAUs kamen angerauscht und mussten unbedingt in die Welt rausblähen, dass sie Karl-Heinz heißen, am liebsten Spaghetti essen und ihren Hund Rover nennen. Selbstverständlich wurde dann -um Aktivität und Wichtigkeit vorzutäuschen- an jeder Ecke ein animated gif "Under Construction" hingepflanzt. Dann wars den DAUs irgendwann nicht mehr DAU-ig genug, weil sie ihre Webpages ja mittlerweile sogar mit MS Word zusammenkleistern konnten, also wurde das Buzzword "Web 2.0" erfunden und somit JavaScripot und jegliches Klicki-Bunti Einfallstor für Unfug zum Must-Have erklärt. Die Profis haben sich mittlerweile soweit zurückgezogen, dass sie von den DAUs bestenfalls die gröbsten Unfälle mitbekommen und lachen herzhaft über sie. Und da eine Website nicht nur mit Klicki-Bunti verhunzt werden musste, sondern alles auch noch dynamisch zu sein hat, haben wir nun auch noch SQL-Injection, Cross-Site-Scripting und was weiß ich noch alles.
Eins ist doch klar: ist die eine Sau durchs Dorf getrieben worden, muss ganz schnell eine neue her oder uns allen fällt der Himmel auf den Kopf. Wenn wir nichts mehr haben, was wir hypen können und wo wir uns ganz dolle wichtig und technisch begabt vorkommen können, was bleibt uns dann noch? Also, was kommt nach Web 2.0? Web 3.11 for Workgroups? Sagt mir Bescheid wenn wir bei Web Vista sind, aber ich hoffe, vorher hat uns Skynet platt gemacht. Verdient hätten wirs dann endgültig...
Sorry für den Rant, der doch gewaltig am Thema vorbei ging. Hier ist auch nicht der Platz für eine solche Grundsatzdiskussion. Aber mit diesen so resolut vorgetragenen Thesen gehe ich schlicht nicht konform, weil sie doch bestenfalls zu kurz gegriffen sind. Die Methode von Dirk scheint mir doch die bessere. Nicht nur aus Sicherheitsgründen, sondern weil man als Entwickler mit Hilfe der fehlerhaften Dokumente sehen kann, wo es noch hapert in der Applikation, wo User gehäuft Fehleingaben machen, weil sie evtl. schlicht nicht verstehen, was von ihnen verlangt wird.
*Grins Dann verwendest du sicher auf allen Rechnern ausschliesslich Kommandozeile und lässt an jeglichen Computer auch keinen ran, der damit nicht umgehen kann.
Klar kann man so argumentieren, nur geht das an der aktuellen Realität vorbei, wo eben der Haupttteil der Benutzer oberflächenorientiert sind.
Du kannst heute auch nicht erwarten, daß z.B. ne Sekretärin Kundendaten per SQL Statements pflegt.
Nur die Frage des Posters war wie kann er es im Web prüfen bevor es abgespeichert wird und das ist eben nur auf dem Client möglich.
Genauso wie es bei Notes Applikationen im übrigen auch ist.
Da macht ebenfalls der Client die Feldvalidierungen und nicht der Server