Richtextfeldvalidierung vor abspeichern eines Dokumentes

  • Kannst Du meines Wissens nach nur per Script machen, beispielsweise im QuerySave. Oder eben in einer Schaltfläche, je nachdem, was Du vorhast.

  • 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?

    Life is not a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside, thoroughly used up, totally worn out, and loudly proclaiming "Wow, what a ride!!! :evil:
    Beschleunigung ist, wenn die Tränen der Ergriffenheit waagrecht zum Ohr hin abfliessen - Walter Röhrl

  • Zitat

    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?


    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?

    Life is not a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside, thoroughly used up, totally worn out, and loudly proclaiming "Wow, what a ride!!! :evil:
    Beschleunigung ist, wenn die Tränen der Ergriffenheit waagrecht zum Ohr hin abfliessen - Walter Röhrl

  • 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

    • Offizieller Beitrag

    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

    Rein logisches Denken verschafft uns keine Erkenntnis über die wirkliche Welt.
    Alle Erkenntnis der Wirklichkeit beginnt mit der Erfahrung und endet mit ihr.
    Alle Aussagen, zu denen man auf rein logischen Wegen kommt, sind, was die Realität angeht, vollkommen leer.
    Albert Einstein

  • 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.

    Life is not a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside, thoroughly used up, totally worn out, and loudly proclaiming "Wow, what a ride!!! :evil:
    Beschleunigung ist, wenn die Tränen der Ergriffenheit waagrecht zum Ohr hin abfliessen - Walter Röhrl

  • *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