WN - Javascript krockar

WN (https://www.wn.se/forum/index.php)

- Klientsidans teknologier, design och grafik (https://www.wn.se/forum/forumdisplay.php?f=12)

- - Javascript krockar (https://www.wn.se/forum/showthread.php?t=1048513)

ehsanpo

2011-06-03 12:33

Javascript krockar

Jag har 2 st java script koder en av de ska ändra utseendet på mina checkbox (jQuery custom checkboxes) och den andra ska va typ en räknare för priser.
jag är inte så grym på javascript och jag kan inte fatta vf de inte funkar med varandra.

Här är pris räknaren:

Kod:

<script type="text/javascript">

//Standard Paket

var SPtotalp = 0;

var SPmanp = 0;

var SPsidor = 0;



// RÄKNAR SP

function sumSP(){

        SPsidorfunc();

        SPextra();

        

        var SPtotpris = SPsidor + SPtotalp;

        var SPmanpris = SPmanp;

        var SPmanprisMonth = Math.round(SPmanpris);

        document.getElementById("SPtotpris").innerHTML = SPtotpris;

        document.getElementById("SPmanpris").innerHTML = SPmanprisMonth;

}

function SPsidorfunc(){

        SPsidor = 0;

        if(document.getElementById("SPsidor").selectedIndex == 0) SPsidor = 200;

        else if(document.getElementById("SPsidor").selectedIndex == 1) SPsidor = 300;

        else if(document.getElementById("SPsidor").selectedIndex == 2) SPsidor = 400;

        else if(document.getElementById("SPsidor").selectedIndex == 3) SPsidor = 500;

        return;

}



function SPextra(){

                SPtotalp = 0;

                SPmanp = 0;

                if(document.getElementById("extra1").checked == true){

                        SPtotalp = SPtotalp + 720;

                }

                if(document.getElementById("extra2").checked == true){

                        SPtotalp = SPtotalp + 720;

                }

                if(document.getElementById("extra3").checked == true){

                        SPtotalp = SPtotalp + 2990;

                }



        return;

}



 function uncheckall()

{

document.getElementById("htmlForm").reset();

}

window.onload = uncheckall;

</script>

znap	2011-06-06 00:55

Vad säger javascript-konsolen?

allstars

2011-06-06 14:27

Jag har svårt att tro att det krockar. däremot kan du ha fel i din javascript (någonstans) som gör att all js-funktionalitet inte laddar. Därför ska man köra med try-catch samt loggning under utvecklingstiden.

ehsanpo

2011-06-06 15:18

alltså firebug säger inget fel..
men om jag lägger räknaren först så funkar inte checkbox jquery och tvärtom..

emilv

2011-06-06 15:57

Kan det vara raden där du skriver över allt som lagts i onload-händelsen?

Kod:

window.onload = uncheckall;

Använd jQuery för att schemalägga uncheckall så slipper du det problemet:

Kod:

$(document).ready(uncheckall);

jQuery köar händelserna istället för att skriva över dem.

ehsanpo

2011-06-06 17:18

nej testat utan uncheckall funktionen och det funkar ändå inte...

Jonas

2011-06-07 04:20

Lite svårt utan att se hela sidan och kunna debugga själv.

Min gissning är att en variabel inte är deklarerad, eller att den inte hittar ett ID på sidan.

ehsanpo

2011-06-07 10:01

men grejen är att både 2 funkar perfekt när de ladas själva men tsm så funkar det inte..

allstars

2011-06-07 11:52

kan det ha med att jquery pluginen byter id på tillvalsknapparna så när du försöker kolla vilken som är ibockad att det går sönder där?

Kan du visa sidan?

ehsanpo

2011-06-20 11:11

Ja! det va det fick använda en annan jquery plugin i slut ändan men tack för hjälpen

Jan	2011-07-30 18:36

Hej, skönt att allt löste sig.
Några saker jag tänkte på bara som inte helt kommit fram i kommentarerna (det mesta vet du säkert redan)

Själv använder jag web developer toolbar i FireFox för att debugga min JavaScript. Rekommenderar den skarpt.

En sak du bör ha som vana när du skriver JavaScript, precis som all annan kod, för att undvika krockar etc (som du trodde var det ursprungliga felet) är att använda dig av namespaces/classer och object.

En tredje sak jag tänkte på och här får någon annan gärna bekräfta eller dementera mina uppgifter då jag absolut inte alls är säker. Det är att det finns vissa risker med att använda window.onload
Det är visserligen en lösning som jag gillar med den även kan lägga init-triggern i de externa JavaScript filerna. Men om jag nu minns rätt (och här får någon annan som sagt gärna också säga sitt) så väntar wondow.onload med att triggas tills allt på sidan har laddats in, alltså även bilder etc.
Det betyder att har du en tung bild som ska laddas eller om användaren sitter på en seg uppkoppling kan det ta flera sekunder innan din init funktion kör igång.

Oftast räcker det med att dom:en har laddat för att dina javascript ska fungera. Då kan du med fördel starta din init funktion i slutet av html-koden.
Vet att alla där ute inte håller med mig om att detta är den ultimata lösningen. Det är i alla fall så jag oftast brukar göra.

SimonP

2011-07-31 00:59

Citat:

Ursprungligen postat av Jan (Inlägg 20413097)

En tredje sak jag tänkte på och här får någon annan gärna bekräfta eller dementera mina uppgifter då jag absolut inte alls är säker. Det är att det finns vissa risker med att använda window.onload
Det är visserligen en lösning som jag gillar med den även kan lägga init-triggern i de externa JavaScript filerna. Men om jag nu minns rätt (och här får någon annan som sagt gärna också säga sitt) så väntar wondow.onload med att triggas tills allt på sidan har laddats in, alltså även bilder etc.
Det betyder att har du en tung bild som ska laddas eller om användaren sitter på en seg uppkoppling kan det ta flera sekunder innan din init funktion kör igång.

Oftast räcker det med att dom:en har laddat för att dina javascript ska fungera. Då kan du med fördel starta din init funktion i slutet av html-koden.
Vet att alla där ute inte håller med mig om att detta är den ultimata lösningen. Det är i alla fall så jag oftast brukar göra.

Att starta Javascript innan sidan laddat klart kan resultera i div. problem, olika webbläsare kan då starta då scriptet vid olika tillfällen, t.ex. en getElementByid() kan ge ett null-resultat i vissa läsare. Med windows.onload får man en lösning som är betydligt mer crossplatform-vänlig och stabil.

Jan	2011-07-31 13:03

Citat:

Ursprungligen postat av SimonP (Inlägg 20413125)

Ja, absolut om inte domen är laddad kommer du få problem att nå dina html-objekt, kallar du dock på init-javascript-funktionen i slutet av sidan, alltså efter att all html är inladdad bör det inte vara några problem. I alla fall har jag aldrig haft några problem med detta i någon av de webbläsare jag har provat.
Men det är möjligt att det kan uppstå problem i något scenario där js-filerna inte hunnit laddas in eller. Jag har dock aldrig stött på detta problem och det är enkelt avhjälpt med en try/catch samt en onload backup trigger (om problemet skulle uppstå). Däremot har jag stött på problem med att onload tagit för lång tid på sig att triggas, exempelvis om en bild laddas från en extern sida som inte längre finns och användaren klickar på en knapp som ska trigga något JavaScript.

dAEk	2011-07-31 19:04

Citat:

Ursprungligen postat av SimonP (Inlägg 20413125)

onload innebär att det blir onödiga och märkbara fördröjningar som i.o.f.s. är acceptabelt för en del men ganska onödigt egentligen. DomContentLoaded körs mkt tidigare än onload. Idag finns det bättre alternativ. Man kan t.ex. kombinera ett modultänk med Jans tankar om att anropa init längst ned innan </body></html> och då får man nog en av de snyggare lösningarna.

SimonP

2011-07-31 20:08

Citat:

Ursprungligen postat av dAEk (Inlägg 20413170)

DomContentLoaded är inte något som jag skulle använda eftersom det är många webbläsare som det inte fungerar i. Att lägga scriptstarten i slutet av bodyn fungerar ofta, men det fungerar inte i alla lägen. Kör du plugins (t.ex Java applet) så kan man få problem i vissa webbläsare.

dAEk	2011-07-31 21:22

Citat:

Ursprungligen postat av SimonP (Inlägg 20413181)

Vilka webbläsare menar du när du skriver många? Äldre versioner av IE vet jag om men resten av de moderna webbläsarna ska det ju funka i.

SimonP

2011-07-31 21:38

Citat:

Ursprungligen postat av dAEk (Inlägg 20413188)

Vilka webbläsare menar du när du skriver många? Äldre versioner av IE vet jag om men resten av de moderna webbläsarna ska det ju funka i.

Ja, alla IE förutom 9:an. Dvs. runt 15-20% av besökarna på en "normal" hemsida.

dAEk	2011-07-31 21:44

Citat:

Ursprungligen postat av SimonP (Inlägg 20413192)

Ja, alla IE förutom 9:an. Dvs. runt 15-20% av besökarna på en "normal" hemsida.

Tack. Jag hade för mig att MS lade in stöd för eventet i IE 8... fasligt vad snabbt man glömmer bort saker och ting när man använder libs.

SimonP

2011-07-31 22:09

Citat:

Ursprungligen postat av dAEk (Inlägg 20413193)

Tack. Jag hade för mig att MS lade in stöd för eventet i IE 8... fasligt vad snabbt man glömmer bort saker och ting när man använder libs.

IE-läsarna historiska "inkompabilitet" har nog ställt till med många timmars onödigt jobb för folk i branschen :)

Clarence

2011-08-01 19:25

Citat:

Ursprungligen postat av SimonP (Inlägg 20413181)

Eller så använder man ett vettigt bibliotek och får fullgott stöd för emulation av domcontentloaded för browsers som inte stödjer det.

Men om man gärna vill återuppfinna hjulet med detta, liksom mycket annat, och göra det manuellt får man:
För IE lägga en conditional statement som kör document.write av en script-tagg, och sen kolla readystate på scriptet.
För Safari lägga en timer som kollar document.readyState

Jan	2011-08-26 11:23

SimonP & dAEk
Hahaha ja det är hemskt vad folk är sega på att uppgradera sina webbläsare
Det är galet att 9.7% av världens surfare fortfarande sitter på ie6 (källa: http://www.ie6countdown.com/)
Riktar man sig dock bara mot svenska och nordiska marknaden kan man äntligen skippa stöd för denna Lucifer skapelse, men riktar man sig mot asien och kina så är det bara att slita av sig håret i frustration.

ie6 fyller för övrigt 10 år i morgon (27 augusti) man kanske skulle anordna ett litet kalas

Clarence
Nja håller inte helt med. Färdiga bibliotek kan vara bra ibland, men det är onödigt att koppla på ett tungt bibliotek om det bara är en liten funktionalitet man behöver.
Sen är det stor kvalitetsskillnad på olika bibliotek och det är inte alltid de är välkodade, samt finns det buggar i biblioteket kan de vara svåra att lösa. JavaScript är lite undantaget, eftersom du har tillgång till all kod där och faktiskt kan gå in och fixa buggarna själv. Men har ett antal gånger råkat ut för slutna .net och actionscript bibliotek som haft buggar i sig och du därför måste skapat en workaround för att minimera problemet.

Det var fortfarande rätt beslut att använda de biblioteken eftersom de sparade mycket utvecklingstid. Min poäng är bara att ett stort bibliotek inte alltid är bästa lösningen och därför kan det vara klokt att diskutera fram en bra lösning på onload-problemet samt att bara för att ett bibliotek är känt eller kostar pengar betyder inte det att det inte har buggar eller andra problem.

Alla tider är GMT +2. Klockan är nu 14:01.