Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien

Content laden met Ajax

Pagina: 1
Acties:

  • Tompouce
  • Registratie: Februari 2012
  • Laatst online: 22-11 16:58
Programmeurs (en anderen ;-) ),

Ik ben bezig met het bouwen van een website met php, html, css en javascript. Nu wil ik eigenlijk het volgende:

Ik wil dat het menu en de footer 1 keer ingeladen worden, daarna gewoon blijven staan. Alleen de content verandert dus als je op een item in het menu klikt. Dit kan met Ajax heb ik begrepen, dus ik ben op zoek gegaan naar tutorials e.d. Ik vind wel tutorials die hier voor zorgen, maar dan gaat de URL 'niet mee'. De URL moet wel wijzigen als ergens op geklikt wordt...

Zou iemand misschien een idee hebben hoe dit kan? Een tip, tutorial of iets anders?

Thnks!

  • ViNyL
  • Registratie: Augustus 2001
  • Niet online
Wat je wil is een div tussen de header en de footer waar via javascript de content in geladen wordt.

Nadeel hiervan is dat het een nachtmerrie is op zoekmachine gebied, maar los daarvan kun je kijken naar:

http://stackoverflow.com/...using-ajax-php-and-jquery
http://stackoverflow.com/...ent-using-ajax-and-jquery
http://css-tricks.com/ajax-load-container-contents/

De URL zal niet wijzigen want je haalt de info namelijk in de achtergrond op en plaatst dit in een element wat je dynamisch update.

Waarom ze je dan niet gewoon de pagina opnieuw laden met de nieuwe content?

[ Voor 19% gewijzigd door ViNyL op 04-11-2013 10:25 ]


  • Tompouce
  • Registratie: Februari 2012
  • Laatst online: 22-11 16:58
Bedankt! Ik wil het vooral gebruiken omdat ik het niet mooi vindt om een wit scherm te krijgen als je een query uitvoert of als hij een nieuwe webpagina inlaad... dan is een laden... optie veel mooier...

  • FotW
  • Registratie: Juli 2012
  • Laatst online: 24-10 13:17
Een van de eeste hits op google: http://www.tinywall.info/...k-github-navigation-menu/ ?

  • ViNyL
  • Registratie: Augustus 2001
  • Niet online
Het is wel een gevalletje van "Mooier is niet altijd beter". Dat is in dit geval ook zeker zo.

Stel dat javascript is uitgeschakeld, dan werkt je navigatie niet meer. Dat is ook waarom zoekmachines er stuk op gaan. De navigatie met javascript kunnen zij niet volgen.

Als je het perse wil zou ik "normale" links gebruiken en het navigatie element een klasse geven die je afvangt met javascript. Als javascript dan uitstaat dan functioneert het tenminste.

  • Tompouce
  • Registratie: Februari 2012
  • Laatst online: 22-11 16:58
Zouden jullie geen ajax gebruiken om 'witte schermen' te voorkomen bij langzame pc's?

  • Room42
  • Registratie: September 2001
  • Niet online
ViNyL schreef op maandag 04 november 2013 @ 10:33:
Het is wel een gevalletje van "Mooier is niet altijd beter". Dat is in dit geval ook zeker zo.

Stel dat javascript is uitgeschakeld, dan werkt je navigatie niet meer. Dat is ook waarom zoekmachines er stuk op gaan. De navigatie met javascript kunnen zij niet volgen.

Als je het perse wil zou ik "normale" links gebruiken en het navigatie element een klasse geven die je afvangt met javascript. Als javascript dan uitstaat dan functioneert het tenminste.
Uiteraard moet je het als extra, secundaire methode bouwen, niet als enige navigatieoptie.

Overigens gaan zoekmachines al tijden niet meer stuk op een beetje Javascript, hoor.
Tompouce schreef op maandag 04 november 2013 @ 10:36:
Zouden jullie geen ajax gebruiken om 'witte schermen' te voorkomen bij langzame pc's?
Zie jij hier op GoT witte schermen tijdens het laden? Volgens mij ligt het aan de browser en de manier van opbouw van de site. Zorg dat je de hele HTML in één keer stuurt. En zorg dat background images etc in de cache van de browser staan.

[ Voor 22% gewijzigd door Room42 op 04-11-2013 10:43 ]

"Technological advancements don't feel fun anymore because of the motivations behind so many of them." Bron


  • ViNyL
  • Registratie: Augustus 2001
  • Niet online
"Stuk" gaan ze er vast niet op, maar je site indexen zullen ze ook niet doen.

Het is gewoon bad practice je site aan de aanwezigheid van javascript op te hangen. De basis html moet in orde zijn en daar leg je javascript eventueel als sausje overheen, los van de hele SEO discussie.

  • Barryvdh
  • Registratie: Juni 2003
  • Laatst online: 21-11 14:12
Het kan inderdaad wel, maar het is meestal niet super ideaal (en sowieso meer werk), maar wel leuk om eens te proberen. Inderdaad gewoon eerst werkend maken zonder ajax en daarna progressief verbeteren (links afvangen en vervangen door ajax, link met pushstate vervangen enzo).
Maar veel van dat 'witte scherm' is vaak op te lossen door je site sneller te maken, headers goed instellen enzo. Als je css (+plaatjes etc) gecached zijn, is het een stuk sneller en hoeft niet gewacht te worden op de css, zelfde voor de plaatjes.

  • Room42
  • Registratie: September 2001
  • Niet online
Barryvdh schreef op maandag 04 november 2013 @ 10:51:
Het kan inderdaad wel, maar het is meestal niet super ideaal (en sowieso meer werk), maar wel leuk om eens te proberen. Inderdaad gewoon eerst werkend maken zonder ajax en daarna progressief verbeteren (links afvangen en vervangen door ajax, link met pushstate vervangen enzo).
Maar veel van dat 'witte scherm' is vaak op te lossen door je site sneller te maken, headers goed instellen enzo. Als je css (+plaatjes etc) gecached zijn, is het een stuk sneller en hoeft niet gewacht te worden op de css, zelfde voor de plaatjes.
Precies, en het grote voordeel van deze manier van werken is dat je ook nog met de middelste muisknop (of ctrl-klik) de link in een nieuw venster kan openen. Dat werkt met een JS-only-link niet.

"Technological advancements don't feel fun anymore because of the motivations behind so many of them." Bron


  • Tompouce
  • Registratie: Februari 2012
  • Laatst online: 22-11 16:58
Bedankt, ik denk dat het dus het beste is om van ajax laden af te zien... zoekmachine is voor mij erg belangrijk, en als de website d.m.v. caching sneller wordt is dat probleem ook opgelost...

  • Bosmonster
  • Registratie: Juni 2001
  • Laatst online: 19-11 09:49

Bosmonster

*zucht*

Tompouce schreef op maandag 04 november 2013 @ 10:31:
Bedankt! Ik wil het vooral gebruiken omdat ik het niet mooi vindt om een wit scherm te krijgen als je een query uitvoert of als hij een nieuwe webpagina inlaad... dan is een laden... optie veel mooier...
Als je witte schermen krijgt dan denk ik dat je pagina's een beetje optimalisatie kunnen gebruiken. Moderne browsers zijn slim/snel genoeg om goed opgemaakte pagina's zonder haperingen weer te kunnen geven.

  • noes
  • Registratie: Augustus 2006
  • Niet online

noes

gek op benzine.

ViNyL schreef op maandag 04 november 2013 @ 10:24:

De URL zal niet wijzigen want je haalt de info namelijk in de achtergrond op en plaatst dit in een element wat je dynamisch update.
Dit kan wel, in moderne browsers, maar je moet het zelf aansturen, zie: MDN

Wat TS beschrijft wordt bijvoorbeeld in jQuery Mobile gedaan. Je kan je site normaal opbouwen en daarna verrijken met deze functionaliteit, waardoor je zoekmachine ranking niet richting toilet gaat ;) Ook kan je de functionaliteit uitschakelen voor oude browsers.

Nog altijd blijft: optimaliseren van performance is belangrijk!

K54/R1250RS | K48/K1600GT | E61/550i


  • Nedra
  • Registratie: Juli 2006
  • Laatst online: 17-10-2023
Met history.js kan je gebruik maken van de historyapi, waarmee je de urls gewoon netjes mee kan veranderen. Het ajaxify script is een script die, zoals de naam al doet vermoeden, de hele boel via ajax load. Niet persé de beste manier, maar het script heeft duidelijke comments waardoor je er veel van kan leren!

https://github.com/browserstate/history.js/
https://github.com/browserstate/ajaxify

  • R4gnax
  • Registratie: Maart 2009
  • Laatst online: 06-09 17:51
Nedra schreef op dinsdag 05 november 2013 @ 16:07:
Met history.js kan je gebruik maken van de historyapi, waarmee je de urls gewoon netjes mee kan veranderen. Het ajaxify script is een script die, zoals de naam al doet vermoeden, de hele boel via ajax load. Niet persé de beste manier, maar het script heeft duidelijke comments waardoor je er veel van kan leren!

https://github.com/browserstate/history.js/
https://github.com/browserstate/ajaxify
History.js is organisatorisch gezien (zowel op projectleiding als codebase) een ramp. Jammergenoeg is het technisch gezien nog steeds de beste polyfill voor de HTML5 History API, en bij mijn weten de enige die significant veel moeite heeft gestoken in het omheenwerken van diverse bugs in de History API waar diverse oudere Webkit en Opera builds nog wel eens op stuk gingen.

Ajaxify is complete onzin. Content asynchroon bijladen of vervangen met bijbehorende updates and de URL structuur is iets wat je niet zinnig met een golden hammer aanpak op kunt lossen. Zo'n aanpak werkt voor triviale voorbeeldscenario's, maar voor de rest is het echt handwerk als je iets wilt wat kwalitatief goed in elkaar steekt en ook een goede user experience levert.

Daarnaast geldt ook hier dat de codebase ruk is.
Een pareltje zoals:

JavaScript:
1
2
3
4
5
6
7
8
9
10
11
12
// HTML Helper
var documentHtml = function(html){
  // Prepare
  var result = String(html)
    .replace(/<\!DOCTYPE[^>]*>/i, '')
    .replace(/<(html|head|body|title|meta|script)([\s\>])/gi,'<div class="document-$1"$2')
    .replace(/<\/(html|head|body|title|meta|script)\>/gi,'</div>')
  ;

  // Return
  return $.trim(result);
};


vertelt mij al alles wat ik moet weten. Dat soort regexes is meteen een rode vlag die prut naar de vuilnisbak gaat verwijzen. Als je een compleet HTML document wilt parsen en dankzij het gebruik van de HTML5 History API toch al aan moderne(re) browsers vast zit; heb dan het fatsoen om DOMParser te gebruiken. Die is daar voor bedoeld:

JavaScript:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
function parseHtmlDocument( html ) {
  // Create another full HTML DOM from the input string using DOMParser.
  // For browsers that don't support the "text/html" content type for DOMParser, see:
  // https://developer.mozilla.org/en-US/docs/Web/API/DOMParser#DOMParser_HTML_extension_for_other_browsers
  var otherDocument = new DOMParser().parseFromString(html, "text/html");

  // Extract the contents of the other document's body and transplant it into
  // the current HTML DOM using innerHtml and a temporary element. 
  var tempNode = document.createElement("div");
  tempNode.innerHTML = otherDocument.body.innerHTML;
  
  // Grab the mass-converted DOM nodes from the temporary element and
  // turn them into a simple array. Then remove their association with the
  // temporary element, allowing it to be disposed of by the garbage collector.
  var nodes = [].slice.call( tempNode.childNodes );
  nodes.forEach( function( node ) {
    tempNode.removeChild( node );
  })
  
  // Return the other document's new title and the other document's body nodes.
  return {
    title : otherDocument.title,
    body  : nodes
  }

});

[ Voor 44% gewijzigd door R4gnax op 05-11-2013 21:21 ]


  • Nedra
  • Registratie: Juli 2006
  • Laatst online: 17-10-2023
Ah duidelijke taal! Ik denk over het algemeen nogal pragmatisch, en als het werkt, gebruik ik het. History.js heeft voor mij altijd de truc gedaan. Ik geloof wel dat er steeds meer interessante alternatieven voor komen.

Wat betreft dat ajaxify script, ik ben het absoluut met je eens dat het geen oplossing is voor een live site, maar met goed kijken kan je er, denk ik, wel wat uithalen qua informatie.

Wat betreft die Domparser, dat vind ik wel interessant. Hoe zou je het in een geval met HistoryJS toepassen? En heb je sowieso niet een regex nodig als fallback?

  • R4gnax
  • Registratie: Maart 2009
  • Laatst online: 06-09 17:51
Nedra schreef op donderdag 07 november 2013 @ 14:48:
Ah duidelijke taal! Ik denk over het algemeen nogal pragmatisch, en als het werkt, gebruik ik het. History.js heeft voor mij altijd de truc gedaan. Ik geloof wel dat er steeds meer interessante alternatieven voor komen.

Wat betreft dat ajaxify script, ik ben het absoluut met je eens dat het geen oplossing is voor een live site, maar met goed kijken kan je er, denk ik, wel wat uithalen qua informatie.

Wat betreft die Domparser, dat vind ik wel interessant. Hoe zou je het in een geval met HistoryJS toepassen? En heb je sowieso niet een regex nodig als fallback?
HistoryJS heeft alleen zin als je gebruik kunt maken van de echte HTML5 History API. De fallback hashbang (#!) url hack voor andere browsers is echt not-done; daar kleven allerlei technische mankementen en problemen aan. Voor 'down-level' browsers kun je beter gewoon een full page refresh aanhouden.

Je moet voor alle URLs die je via de History API in de window.location bijschrijft namelijk sowieso de mogelijkheid houden om ze door de server correct uit te laten serveren als volledige page requests: ook iemand die van een browser gebruik maakt waar de History API wel ondersteund is, kan namelijk later in een browsing sessie wel eens via een bookmark terug op zo'n URL belanden en dan een volledige request nodig hebben.

Als je het hele async refreshen v/d pagina alleen implementeert voor moderne browsers die de History API ondersteunen, dan zit je sowieso al in het segment browsers dat DOMParser ondersteunt of de document.implemententation.createHTMLDocument polyfill zoals die op MDN besproken wordt. :)

  • Nedra
  • Registratie: Juli 2006
  • Laatst online: 17-10-2023
Op die fiets! Terugvallen op een full page refresh lijkt me inderdaad geen probleem.

Bedankt voor de heldere uitleg!
Pagina: 1