Virker ikke i FF

Har du virkelig brugt et å i en identifier ?-)

hehe nej det er íkke lige mig, men det virker alligevel ikke... - så den efter jeg lavede tråden...

Men det virker fint med å i IE :)

nu har jeg skruet lidt om på det.. (det skal bare virke i 2uger, er ved at redesigne med asp.net/xhmtl)...

    function validateContactForm() {
       
        var el = document.getElementById('contactform');



        // check default values...
        if(document.getElementById('Navn').value == "Fornavn Efternavn") {return false;}
        if(document.getElementById('EmailTlf').value == "navn@firma.dk") {return false;}
       
        validateSelectBox(document.getElementById('Angaaende'),"Angaaende","about",1,1,"0");
        validateFullName(document.getElementById('Navn').value,"Navn","name",false);
        if(document.getElementById('EmailTlf').value.indexOf("@") > -1 || document.getElementById('EmailTlf').value.length == 0) {
            validateEmail(document.getElementById('EmailTlf').value,"Email","email",false);
        }
        else {
            validateTelFax(document.getElementById('EmailTlf').value,"Telefonnr.","email",false);
        }
       
        // udskriv fejl...
        if(printErrors() == 0) {document.getElementById('contactform').submit();}
       
    }

Men den submitter sku ikke i FF.... bruger jeg den der javascript konsul i FF siger den fejl et andet sted.. i system_xml.js ... noget :

objXMLDom = new ActiveXObject("MSXML.DOMDocument"); // i denne linie..


Men den bliver slet ikke brugt... Så det burde vel ikke have noget at sige..

www.webdanmark.com <- drejer sig om den kontakt formular der er på forsiden..

Så er det vel fordi den disabler javascript, når den finder en fejl, som kan køres ?-)

Hvordan kalder du metoden?
Det virker i hvert fald at kalde på følgende måde:
<form .... onsubmit="return validateContactForm(this)">
Dermed får du formen med som parameter, der kan samles op i metoden i stedet for at bruge den første linje, og du skal så ende med enten at returnere true eller false.

Metoden kunne så se således ud:
    function validateContactForm(el) {
        // check default values...
        if(el.Navn.value == "Fornavn Efternavn") {return false;}
        if(el.EmailTlf.value == "navn@firma.dk") {return false;}
     
        validateSelectBox(el.Angaaende,"Angaaende","about",1,1,"0");
        validateFullName(el.Navn.value,"Navn","name",false);
        if(el.EmailTlf.value.indexOf("@") > -1 || el.EmailTlf.value.length == 0) {
            validateEmail(el.EmailTlf.value,"Email","email",false);
        }
        else {
            validateTelFax(el.EmailTlf.value,"Telefonnr.","email",false);
        }
     
        // udskriv fejl...
        if(printErrors() == 0) {return true;}
     
    }
med HTML:
<form .... onsubmit="return validateContactForm(this)">

Virker dette efter hensigten?

har smidt din ind.. og tilføjet det til onsubmit til formen..

Men den submitter bare hvis jeg bruger denne :

<a href="#" onClick="document.contactform.submit()"><img src="Images/System/Common/Da/TextSendForm.gif" alt="" border="0"></a>

trode den ville køre contactform.onSubmit før den submittede

altså den validerer ikke

Nej onsubmit køres ikke, hvis man submitter via javascript ...

øv er det kun en button der kan så ?

Ja, f.eks. en image-button:

<input type="image" src="Images/System/Common/Da/TextSendForm.gif">

-- og den skal selvfølgelig være i formen !-)

Ja, det burde den sandelig også. Jeg tror ikke at det gør en forskel men onsubmit skal være med små bogstaver hele vejen. Egentlig er det også meningen at man skal submitte ved at klikke på en submit-knap, ikke på et link.
Prøv i stedet at skrive:
<input type=image src="Images/System/Common/Da/TextSendForm.gif" />
Den skal naturligvis være efter <form> og før </form>

Nå, der var roenving hurtigere. Havde ikke set at du skrev i html4. Så skal / til sidst ikke være med...

-- og der er flere underligheder ...

F.eks. er det ret mystisk at et web-bureaus hjemmeside bruger et char-set, som kun er beregnet til windows, når der findes globale standarder ...

-- og det tyder ikke på voldsomt megen viden om web-kodning, hvis man benytter sig af en doctype, som disabler meget væsentlige dele af css i IE !-)

roenving: Enig, men spørgeren siger og at den skal redesignes med til xhtml.

Du skal skifte linjen:
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
ud med:
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />

ja men det er nok 2 år gammelt.. er lige blevet ansat og er ved at omskrive det til "xHtml" (eller hvad der nu er muligt med asp.net 1.1)..

ok det virker nu.. den submitter når det er korrekt.. men der kommer ikke de sædvanlige popup beskeder i IE længere.. (nok ikke muligt i FF)

Men er det ikke usmart at være foran på standarderne, når det rent faktisk kører dårligere i xhtml end i htnl4 ?-)

Se oleboles artikler om det: http://www.eksperten.dk/artikler/537 & http://www.eksperten.dk/artikler/538 !-)

Jo men nu er mit problem noget med et javascript :)

Men lukker, vi kommer nok ikke længere :).. Det er også underordnet..

Og jo html 4 er fint, men vi har diskuteret det meget, men valgte alligevel at tage xhtml, mest fordi asp.net 2.0 skulle understøtte det ganske glimrende..

kom lige med et svar... er 50/50 ik fair ?

roenving: Jeg er ikke helt enig i alle oleboles pointer. XHTML har mange fordele, først og fremmest at de spiller bedre sammen med XML i server-side systemer.
Jeg ved ikke hvad status er for XHTML og IE7, men jeg synes ikke at de overvejelser artiklen gør om XHTML og IE6 (det er her problemer er) berettiger at skulle holde sig fra XHTML.

Oki '-)

svar

tak for Jeres tid..

Jamen du kan da lave alle de xml-ting, du har lyst til serverside, problemerne opstår jo først i klienten ...

-- og sålænge IE6 er langt den største browser hos de mennesker, som rent faktsik surfer på indernettet, er man jo nødt til at tage højde for den !-)

-- og tak for point ;~}

<ole>

Hvis du har problemer med dette, vil jeg mene, du skal sætte dig grundigt ind i XHTML, før du går videre med projektet - for det lyder ikke til, at du har kompetencer til at løfte opgaven.
At skrive XHTML er betydelig meget mere end at huske at lukke sine tags og skrive lowercase - og det kan ikke læres ved hjælp af tutorials. I hvert fald kender jeg ikke til én eneste web-tutorial, der lærer folk at skrive XHTML ... formodentlig fordi de, der skriver den slags, heller ikke ved, hvad XHTML er og hvordan det virker  ;o)

Du vil også løbe ind i problemer med flere scripts i dokumentet, som ikke kan anvendes under XHTML. Bruger du f.eks. 'document.write' i et script, kan siden ikke længere parses som XHTML, men bliver fortolket som dårlig, fejlfyldt html4.

Da det er en løsning, du åbenbart skal løse som professionel, er du pisket nødt til at lære XHTML (grundigt) først ... om ikke andet, så af moralske grunde  :)

/mvh
</bole>

Ole..

Jeg er udemærket klar over det ikke vil være rigtig xHtml, men så markup liderlig er jeg heller ikke..

Det ender nok også med en html løsning, der er mange ting der ikke vil komme til at virke ellers, er jeg nok klar over..

Men det går i bund og grund ud på at få optimeret det vi ellers har liggende, til en meget dynamisk løsning og lidt pænere markup (og der vil derfor være meget overflødigt html i vores output) men for at gøre det så dynamisk så muligt..

Men tak for din kommentar..

Mvh
Jacob

Hvis det er din XML-linje, der giver problemer, er det ikke så mærkeligt, da FF har en helt anden måde at behandle XML på.

  objXMLDom = new ActiveXObject("MSXML.DOMDocument");
- er således ikke en sytaks, FF forstår. Læs evt. om XML i Mozilla her:
    http://www.mozilla.org/newlayout/xml/

schwarz84 >> Det er muligt, du er uenig med mine pointer - men så er du følgelig også uenig med W3C. Jeg skriver ikke stort andet, end du kunne have læst i W3C's FAQ om XHTML.
Det morsomme er blot, at meget få af de, der har meninger om XHTML, nogensinde er nået så 'langt' i deres 'undersøgelse' af teknologien - hvilket igen bevirker at kun meget få overhovedet er i stand til at få XHTML til at virke som andet end dårlig HTML. Det problem er langt fra et isoleret IE-fænomen  ;o)