Toon posts:

Gegevens behouden bij het teruggaan (in ASP)

Pagina: 1
Acties:

Verwijderd

Topicstarter
Ik ben een site aan het bouwen. Hierin heb ik een formulier gemaakt. De bedoeling is dat na het invullen van dit formulier je op een nieuwe pagina terecht komt(dit werk al). Vervolgens heb ik op die nieuwe pagina een foutmelding gemaakt dat het formulier niet helemaal goed is ingevuld. Het moet dan mogelijk zijn om via een knop terug te gaan naar het formulier. Dit formulier moet dan de oude waarden bevatten.

Alvast bedankt

  • eborn
  • Registratie: April 2000
  • Laatst online: 08-09 12:50
Het is denk ik makkelijker om gewoon weer het oude formulier te laten zien, met alle velden ingevuld, en een foutmelding erboven. Dan hoef je niet nog iemand door te sturen.

Verwijderd

Topicstarter
Op donderdag 04 april 2002 11:09 schreef eborn het volgende:
Het is denk ik makkelijker om gewoon weer het oude formulier te laten zien, met alle velden ingevuld, en een foutmelding erboven. Dan hoef je niet nog iemand door te sturen.
Hoe doe je dit?? Dit lijkt me ook de goede oplossing. Maar wanneer je op de knop klikt om het formulier te versturen gaat ie naar een andere pagina (de verwerkingspagina van het formulier). Hoe krijg ik het voor elkaar dat de foutmelding boven het formulier komt te staan en dat de gegevens dus blijven staan, zoals jij zegt?

  • Glimi
  • Registratie: Augustus 2000
  • Niet online

Glimi

Designer Drugs

(overleden)
Neem een hidden variable op in het forumlier. Als het formulier gesubmit wordt naar de pagina zelf, dan gaat deze variable dus een waarde bevatten.

In de pagina neem je dan code op die checkt of de hidden var geset is en als dat zo is, dan de controle logica gaat uitvoeren, en evt foutmeldingen dropt.

Verwijderd

Dit is een van de naarste zaken die je kunt bedenken bij webdevelopment. In ASP.NET hebben ze dat gelukkig opgelost, in ASP moet je het zelf doen. Er is niet echt een goede oplossing, dwz alle oplossingen vereisen een of andere vorm van ellende die je liever vermijdt.

Ik gebruik voor dit soort dingen OF het session object (wanneer het een klein form betreft) of een dictionairy object in het session object (wanneer het een groot form betreft). Vooral dat laatste is volgens sommigen een slechte oplossing, maar je ontkomt er niet aan, imho.

Wat je doet is: (ik zeg het even simplistisch, veelal initieer je sessionvariables bij het inloggen / attachen van een user)
in de page die voor het form zit (dus waar vandaan je het form benadert) creeer je een boolean variable in je session, bErrorOccured, zet die op false. Creeer een dictionairy object, creeer voor elk formfield een key-value pair met de default value, en plaats het dictionairy object in je sessionobject.

De user komt op het form, je controlleert of er een error heeft plaatsgevonden (door bErrorOccured te testen) en indien NEE kun je de velden in je dictionairy object vullen met data uit een database bv mocht je dat willen.

In je form vul je alle VALUE attributen van de input en select tags met values uit het dictionairy object uit je session. In de process page van het form, vul je alle dictionairy fields met de values die de user heeft ingegeven in het form (request.form().item values). Je controlleert de values. Is er een error, zet de session("bErrorOccured") op true en redirect naar de formpage. Omdat alle values van de user al zijn ingevuld, gaat dit meteen goed. Je kunt code in je form opnemen dat wanneer session("bErrorOccured") op true staat er een errortekst wordt afgedrukt, bv de tekst die je hebt samengesteld in de process page en hebt geplaatst in session("sUserError").

Als alles OK is in je process page, remove je alle fields in het dictionairy object in het session object en removed daarna het dictionairy object. Zet bErrorOccured op false.

Na een aantal van dit soort verschrikkelijke pages te hebben gebouwd (met soms wel 50 inputfields) is dit echt de meest simpele methodiek. Je kunt als alternatief in je session allerlei fields gaan stoppen, maar die zijn niet goed meer te verwijderen. heb je een applicatie met verschillende forms, dan wordt je session al snel vervuild met data. Hidden parameters in een form is ook een optie, maar dit brengt ook een drama met zich mee, want hoe geef je de ingegeven data door aan de formpage vanuit de process page? (tenzij je processcode EN form in dezelfde page stopt maar dat is niet aan te bevelen in asp). ZOals je ziet, iedere ASP developer's favoriete werk, formhandling code :)

  • pistole
  • Registratie: Juli 2000
  • Laatst online: 21:09

pistole

Frutter

response.transfer is ook een mogelijkheid..
en anders al je vars via GET meegeven in je hyperlink naar de invulpagina
of een hidden form die gesubmit wordt

Mogelijkheden zat, en niet echt moeilijk

Ik frut, dus ik epibreer


  • pistole
  • Registratie: Juli 2000
  • Laatst online: 21:09

pistole

Frutter

Op donderdag 04 april 2002 11:44 schreef Otis het volgende:(tenzij je processcode EN form in dezelfde page stopt maar dat is niet aan te bevelen in asp
En waarom dan niet? Ik gebruik dit heel vaak.

Ik frut, dus ik epibreer


Verwijderd

Op donderdag 04 april 2002 11:23 schreef Glimi het volgende:
Neem een hidden variable op in het forumlier. Als het formulier gesubmit wordt naar de pagina zelf, dan gaat deze variable dus een waarde bevatten.

In de pagina neem je dan code op die checkt of de hidden var geset is en als dat zo is, dan de controle logica gaat uitvoeren, en evt foutmeldingen dropt.
Heb je een voorbeeldje voor ons? Want nu wordt het formulier door een andere asp-pagina afgehandeld. Dit werkt al, maar moeten we die code dan nu in de asp-pagina met het formulier zetten? :?

Verwijderd

Op donderdag 04 april 2002 11:49 schreef pistole het volgende:
response.transfer is ook een mogelijkheid..
Ik zie geen transfer method bij het response object staan voor ASP code.
Waarom is (dictionary object) slecht?
Het object is niet echt klein, tenminste het eet nogal wat memory, waardoor bij veel users, je sessionobjects nogal wat memory opvreten. Het is ook een nogal buggy component (zeker de wat oudere versies die bij IIS4 werden meegeleverd) dat nogal eens memleaks veroorzaakt. Maar in een app waar niet honderdduizenden mensen per dag gebruik van maken is er niets aan de hand.

  • chaozz
  • Registratie: Juni 2000
  • Laatst online: 23-08 22:57
kan echt veel simpeler. je kunt de input van je velden VOOR het submitten controleren met javascript.

een voorbeeld:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
<HTML>
 <HEAD>
  <SCRIPT ID=clientEventHandlersJS LANGUAGE=javascript>
   <!--
    function saveBtn_onclick() {
    /*Validate textarea length before submitting the form*/

    var maxChar = 249
    if (document.form.field.value.length > maxChar) {
      diff=document.form.field.value.length - maxChar;
      if (diff>1)
        diff = diff + " karakters";
      else
        diff = diff + " karakters";

      alert("De omschrijving is gelimiteerd tot " + maxChar + " karakters\n" + "De tekst is " + diff + " te lang");
      document.form.field.focus();
      return (false);
       }

    if (document.form.field.value.length == 0) {
      alert("U dient commentaar toe te voegen");
      document.form.field.focus();
      return (false);
       }
     }
    //-->
  </SCRIPT>

  <TITLE>BLA</TITLE>
 </HEAD>
<BODY>

<H3>Voorbeeld Formulier</H3>

    <FORM ACTION="volgendepage.php" METHOD="post" NAME="form">
     Commentaar:<br>
     <TEXTAREA ROWS=5 COLS=30 NAME="txtOpmerking" ID="field" NAME="field"></TEXTAREA><BR><BR>
     <input type="submit" class=button align="center" value="Post deze waarden" id="saveBtn" name="saveBtn" LANGUAGE=javascript onclick="return saveBtn_onclick()">
    </FORM>
</BODY>
</HTML>

in dit voorbeeld MOET je iets invullen, maar mag het maximaal 249 karakters zijn.

chaozz.nl | RetroGameCouch


  • eborn
  • Registratie: April 2000
  • Laatst online: 08-09 12:50
Op donderdag 04 april 2002 16:11 schreef chaozz het volgende:
kan echt veel simpeler. je kunt de input van je velden VOOR het submitten controleren met javascript.
En wat nou als ik het handmatig aan het formuliertje voor? Met mijn eigen geschreven browser die geen JavaScript aan heeft staan? :Y)

  • chaozz
  • Registratie: Juni 2000
  • Laatst online: 23-08 22:57
ik gaf een suggestie op het probleem met de feiten die ik voor handen had. als er opeens sprake is van een browser die geen javascript ondersteund, dan neem ik het mezelf niet kwalijk dat het idee niet werkbaar is.

chaozz.nl | RetroGameCouch


  • Crazy D
  • Registratie: Augustus 2000
  • Laatst online: 10-09 14:16

Crazy D

I think we should take a look.

Op donderdag 04 april 2002 16:19 schreef chaozz het volgende:
ik gaf een suggestie op het probleem met de feiten die ik voor handen had. als er opeens sprake is van een browser die geen javascript ondersteund, dan neem ik het mezelf niet kwalijk dat het idee niet werkbaar is.
Er is niet opeens sprake van, het is gewoon een zeer slechte gewoonte imho om je validatie alleen in javascript te doen. Een aantal controles kun je er uiteraard wel alvast in uitvoeren, scheelt weer een trip naar de server en terug alleen omdat je vergeten bent aan te vinken of je mannetje of vrouwtje bent (om maar ff wat te noemen), maar je moet _altijd_ serverside controleren... clientside is alleen als extraatje...

Exact expert nodig?


  • pistole
  • Registratie: Juli 2000
  • Laatst online: 21:09

pistole

Frutter

Op donderdag 04 april 2002 13:03 schreef Otis het volgende:

[..]

Ik zie geen transfer method bij het response object staan voor ASP code.
[..]
Sorrie, moest server.transfer zijn, zie http://msdn.microsoft.com/library/default.asp?url=/library/en-us/iisref/html/psdk/asp/vbob9waa.asp

Wat je er in het kort gezegd mee kan doen, is het volgende
1) data wordt gepost naar je verwerkingsscript.
2) script valideert de gegevens
3) indien ongeldig doet het script een transfer terug naar het formulier
4) formulier gebruikt de gegevens weer als "values"

Het gebruik van javascript is dan ook erg slim, maar niet zaligmakend.

Ik frut, dus ik epibreer

Pagina: 1