Webkafeen

[loathsome]

Ok, nå er jeg litt lost her.

 

http://srv1.bounceme.net/AJAX/

 

Prøv å post to forskjellige meldinger rett etter hverandre, så ser du fort hva jeg vil oppnå Takk for hjelpen!

[Jesper Karsrud]

Ikke helt sikker på denne her, men den kan sikkert fungere for deg hvis du vil

var para1 = document.createElement("p");
var strong = document.createElement("strong");
para1.appendChild(strong);
var author = document.createTextNode(getAuthor + " says:");
strong.appendChild(author)
var para2 = document.createElement("p");
var shout = document.createTextNode("ShoutText");
para2.appendChild(shout);
var shoutDiv = document.getElementById("divMedShouts");
shoutDiv.appendChild(para2);
shoutDiv.appendChild(para1);

 

Edit: Fortsatt ikke testet, men den skal altså skrive ut noe slikt som dette:

 

<p><strong>Author</strong> says:</p>

<p>shoutText</p>

 

Derfor de står i omvendt rekkefølge, fordi para1 skal stå over para2. Hvis jeg har skjønte hvordan appendChild funker, legger den nok inn childnodes i den rekkefølgen de blir lest av interpreteren, altså nederste øverst.

Endret 11. september 2007 av Jesper Karsrud

[loathsome]

Konge, Jesper. Skal testes ut i morgen, nå er det natta.

 

Tusen takk!

[Steinmann]

http://bullshit.loathsome.us/ajaxtest/include/

 

Now that's pretty nifty, eh?

9474461[/snapback]

Noen som husker den artiklen om top 10 ting ajax ikke bør brukes til?

Dette var vel nr 2

[Vindstille]

Django-Mango diskusjon #1:

Er det best å hardkode URLer?

<a href="/blog/{{ post.publish_date|date:"Y/M/d"|lower }}/{{ post.slug }}/">

 

Eller bruke slå dem opp?

{% url django.views.generic.date_based.object_detail post.publish_date|date:"Y",post.publish_date|date:"M"|lower,post.publish_date|date:"d",post.slug %}

 

Med det siste er det selvfølgelig mye neklere å vedlikeholde og endre på URL-er. Sprørsmålet er hvor mye ekstra ytelse det krever. Er det snakk om noen merkbar forskjell?

 

Noen som foresten vet om en bedre ytelsesmåler enn StatsMiddleware? Gjerne ett som kan måle tid ned til tiendeler av et mikrosekund. (StatsMiddleware gjør av en eller annen merkelig grunn ikke det selv om time.time() er brukt til å måle tiden med.)

Endret 11. september 2007 av JonT

[mikaelb]

Ok, nå er jeg litt lost her.

 

http://srv1.bounceme.net/AJAX/

 

Prøv å post to forskjellige meldinger rett etter hverandre, så ser du fort hva jeg vil oppnå Takk for hjelpen!

9476055[/snapback]

 

 

Du kan fikse det med noe som det her:

 

/*
   Insert a paragraph at the top in wrapper with id elementId.
   Inserted paragraph has the text newText
*/
function insertBeforeFirstChild (elementId, newText) {
   var insertElement = document.createElement('p');
   insertElement.appendChild(document.createTextNode(newText));
   
   // Define insertInto node.
   var insertInto = document.getElementById(elementId);
   // If insertInto.firstChild is undefined, 
   // insertBefore will behave like appendChild
   insertInto.insertBefore(insertElement, insertInto.firstChild);
   
   return true;
}

 

Edit: forbedret funksjon

Endret 11. september 2007 av mikaelb

[loathsome]

Haha, du er over alt du, Mikael Men takk skal du ha, forhåpentligvis funker det. Jespers måte funket desverre ikke - den slengte paragrafen i bunnen.

 

I'll report back!

[Gjest Slettet-df17e]

For en utrolig rotette side P4 har!

[Steinmann]

Django-Mango diskusjon #1:

Er det best å hardkode URLer?

<a href="/blog/{{ post.publish_date|date:"Y/M/d"|lower }}/{{ post.slug }}/">

 

Eller bruke slå dem opp?

{% url django.views.generic.date_based.object_detail post.publish_date|date:"Y",post.publish_date|date:"M"|lower,post.publish_date|date:"d",post.slug %}

 

Med det siste er det selvfølgelig mye neklere å vedlikeholde og endre på URL-er. Sprørsmålet er hvor mye ekstra ytelse det krever. Er det snakk om noen merkbar forskjell?

 

Noen som foresten vet om en bedre ytelsesmåler enn StatsMiddleware? Gjerne ett som kan måle tid ned til tiendeler av et mikrosekund. (StatsMiddleware gjør av en eller annen merkelig grunn ikke det selv om time.time() er brukt til å måle tiden med.)

9476788[/snapback]

Hmm. beste måten er vel uansett å hente url fra objektet

[Garreth]

Django-Mango diskusjon #1:

Er det best å hardkode URLer?

<a href="/blog/{{ post.publish_date|date:"Y/M/d"|lower }}/{{ post.slug }}/">

 

Eller bruke slå dem opp?

{% url django.views.generic.date_based.object_detail post.publish_date|date:"Y",post.publish_date|date:"M"|lower,post.publish_date|date:"d",post.slug %}

 

Med det siste er det selvfølgelig mye neklere å vedlikeholde og endre på URL-er. Sprørsmålet er hvor mye ekstra ytelse det krever. Er det snakk om noen merkbar forskjell?

 

Noen som foresten vet om en bedre ytelsesmåler enn StatsMiddleware? Gjerne ett som kan måle tid ned til tiendeler av et mikrosekund. (StatsMiddleware gjør av en eller annen merkelig grunn ikke det selv om time.time() er brukt til å måle tiden med.)

9476788[/snapback]

 

Hva skjedde med DRY ? {{ object.get_absolute_url }} er vel litt bedre? Du definerer url-en i modellen.

 

Edit:

 

@ Lovskogen: Hvor ligger de B&A artikklene på istock?

Endret 12. september 2007 av Garreth

[Lovskogen]

Bare klikk inn på "Buy single articles" elns.

[Cucum(r)]

Bruk url-funksjonaliteten. Det er slettes ingen flaskehals i ein real-life applikasjon.

[Haraldson]

Edit: forbedret funksjon

Hvorfor ikke la nodetype være et parameter i metoden, så man kan sende inn dette som argument istedenfor å ha en metode som kun kan opprette avsnitt?

 

Kan vel være en ide å sjekke om nodetype-argumentet er gyldig ifht. HTML/XHTML i metoden før man gjør noe mer, men generelt klarer man vel å sende korrekte argumenter til metoden regner jeg med...

[Peter]

Er vel bedre å lage applikasjonen så dynamisk som mulig, og heller bruker caching for at ytelsen ikke skal gå rett øst?

[Gjest Slettet-df17e]

Det kommer jo veldig ann på applikasjonen. Men caching er som regel aldri en negativ ting

[Cucum(r)]

Men det er mange situasjoner kor caching er meir ressurskrevande enn besparande.

[Peter]

Men det er mange situasjoner kor caching er meir ressurskrevande enn besparande.

9478199[/snapback]

Dette er interessant, kan du utdype?

[Cucum(r)]

Eit veldig enkelt eksempel er jo ei side kor det er fleire writes enn reads.

 

Den fordelaktige versjonen ser noko slikt ut:

• Skriv
  
• Lagre i databasa og cache-ordninga
  
• Les
  
• Les x 1000
  

Eit eksempel kor caching ikkje er ideelt:

• Skriv
  
• Lagre i databasa og cache-ordninga
  
• Skriv
  
• Lagre i databasa og cache-ordninga
  
• Skriv
  
• Lagre i databasa og cache-ordninga
  
• Les
  

For kvar lagring i cache-ordninga må du slette den allereie eksisterande nøkkelen og legge den til på nytt. Ikkje fordelaktig.

[Steinmann]

Dersom dataene endrer seg stadig vil det ikke være noe vits å cache, det er jo en viss overhead på caching.

 

jeje, jeg hadde enkel forklaring..

Endret 12. september 2007 av Steinmann

[Cucum(r)]

Eg sug til å forklare uten å ty til eksempler, så ja - bra Sebba.

 

Det må også seiast at store mengder informasjon bør spreiast ut over fleire enheter (iallfall i memcached). Det er mogleg å endre den øvre grensa til kvar enhet i memcached, men dette blir like ressurskrevande som det å hente informasjonen rett ut i frå databasa.

Caching er generelt sett fantastisk flott, men det er visse gongar då det faktisk kan bli ein liten flaskehals.

Endret 12. september 2007 av Henrik Lied