16. maj 2001 - 14:02Der er
3 kommentarer og 2 løsninger
Beregn \"hash-værdi\" på 5 felter, før og efter opdatering
Lidt point til den, der kan udtænke den løkke, der sammenligner en før-og-efter hash-værdi af et vilkårligt antal felter. Jeg er en novice, der skal bruge MEGET tid på at udtænkt den præcise kode - Derfor vil jeg meget gerne give nogle point for DIT kodeforslag - Jeg er nemlig selv rigeligt presset med andre dele af koden.
SCENARIE: Jeg loader en html-form, og indlæser defaultværdier fra en db. Der findes fx. 15 felter på en side. Opgaven er nu, at fortælle om 5 specifikke felter ændrer sig...
--- Her er lidt af load-koden: <td><input name=\"Address1\" type=\"text\" size=\"30\" maxlength=\"80\" value=\"<%=rsEnt(\"Address1\")%>\"></td> </tr> <tr> <td><FONT SIZE=2 FACE=\"helvetica, verdana, geneva\">Adresse 2</font></td> <td><input name=\"Address2\" type=\"text\" size=\"30\" maxlength=\"80\" value=\"<%=rsEnt(\"Address2\")%>\"></td>
--- Det drejer sig om adresse-felterne, som jeg ønsker at vide om de har ændret sig. Hvis bare ét af felterne er ændret, ønsker jeg at udføre en ekstra update-action.
Jeg forestiller mig en løkke, der køres ved indlæsning, og skaber en default hash-værdi. Denne gemmes i en session-cookie, eller hiddenvalue eller måske noget helt tredje. (HVORDAN LAVER JEG DEN...)
ASP-siden der modtager kaldet skal herefter genberegne samme hash-værdi. Hvis værdien er forskellig skal der udføres en action. (HVORDAN LAVER JEG DEN DEL...?)
Skal virksomheder stå stærkere mod angreb og kunne udvikle sig, skal sikkerhed, drift og forretning tænkes sammen. Det er tanken bag Jysk IT’s ambition om at skabe en “sikker fremtid” for kunderne.
Jeg vurderer det væsentligt hurtigere at lave en beregnet \"hash-værdi\" end at skulle sammenligne før og efter via \"opslag-og-sammenligning-på-feltniveau\" før jeg kører min update. Jeg vil principielt gerne minimere antal \"overflødige\" connections til DB i løbet af min \"session\". Det er vel i teorien hurtigst at undgå DB\'en fremfor en variabel? Desuden er DB\'ens primære formål at returnere værdi til et stort antal hits, som helst ikke skal påvirkes af det her.
Jeg forestiller mig en løkke, der summerer ascii-værdi pr. tegn for et ønsket felt.
Jeg forestiller mig i teorien en \"public-variabel\" der summeres af en funktion/sub, der kaldes med én variabel ad gangen. Dermed kan man nemt kalde funktionen fx. 4 gange, hvis man ønsker at inddrage 4 felt-værdier.
Men mener du der er enklere (og hurtigere veje), så sig endelig frem. Jeg vil gerne undgå DB-opslag, fordi min server i forvejen har rigeligt at gøre med at levere DB-opslag til andre processor.
Jeg overvejede også at stille spørgsmålet i Javascript istedet for ASP - Men der er mine kompetencer bare væsentligt lavere, hvorfor jeg vil have svært ved at forholde mig til svarene. Javascriptet kunne kaldes onlostfocus eller lignende, og påvirke en variabel ved submit sammenlignes med en oprindelig hash-værdi. Men da den oprindelige værdi jo også skal dannes så jeg det blot nemmest at gøre i ASP - pga. min newbie-javascript-status...
For hvert tekstfelt i din <FORM> laver du et hidden felt, der indeholder samme værdi, og sammenligner de to i det script, der evt. skal foretage opdateringen?
\"en løkke, der summerer ascii-værdi pr. tegn for et ønsket felt\" - nej, det må du ikke gøre. Der er alt for stor sandsynlighed for at du rammer den samme værdi med forskellige data - og så går det galt. Skal du lave en hashværdi så brug MD5, der er kryptografisk stærk. Du kan ikke opfinde noget bedre selv. Den er indbygget i PHP, men i ASP - det ved jeg ikke.
Men du spilder ikke noget væsentlig tid ved at tage de 5 felters rigtige værdier og sammenligne med dem. Det kan altså anbefales.
Jeg nupper selv en smule af pointene, fordi ingen har svaret i retning af, hvad jeg spurgte. Jeg spurgte konkret til en sum-beregning, for at kunne overført ét felt til genberegning af hvorvidt der er ændringer. Mwittrock er kommet med et forslag om hidden value pr. felt. Det kan bruges relativt, og derfor fortjener han sine point, men kræver en del arbejde, hvis man fx. om 2 mdr. ønsker at anvende endnu et felt, vil det ikke blot kunne kobles på en funktion, men skal selvstændigt behandles hele vejen igennem. Derfor er løsningen ikke optimal, men brugbar. Vi deler halv/halv.
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.