Gå til innhold

Edorph

Medlemmer
  • Innlegg

    530
  • Ble med

  • Besøkte siden sist

Innlegg skrevet av Edorph

  1. ..jeg er ikke av den oppfatningen at jeg tror alt som kommer fra Kina/Bangladesh/andre "produksjonsland" nødvendigvis må være uetisk. Jeg ser ikke noe galt i å betale andre for å betale andre for å lage klær utenfor Norge, EU eller andre flinke, flotte og fine industriland, og tror det er ugunstig for de fleste om vi fjerner alle Helly Hansen-jobber i Kina og flytter dem til Norge, slik situasjonen er per i dag.

     

    Vil du kjøpe etisk, så undersøk akkuratt hvor produktet blir laget, og ikke bare hvilket land det dreier seg om.

    Takker for gjennomtenkt svar. Jeg har som deg naturligvis ikke noe imot varer produsert fra andre land som sådan. Det kan antakelig diskuteres om det er en distinksjon mellom etikk og det jeg kalte idealisme. I utgangspunktet mener jeg at en variert industri er fordelaktig på sikt (aka det bør gå an å drive produksjon av forbruksvarer i "høykostland"), og blir bittelitt irritert når det gjøres en greie ut av at noe er "lokalt" ("born in Norway" her), men det likevel er business as usual.

    Men dette ble flåsete fra min side, og siden dette er mote-tråden kan jeg jo nevne at jeg (som den hykleren jeg er) kjøpte jeg en Uber Regulator uansett :hm:

     

    aduog.jpg

  2. Noen som tilfeldigvis vet hvor Uber ( uberfunction.com ) produserer jakkene sine?

    Siden jeg skamløst braste inn med spørsmålet mitt, tillater jeg meg å besvare det også.

     

    Viste seg at de var produsert i Kina, med stoff fra Japan. Hvorfor er det ikke flere produsenter som gjør et nummer ut av å produsere lokalt? I Uber sitt tilfelle gjør de en greie ut av å være "born in Norway" osv, og jakkene har en pris som skulle tilsi norske/vestlige produksjonskostnader, men neida.

     

    Er idealismen min på villspor, eller er det flere som irriterer seg over sånt?

  3. (...) når funksjonen sjekkEpostDB kjører, så venter ikke denne på at onreadystatechange skal bli ferdigkjørt.

    Det er fordi du ikke sier «kjør denne funksjonen nå», men «kjør denne funksjonen når jeg har fått respons fra serveren» (altså når XMLHttpRequest-objektet har state lik 'ready'). Det er dette som menes med Asynchronous Javascript and XML (AJAX). Ditt skript kjører kjører avgårde lykkelig og fornøyd, mens XMLHttpRequest kjører requesten til serveren i bakgrunnen, og kaller onreadystatechange-funksjonen når den er ferdig.

     

    Du kan sette tredje argumentet i open() til false, og gjøre requesten synkron (men da er det i ordets rette forstand ikke AJAX lengre.. SJAX kanskje? :-) ):

    function sjekkEpostDB(epost)
    {
     var response = null;
     httpObj.open('get', '/sjekk_epost_db.php?epost='+epost, false);
     httpObj.send(null);
     if(httpObj.status == 200) {
    response = httpObj.responseText;
    if(response.match("true") == null) {
      document.getElementById('epost_msg').innerHTML = 
    	'<div class="okMsg">OK</div>';
    }
    else {
      document.getElementById('epost_msg).innerHTML = 
    	'<div class="errorMsg">ERROR</div>';
    }
     }
     else {
    alert('request failed..');
     }
    }

    I de fleste tilfeller er ikke dette noen god idé, blant annet fordi websiden din stopper opp mens skriptet venter på svar fra serveren. Det er bedre å hekte en funksjon på onreadystatechange, slik du hadde begynt.

  4. Hmm, du skriver at «uansett hva jeg skriver inn så kommer ERROR opp». Jeg ville trodd det ble omvendt, at OK uansett kommer opp.

     

    Du har rett i at feilen er return httpObj.onreadystatechange=function(){...};. Her returnerer du et funksjonsobjekt, som alltid vil være true. Du får altså ikke return-verdien til onreadystatechanged.

     

    Har endret litt i sjekkEpostDb-metoden din under. Uten å gå for mye i detalj, så ser du at onreadystatechange sin returverdi ikke spiller noen rolle lengre. Siden man ikke vet når denne metoden blir kjørt, er det sjelden lurt å la resten av koden stoppe opp og vente på den.

     

    function sjekkEpostDB(epost)
    {
    var response = null;
    httpObj.open('get', '/sjekk_epost_db.php?epost='+epost, true);
    httpObj.onreadystatechange=function()
    {
    	if(httpObj.readyState == 4)
    	{			
    		response = httpObj.responseText;
    		//responseText er "true"(string) hvis epost finnes i databasen og "false"(string) hvis ikke.
    		if(response.match("true") == null)
    		{
    			document.getElementById('epost_msg').innerHTML = '<div class="okMsg">OK</div>';
    		}
    		else
    		{
    			document.getElementById('epost_msg).innerHTML = '<div class="errorMsg">ERROR</div>';
    		}
    	}
    };
    httpObj.send(null);
    }

  5. Edit: Når det gjelder "debugger" som er gratis og bra, så tror jeg du må lete lenge. Jeg har aldri noen sinne kommet over et stykke programvare som kan debugge på en slik måte at det faktisk hjelper. Du er nok nødt til å lære deg å debugge på egen hånd dersom du skal drive med dette.

    Bruker selv Eclipse PDT med xdebug, og det funker kjempefint det - med breakpoints, stepping og ellers det meste hva hjertet kan begjære. Men er enig i at med riktig logging og tester så dukker de fleste bugs opp før man kommer til det punktet hvor en debugger egentlig er nødvendig.

  6. Er det noen grunn til at du absolutt vil ha Javascriptet til å vite IDen? Hvis du submitter formen (Javascript eller ei), så ser jo PHP-skriptet ditt hvilke verdier som er sendt. Mao, gi hidden input-feltet et felles navn for alle formene, f.eks. name="myid":

    <form name="skjema_id">
    <input type="hidden" name="myid" id="rad1" value="1">
    <input type="submit" id="tekst" value="Hent meir tekst">
    </form>
    <form name="skjema_id">
    <input type="hidden" name="myid" id="rad2" value="2">
    <input type="submit" id="tekst" value="Hent meir tekst">
    </form>

    I PHP får du da en POST-parameter kalt "myid" som forteller deg hvilken form du klikket på.

     

    Med name-attributten på hidden input-elementet vil du også kunne finne IDen i Javascript med this.form.myid.value i onclick-eventen til submit-knappen.

     

    Hvis du ikke kan endre på markupen, men vet at hidden input-elementet alltid er det første input-elementet i formen, kan du også bruke this.form[0].value .

  7. Du må bruke en left og right fordi man i praksis vil ha to bakgrunnsbilder som glir over hverandre (som to butikkdører, derav Sliding Doors-analogien) alt ettersom hvor bredt innholdet er.

     

    Kan nesten se ut som begge bakgrunnsbildene dine bare er ~10px i bredden? Husk at det ene må være minst like bredt som det bredeste menyelementet. Du skal altså ikke repetere noen av bakgrunnsbildene.

×
×
  • Opprett ny...