Jeg har et tekstfelt og en knap i en form. Så er det meningen, at når jeg
trykker på knappen, skal teksten sendes aftsted, og appendes til tekstfilen.
Jeg kan bare ikke få det til at virke...
Nogle, som har eksempler, som virker? Jeg bruger ASP, så håber ikke, det er
altfor meget serverside, hvis jeg skal konvertere fra PHP.
Jeg har en fornemmelse, at jeg skal bruge POST i den form, men alle forsøg
er hidtil strandet.
MVH
Rune Jensen
Er lige kommet tilbage til hovedlandet, efter en week-end hos familie på
djævleøen.
Din "send" knap skal kalde et script der samler nødvendige data fra
involverede felter/input, pakker dem sammen som variable til dit serverside
script, og sender dem med AJAX til dit script.
Så umiddelbart er en <form> mere i vejen, end den gavner (klik "send",
resulterer i en reload af siden / visning af det der bliver returneret af
dit script).
Med AJAX, styrer du selv hvad der skal ske - ingenting, eller hentning af
filen efter dit script har tilføjet...
Brug "id" i felter/inputs i stedet for "name", f.eks :
XHTML
<textarea id="mintekst">Tekst her</textarea>
<line id="minmail" type="text" value="email adresse" />
<button onclick="Send" onclick="DoSend()">Send</button>
script :
function DoSend() {
txt = document.getElementById( 'mintext').value;
em = document.getElementById( 'minmail').value;
ptext = encodeURIComponent( 't='+txt+'&e='+em);
req = MakeReqObj();
req.onreadystatechange = TextSent;
req.open( 'post', 'dit_script.asp', true);
req.send( ptext);
end;
function TextSent() {
if ( req.readyState == 4) {
if ( req.status != 200) {
//fejlmeddelelse
}
// Her kan de behandlede data hentes og vises - eller hvad man nu
ellers måtte have behov for
}
}
Det er ikke afprøvet - men skulle være tæt på at fungere.
Og under alle omstændigheder, ideen være tydelig ok.
Birger
Rune,
Birger har givet dig en løsning, dog kom han ikke ind på ASP delen.
Jeg vil foreslå dig følgende fremgangsmåde:
1) Lav en minimalistisk HTML med en <form>, der afspejler din funktion.
Husk her at angive både navn og id (det letter overblikket)
2) Når du har fået denne <form>, der som du rigtigt skriver, er en POST
request, til at virke - incl ASP delen, er det en simpel sag at
'ajaxificere' den.
3) Når du skal 'ajaxificere' den bruger du id'en til at hente værdierne med,
ig name til at skabe encodede name/valuepairs til din send request.
4) På serversiden (ASP) bruger du name'et til at hente værdierne ud med.
Id'et er det anbefaldede tag inden for XML, baggrunden for også at bruge
name er, at det er den der skaber overblikket/sammenhængen mellem dit HTML
og ASP.
Hvis du 'går kold' i 'ajaxificeringen' skal du bare poste dit _fungerende_
minimalistiske HTML, så er der nok nogen, der kan hjælpe dig videre.
--
Med venlig hilsen
Stig Johansen
Jeg har ikke forstand på ASP. ;>)
Mener dog at Rune skulle være i stand til at "ajaxificere" uden først at gå
over en <form>. ;>)
Jeg mener også at huske at Rune udvikler i FF, hvor Firebug giver
information om requests - altså også evt. fejlmeddelelser fra ASP, og også
selvom disse ikke vises på siden.
Og om der anvendes ASP, PHP eller et 8'ende serverside sprog, har ikke nogen
indflydelse på den anvendte script eller XHTML/HTML.
"1) Husk her at angive både navn og id (det letter overblikket)"
Se
http://www.w3.org/TR/xhtml1/#h-4.10
om name og id.
name attributten er deprecated i XHTML.
Forstår jeg Stig rigtigt, mener han noget i retning af opbygning af
parametre efter devisen :
document.getElementById( "id").name+"="+document.getElementById(
"id").value;
Jeg kan se det smarte i at kunne gennemgå elementerne i en form, og opbygge
requesten på denne måde, og det svarer også til den måde <form> virker på.
I betragtning af at name er deprecated, og at man formentlig ved hvilke
parametre man vil have overført, foretrækker jeg at undgå brugen af name
attributen.
Om man skal bruge en name attribut eller et i script defineret navn
serverside, er vel et fedt.
Jeg kan godt se, at det får serverside til at hænge sammen med XHTML'en, i
hvert fald visuelt, og derfor er mere "overskueligt".
(Kunne man forestille sig en mulighed for at gøre det samme, men anvende
f.eks. en id for en label som navn for parametren?)
Birger
Birger
> Jeg har ikke forstand på ASP. ;>)
Me neither, men som du selv skriver er det fuldstændig ligegyldigt, da
klienten kun ser request/responset.
> Mener dog at Rune skulle være i stand til at "ajaxificere" uden først at
> gå over en <form>. ;>)
Nu skal man passe på hvad man siger, men jeg har en teori om at Rune er
rimelig 'ny' ud i ASP.
Når du læser det jeg skriver skal du abstrahere fra det teknisk korrekte
niveau.
Lad os lave et hypotetisk tilfælde.
Antag at vi har en person der er velbevandret udi HTML.
Første skridt er at personen ønsker at udvide sin horisont med noget
serverside, typisk ASP eller PHP, lidt afhængig af religion.
For at kunne sende data til serverside benytter personen <form>, hvad skulle
man ellers bruge?
<form> sender værdien af name attributten med, og på serverside refererer
man til _denne_ attribut.
Nu har denne her person et system, hvor man kan opdatere databasen på
baggrund af name attributten.
Personen vil videre i sin udforskning med fokus på AJAX.
Her er udfordringen at man _selv_ skal bygge sin request, med tilhørende
response, i stedet for at lade browseren gøre det automatisk på baggrund af
<form>'en.
Jeg foreslår derfor, at man stater med at lave sin serverside-something.
Til brug for aftestning af serverside laver man så en <form>, der indeholder
de nødvendige elementer. Altså formålet med dette step er, at man er 100%
sikker på at _serverside_ er i orden _inden_ man overhovedet tænker på
AJAX.
Det videre step er så at 'ajaxificere', som nu involverer clientside.
Her er den foretrukne metode ..byId, som betyder 'endnu' en attribut.
Her er mit forslag at give _både_ id og name den _samme_ værdi, fordi man så
kan bruge den samme (X)HTML til _manual_ aftestning af serverside.
For at rekapitulere, så er det overordnede budskab(struktureret udvikling):
1) Gør serverside 100% _færdigt_.
2) Hvis 'ajaxificeringen' ikke virker er man dermed 100% sikker på at fejlen
ligger på _clientside_, og man behøver ikke at fejlsøge på _Serverside_.
Nu kan det godt være du bliver sur Birger, men du har selv eksponeret det,
og jeg er ældre end dig, så jeg gør det squ alligevel:
<Birger wrote>
txt = document.getElementById( 'mintext').value;
em = document.getElementById( 'minmail').value;
ptext = encodeURIComponent( 't='+txt+'&e='+em);
</Birger wrote>
Problemet her er at man i HTML'et _kun_ ser 'mintext' og 'minmail'.
Med dit eksempel skal man på serveren _kun_ ser 't' og 'e'.
Hvor er sammenhængen? Overskueligheden? Vedligeholdelsesbyrden?
Hvor ser man at 't' = 'mintext'?.
(Og i øvrigt skal &'et ikke encodes i dit eksempel)
Jeg håber du er med på, at det er skrevet i en positiv ånd, og ikke bliver
formærmet.
Jeg læste dit indlæg forkert. ;>)
Ikke at jeg bliver sur eller bærer nag.
Vi gør jo det her for selv at blive klogere, og at hjælpe andre hvor de går
i stå.
Birger
Netop Birger.
Og den virkelige baggrund for mine 'lange' indlæg i stedet for diskussion og
korte faktuelle svar er at skabe input/inspiration hvis en eller
anden(dig?) skulle finde på at lave en dansk 'Hvordan laver man AJAX'.
(Jeg gider ikke)
Hov, den var måske lige grim nok. Jeg vil med glæde bistå med uddybning hvis
der opstår et behov, men jeg er altså ikke pædagogisk nok til at kunne lave
en.
> Stig Johansen wrote:
>> (Jeg gider ikke)
>
> Hov, den var måske lige grim nok. Jeg vil med glæde bistå med uddybning
> hvis
> der opstår et behov, men jeg er altså ikke pædagogisk nok til at kunne
> lave
> en.
Ja, det er et stort arbejde at skulle lave sådan en guide, jeg har prøvet i
andre sammenhænge, og det er ikke så let som man tror, heller ikke selvom
man er fuldt inde i stoffet. Men synes nu, i klarer det ganske godt - også
derfor, det kunne være sjovt med en sådan guide;-) Hvis det endelig er, så
skal jeg gerne forsøge at oversætte PHPen til ASP, så der kommer begge
udgaver med - eller man kan måske bruge noget af det, jeg så finder frem til
via jeres hjælp.
Nu har jeg så desværre været syg de seneste dage, og derfor har det stået
sløjt til med den videre afprøvning af jeres script og
forslagene/kommentarerne til det. Det har mere været sporadiske forsøg
imellem hosteanfaldene og næsepudseriet, som så ikke lykkedes helt... Men nu
giver jeg det en chance igen, så kommer jeg nok igen med nogle spørgsmål.
MVH
Rune Jensen
> Nu skal man passe på hvad man siger, men jeg har en teori om at Rune er
> rimelig 'ny' ud i ASP.
Ja... jeg er på læs-eller-skriv-til-en-fil-niveauet. Måske lidt mere, da jeg
har programmeret i Visual Basic for mange år tilbage. Mens databaser f.eks.
stadig er uopdyrket land.
> Jeg foreslår derfor, at man stater med at lave sin serverside-something.
> Til brug for aftestning af serverside laver man så en <form>, der
> indeholder
> de nødvendige elementer. Altså formålet med dette step er, at man er 100%
> sikker på at _serverside_ er i orden _inden_ man overhovedet tænker på
> AJAX.
...så i ASPen, der skal jeg lave en aflæsning af indholdet i formens
elementer? Noget a la:
strName1=trim(Request.Form("name1"))
strName2=trim(Request.Form("name2"))
og så gemme det til fil på normal vis med WriteLine?
Altså bare normal serverside, ingen specielle koder? For det kan jeg hurtigt
lave, så...
MVH
Rune Jensen
> ...så i ASPen, der skal jeg lave en aflæsning af indholdet i formens
> elementer? Noget a la:
>
> strName1=trim(Request.Form("name1"))
> strName2=trim(Request.Form("name2"))
>
> og så gemme det til fil på normal vis med WriteLine?
>
> Altså bare normal serverside, ingen specielle koder? For det kan jeg
> hurtigt lave, så...
Fuldstændig korrekt Rune, så længe der er tale om 'simple' transaktioner
analogt med en <form> er der _zero_ forskel set fra serverens side - ingen
specielle koder eller andet magisk (Bortset fra det der med man bruger
Id'et til AJAX delen og name til din request.form - deraf min anbefaling at
bruge både name og id).
I dit projekt her skal du bare betragte AJAX delen som en slags usynlig
iframe.
Der hvor det går hen og bliver 'spændende' skal ses i lyset af, at 'man' har
valgt HTTP som en slags defacto protokol til alle mulige ting.
Eksempelvis åbner det mulighed for direkte at kommunikere med en såkaldt
webservice (SOAP/HTTP).
Eller REST - eller XML-RPC osv.
Men så er vi ovre i den noget mere langhårede ende af skalaen.