---

Fik løst problemet med linieantal ved i PHP at bede om 1 linie mindre end
jeg faktisk vil have vist, når browseren er FF.
Tak til bidragydere!

Så er det jeg spekulerer på, om der måske også er nogen der kan fortælle
mig, hvordan man får FF til også at vise markøren i <textarea>, når der skal
skrives i det?
(Måske også får FF til ikke at vise tekst-markør på tekster der ikke kan
ændres..)

Og så er det at man gerne vil have et link.
Eftersom FF ikke kan finde ud af at overføre data synkront med AJAX alene,
skal man også have Firebug installeret og aktiveret. Ellers virker siden
slet ikke i FF.
Det er på
http://bbsorensen.dk/?men=Blog
Men man skal være logget ind.
Jens/Jensen kan midlertidigt bruges som navn/pw
Efter det, er man så nødt til at gå tilbage til Blog, så måske er det
smartere bare at starte på http://bbsorensen.dk.
Klik på een af bloggene, og prøv at lægge en kommentar. Det viste <textarea>
har ingen cursor. Selv om det markerer den eksisterende tekst ved klik via
onfocus, er det tilsyneladende ikke focused nok til at FF syntes brugeren
skal vide hvad hyn foretager sig.
(Luk visningen af blog'en - der vil nu være en tekst-cursor i oversigten,
hvor brugeren ikke kan skrive noget! Og det sidste kan verificeres uden at
være logget ind, eller forsøge at skrive en kommentar.
Kommentar-delen er ikke færdig. For at se en ny kommentar skal siden
reloades - bare for at en evt. diskussion her, ikke farer ud langs en ikke
eksisterende tangent..)

Tingene virker som forventet i IE7, og siderne validerer.
Ved godt at validering ikke er en garanti for at tingene virker, kun en
forudsætning. Skriver det også bare, for at spare dem der havde tænkt sig at
forsøge at validere den for lidt tid... (Anvendelse af AJAX gør også
validering lidt mere besværlig. Hver del skal valideres for sig, for at give
et præcist billede. Til gengæld kommer Firebug der helt til sin ret - man
kan få alle detaljer om AJAX kommunikationen, incl. den HTML der servers af
php.)

Men det ku' da være sjovt, hvis man ku' få cursoren i <textarea>'et også i
FF...

Birger

---

Birger skrev:

> Eftersom FF ikke kan finde ud af at overføre data synkront
> med AJAX alene,

Synkront? AJAX plejer at stå for *asynkron* javascript + xml.
Og Firefox virker fint med masser af AJAX-applikationer.


Jeg kan ikke se hvorfor det ikke virker på din side - men jeg kan
på den anden side heller ikke se at der skulle være brug for en
udvidelse for at få det til at virke.

--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

"Jens Gyldenkærne Clausen" <jens@gyros.invalid> skrev i en meddelelse
news:Xns99BEB3CBB9F41jcdmfdk@gyrosmod.dtext.news.tele.dk...
> Birger skrev:
>
>> Eftersom FF ikke kan finde ud af at overføre data synkront
>> med AJAX alene,
>
> Synkront? AJAX plejer at stå for *asynkron* javascript + xml.
> Og Firefox virker fint med masser af AJAX-applikationer.
>
>
> Jeg kan ikke se hvorfor det ikke virker på din side - men jeg kan
> på den anden side heller ikke se at der skulle være brug for en
> udvidelse for at få det til at virke.
>
> --
> Jens Gyldenkærne Clausen
> Svar venligst under det du citerer, og citer kun det der er
> nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
> hvordan på http://usenet.dk/netikette/citatteknik.html

AJAX anvender et ActiveX object - XMLHttpRequest - til overførsel af data
mellem server og client.
Det har en metode der hedder open (M$ : XMLHttpRequest.open(sMethod, sUrl [,
bAsync] [, sUser] [, sPassword]))
3. parameter bAsync er en boolean der angiver om operationen skal være
asynkron (true) eller synkron (false).
Anvendes synkron, stopper programafviklingen indtil et svar er returneret -
asynkront forsætter programafvikling uanfægtet.
Det er i hvert fald meningen - og det virker sådan i andre browsere.
Man kan også møde betegnelsen "blocking" eller "non blocking" for dette.

*asynkron* i beskrivelsen af AJAX, opfatter jeg som en betegnelse for at
kommunikationen ikke foregår samtidig med hentning af siden - man kan ændre
dens indhold, efter den er hentet - asynkront.

Min side bruger XMLHttpRequest til at hente data til visning - bl.a. menuer.
Visse steder er programmet nødt til at vente til data er hentet - fordi det
umiddelbart skal behandle disse data.
Derfor synkront.

XMLHttpRequest objetet i FF virker ikke synkront, med mindre man har Firebug
installeret og aktiveret.
Er du i tvivl, så installer Firebug og prøv igen.
Det er som jeg forstår det, en kendt bug.

Spørgsmålet var ikke hvorfor AJAX ikke virker.


FF vises ikke cursor i <textarea>.
Nogen der ved hvorfor, eller evt. hvordan man får FF til det?


Birger

---

Birger wrote:
> XMLHttpRequest objetet i FF virker ikke synkront, med mindre man har Firebug
> installeret og aktiveret.

Så kalder du din XMLHttpRequest forkert...
Så simpelt kan det siges.

Sidst jeg rodede med selv at bygge mit request (ca. 1 år siden, inden
jeg begyndte at bruge et javascript framework) så mit xmlrequest således ud

xmlhttp=null
if (window.XMLHttpRequest) xmlhttp=new XMLHttpRequest()
else if (window.ActiveXObject) xmlhttp=new
ActiveXObject('Microsoft.XMLHTTP')

---

"Martin" <maaNO@SPAMscandesigns.dk> skrev i en meddelelse
news:4703cfae$0$90263$14726298@news.sunsite.dk...
> Birger wrote:
>> XMLHttpRequest objetet i FF virker ikke synkront, med mindre man har
>> Firebug installeret og aktiveret.
>
> Så kalder du din XMLHttpRequest forkert...
> Så simpelt kan det siges.
>


Nej det gør jeg ikke.
Jeg har prøvet at ændre, så kaldene bliver gjort asynkront.
Det virker - det gør resten bare ikke, fordi data der skal behandles ikke er
hentet endnu, når programmet ikke venter...
Og det virker stadig i andre browsere - selv Opera, kan finde ud af den del
af det...

Er der en sammenhæng mellem den overvældende interesse for, at
XMLHttpRequest ikke virker ved synkront kald i FF, og den manglende cursor i
<textarea> i samme browser?

Birger

---

"Birger" <sdc@bbsorensen.com> writes:

> Er der en sammenhæng mellem den overvældende interesse for, at
> XMLHttpRequest ikke virker ved synkront kald i FF, og den manglende cursor i
> <textarea> i samme browser?

Uden at have læst resten af tråden, så er det et realistisk gæt at
et synkront kald der "hænger" vil gøre at siden ikke opdateres,
inkl. cursoren.

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

---

"Lasse Reichstein Nielsen" <lrn@hotpop.com> skrev i en meddelelse
news:wsu33kg1.fsf@hotpop.com...
> "Birger" <sdc@bbsorensen.com> writes:
>
>> Er der en sammenhæng mellem den overvældende interesse for, at
>> XMLHttpRequest ikke virker ved synkront kald i FF, og den manglende
>> cursor i
>> <textarea> i samme browser?
>
> Uden at have læst resten af tråden, så er det et realistisk gæt at
> et synkront kald der "hænger" vil gøre at siden ikke opdateres,
> inkl. cursoren.
>
> /L
> --

Der er ikke noget andet der ellers tyder på at der er noget der "hænger".
<textarea>'et er funktionelt, på den måde at det kan markere, man kan skrive
idet, og teksten bliver også submitted. Der er bare ingen cursor.
Men noget går åbenbart galt.
Har prøvet at kreere en side, der har samme "overbygning" - altså har
<textarea>'et i omtrent samme divs etc. som på den oprindelige side, og her
er der ingen problemer. (http://test.bbsorensen.dk)
Der er selvfølgelig ikke samme indhold i øvrigt, men det burde nok ikke have
nogen indflydelse...

Der er så nok ikke så meget andet at gøre, end at prøve at lægge om til at
GET i stedet for POST i XmlHttpRequest, og se om det kan have nogen
betydning.
Temmelig meget arbejde for at tækkes en bug i FF...

Birger

---

"Birger" <sdc@bbsorensen.com> writes:

> Eftersom FF ikke kan finde ud af at overføre data synkront med AJAX alene,
> skal man også have Firebug installeret og aktiveret. Ellers virker siden
> slet ikke i FF.

Så vidt jeg kan se virker denne side:
<URL: http://wehrlos.strain.at/httpreq/client.html>
som bruger synkron XMLHTTPRequest, i min Firefox som ikke har Firebug
installeret. Der må være andre omstændigheder også.

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

---

"Lasse Reichstein Nielsen" <lrn@hotpop.com> skrev i en meddelelse
news:sl4r3k2e.fsf@hotpop.com...
> "Birger" <sdc@bbsorensen.com> writes:
>
>> Eftersom FF ikke kan finde ud af at overføre data synkront med AJAX
>> alene,
>> skal man også have Firebug installeret og aktiveret. Ellers virker siden
>> slet ikke i FF.
>
> Så vidt jeg kan se virker denne side:
> <URL: http://wehrlos.strain.at/httpreq/client.html>
> som bruger synkron XMLHTTPRequest, i min Firefox som ikke har Firebug
> installeret. Der må være andre omstændigheder også.
>

Sørme ja.

Den side bruger GET til posting af data. Altså kommandline argumenter.
Jeg bruger Post. Altså parametre sendes i separat forbindelse - "usynligt".

Hvis jeg bruger GET, vil det være muligt via kommandolinien at manipulere
data i min database.
Hvilket jeg ikke er specielt interesseret i.

Ellers er der såmænd ingen forskel.

Birger

---

"Birger" <sdc@bbsorensen.com> writes:

> Hvis jeg bruger GET, vil det være muligt via kommandolinien at manipulere
> data i min database.
> Hvilket jeg ikke er specielt interesseret i.

Hvis man gerne vil hærge din database, så er det ikke en forhindring at
man skal bruge POST. Det er kun en anelse sværere, ikke noget der stopper
en beslutsom hærger.

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

---

"Lasse Reichstein Nielsen" <lrn@hotpop.com> skrev i en meddelelse
news:3awq4ss8.fsf@hotpop.com...
> "Birger" <sdc@bbsorensen.com> writes:
>
>> Hvis jeg bruger GET, vil det være muligt via kommandolinien at manipulere
>> data i min database.
>> Hvilket jeg ikke er specielt interesseret i.
>
> Hvis man gerne vil hærge din database, så er det ikke en forhindring at
> man skal bruge POST. Det er kun en anelse sværere, ikke noget der stopper
> en beslutsom hærger.
>
> /L
> --
> Lasse Reichstein Nielsen - lrn@hotpop.com
> DHTML Death Colors:
> <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
> 'Faith without judgement merely degrades the spirit divine.'

Nej, det er jeg godt klar over.
Ligesom med indbrud. Hvis de vil ind kommer de det også.
Men derfor behøver man jo ikke lade vinduerne stå åbne ;>)

Birger

---

"Lasse Reichstein Nielsen" <lrn@hotpop.com> skrev i en meddelelse
news:sl4r3k2e.fsf@hotpop.com...
> "Birger" <sdc@bbsorensen.com> writes:
>
>> Eftersom FF ikke kan finde ud af at overføre data synkront med AJAX
>> alene,
>> skal man også have Firebug installeret og aktiveret. Ellers virker siden
>> slet ikke i FF.
>
> Så vidt jeg kan se virker denne side:
> <URL: http://wehrlos.strain.at/httpreq/client.html>
> som bruger synkron XMLHTTPRequest, i min Firefox som ikke har Firebug
> installeret. Der må være andre omstændigheder også.
>
> /L
> --
> Lasse Reichstein Nielsen - lrn@hotpop.com
> DHTML Death Colors:
> <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
> 'Faith without judgement merely degrades the spirit divine.'


Jeg skal lige takke for dette link, hvoraf løsningen på problemet med
synkron fandt en "løsning", da jeg fik nærlæst koden og sammenlignet med min
egen.
Ovenstående bruger nemlig en parameter onload for callback funktionen.
Den hedder ellers onreadystatechange i alle andre tilfælde.
I FF, POST af parametre og synkron (blocking) virker XMLHttpRequest KUN hvis
callback hedder onload.
Standarderne http://www.w3.org/TR/XMLHttpRequest/ definerer kun
onreadystatechange.
Jeg har ikke kunnet finde dokumentation for denne afvigelse i FF - blot kan
jeg konstatere, at det virker, hvis man gør sådan.

Kan så desværre også konstatere, at det får ikke cursoren frem i <textarea>.
Heller ikke at lægge om til at GETte parametre løser dette problem.

Birger

---

"Birger" <sdc@bbsorensen.com> writes:

> Standarderne http://www.w3.org/TR/XMLHttpRequest/ definerer kun
> onreadystatechange.

Det er kun en draft af en standard[1]. De siger også:
"This specification does not include the following features which are
being considered for a future version of this specification:
* load event and onload attribute;
..."

Der er ikke nogen standard endnu.

Hvis man bruger synkron kommunikation, så har man kun brug for at kunne
adskille en fejl og success. Man har slet ikke brug for callbacks, og
ellers kan man nøjes med en onerror der smider en exception.
Almindelig opførsel kan foretages af den efterfølgende kode,
som jo først bliver udført når requesten er overstået.

Derfor kan jeg godt forstå at man har "onload"/"onerror" til synkrone
requests og "onreadystatechange" til asynkrone. Det er så træls at
IE og Mozilla ikke er enige.

/L

[1] og de anbefaler at man siger det når man henviser til det, jf
"Publication as a Working Draft does not imply endorsement by the W3C
Membership. This is a draft document and may be updated, replaced or
obsoleted by other documents at any time. It is inappropriate to cite
this document as other than work in progress."
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

---

"Lasse Reichstein Nielsen" <lrn@hotpop.com> skrev i en meddelelse
news:sl4o4h93.fsf@hotpop.com...
> "Birger" <sdc@bbsorensen.com> writes:
>
>> Standarderne http://www.w3.org/TR/XMLHttpRequest/ definerer kun
>> onreadystatechange.
>
> Det er kun en draft af en standard[1]. De siger også:
> "This specification does not include the following features which are
> being considered for a future version of this specification:
> * load event and onload attribute;
> ..."
>
> Der er ikke nogen standard endnu.

Ups. Det forklarer jo lidt.
Fandt den ellers på en side om AJAX gennem google.
Nærlæste ikke - kun om definerede param/events

>
> Hvis man bruger synkron kommunikation, så har man kun brug for at kunne
> adskille en fejl og success. Man har slet ikke brug for callbacks, og
> ellers kan man nøjes med en onerror der smider en exception.
> Almindelig opførsel kan foretages af den efterfølgende kode,
> som jo først bliver udført når requesten er overstået.
>
> Derfor kan jeg godt forstå at man har "onload"/"onerror" til synkrone
> requests og "onreadystatechange" til asynkrone. Det er så træls at
> IE og Mozilla ikke er enige.
>

Mener nu at en callback kan være god at have og lette kodning (og
fejlfinding). Egentlig nødvendig er den ikke ved synkron.
Mener heller ikke at det er nødvendigt at kalde den noget andet, i og med
man allerede ved open() bestemmer om der er tale om synkron eller asynkron
overførsel.
Og onerror() kan være lige så relevant ved asynkron som ved synkron.

Helt enig i at det er træls at de ikke er enige.
Finder det desuden en smule besynderligt at FF kan bruge begge dele i alle
tilfælde - undtagen når man anvender POST med synkron. Så _skal_ det
pludselig være den der ikke virker i de andre...


Birger