[ALG] Dynamische content in static HTML pagina's?

[Reveller]

Meer en meer kom ik websites tegen die, om de (database)server te ontlasten, eens in de zoveel tijd hun perl, PHP of wat-dan-ook-scripts, HTML pagina's laten genereren en die op de server zetten.

Zo bestaan sites als CNN.com bijna geheel uit HTML'letjes. Dat dit efficient en in principe niet zo heel moeilijk te bewerkstelligen is (zie bv. http://www.phpfreaks.com/tutorials/29/0.php) heb ik al door.

Maar nu het volgende (de screendumps zijn van een paar minuten geleden): als ik naar amazon.com surf, krijg ik de volgende pagina:

.

Niet verwonderlijk is Amazon's indexpagina (home.html) een statische HTML pagina.

Ik begrijp het alleen niet meer als ik inlog:



Nog steeds zit ik op home.html, maar mijn naam is duidelijk toegevoegd. Die naam wordt naar ik aanneem gewoon uit een sessie getrokken en moet dus dynamisch - via een stukkie perl ofzo - op de homepagina worden weggeschreven.

Hoe kan dit wanneer de homepagina een HTML-file is?!

Ik stoei er al tijden mee, en het is niet direct een vraag die ik voor mijn eigen progwerk nu beantwoord moet hebben ofzo. Ik ben er alleen erg benieuwd naar en kan een dergelijk systeem in de (verre? ) toekomst ook zelf implementeren...

Wie verlicht mij?

[Infinitive]

Dat .html zegt in principe helemaal niets. Je weet van een URL nooit of hierachter een statische of dynamische pagina zit.

En natuurlijk is de "directory" exec natuurlijk erg verdacht.

Server: Stronghold/2.4.2 Apache/1.3.6 C2NetEU/2412 (Unix) amarewrite/0.1 mod_fastcgi/2.2.12

[ Voor 48% gewijzigd door Infinitive op 06-01-2004 01:28 ]

[Verwijderd]

Inderdaad, want je kan je server bijvoorbeeld ook .html-bestanden door de PHP-parser laten trekken .

[P_de_B]

Je kunt niet echt van Amazon uit gaan, de webserver is voor een groot gedeelte maatwerk.

[Reveller]

De conclusie is dus: het is onmogelijk om dynamische content in statische (de tegenstelling zegt het eigenlijk al) pagina te laden.

Het feit dat er .html in de adresbalk staat, wil hooguit zeggen dat de webserver staat ingesteld om .html (met serverside scriptinhoud) als dynamische pagina's te herkennen en te parsen.

Blijft de vraag: het is dus niet mogelijk om een shoppingcart of veilingsite of wat dan ook te maken, en deze hele site statisch te renderen? Immers, je heb altijd dynamische content (username, items in cart, banners, etc.) op deze pagina's nodig.

Als ik een site dan toch sneller wil maken mbv. statisch renderen, wat is dan wel een oplossing? Dat ik bijvoorbeeld onderdelen die op elke pagina - ongeacht of de bezoeker is ingelogd of niet - zoals de footer en eventueel zijnavigatie, statisch render, en dan in plaats van een footer.php de gerenderde footer.html include?

[Voutloos]

Ja, soms kan je besparen als je bijvoorbeeld menuutjes hebt op een frontpage die niet vaak veranderen door het te renderen of cachen. Volgens mij doet t.net dat ook.

Maar of je het .html wil noemen staat hier imo los van.

Blijft de vraag: het is dus niet mogelijk om een shoppingcart of veilingsite of wat dan ook te maken, en deze hele site statisch te renderen?

Waarom denk je dat HTML niet meer voldoet en we PHP etc nodig hebben?

[ Voor 34% gewijzigd door Voutloos op 06-01-2004 12:22 ]

[gorgi_19]

Blijft de vraag: het is dus niet mogelijk om een shoppingcart of veilingsite of wat dan ook te maken, en deze hele site statisch te renderen? Immers, je heb altijd dynamische content (username, items in cart, banners, etc.) op deze pagina's nodig.

Kan best; je laat gewoon een script dagelijks de statische pagina's genereren vanuit de database; een soortement van 'preparsen'.

MAar ik denk dat je beter kan kijken naar caching opties in PHP, ASP, ASP.Net, whatever.

Maar of je het .html wil noemen staat hier imo los van.

Ik heb het sterke vermoeden dat dit is gedaan om een hogere ranking te krijgen in zoekmachines, iig in het verleden.

[ Voor 19% gewijzigd door gorgi_19 op 06-01-2004 12:44 ]

[Altaphista]

gorgi_19 schreef op 06 januari 2004 @ 12:21:
[...]

Kan best; je laat gewoon een script dagelijks de statische pagina's genereren vanuit de database; een soortement van 'preparsen'.

[...]

Dan ben je zomaar (productaantal * aantalcombinaties * aantallen van iederproduct) pagina's verder, dus lijkt me niet handig voor een shoppingcart

[ Voor 4% gewijzigd door Altaphista op 06-01-2004 13:15 ]

[gorgi_19]

Altaphista schreef op 06 januari 2004 @ 13:15:
[...]


Dan ben je zomaar (productaantal * aantalcombinaties * aantallen van iederproduct) pagina's verder, dus lijkt me niet handig voor een shoppingcart

Een shoppingcart lijkt me hier idd niet voor geschikt nee.. Echter, een hoop pagina's (standaard productpagina's) moeten wel 'statisch' te maken zijn.

Echter, ik ben wat dat betreft meer een voorstander van caching van pagina's c.q. pagina-onderdelen.

[ Voor 15% gewijzigd door gorgi_19 op 06-01-2004 13:17 ]

[drm]

Altaphista:
Dan ben je zomaar (productaantal * aantalcombinaties * aantallen van iederproduct) pagina's verder, dus lijkt me niet handig voor een shoppingcart

Dat zijn dan dus ook niet de statische pagina's. Statisch is uberhaupt maar een relatief begrip.

Je zou er bijvoorbeeld voor kunnen kiezen om de productoverzichten en categorien te renderen op het moment dat er een wijziging gedaan wordt ipv. elke request. Dan kun je de rest gewoon dynamisch laten.

Je kunt overigens ook een eind komen met clientsided scripting.

[Altaphista]

gorgi_19 schreef op 06 januari 2004 @ 13:16:
[...]

Een shoppingcart lijkt me hier idd niet voor geschikt nee.. Echter, een hoop pagina's (standaard productpagina's) moeten wel 'statisch' te maken zijn.

Echter, ik ben wat dat betreft meer een voorstander van caching van pagina's c.q. pagina-onderdelen.

* Altaphista totally agrees

was ook (expres) een zgn. 'met-de-oogklep-op'-reactie ter illustratie

[Reveller]

Vaak wordt PHP cachen en van PHP scripts, HTML pagina's renderen en die op de server opslaan, door elkaar gebruikt. Wat is het verschil tussen deze twee?

Ik weet dat bv. SQL queries te cachen zijn door hun output te serializen en op te slaan op de server. MySQL 4 ondersteunt het op database niveau cachen van queries. Op PHP niveau vind ik het onderscheid lastiger.

[drm]

Ik denk dat er niet zozeer een duidelijk verschil is tussen cachen en HTML pagina's renderen en opslaan op de server is, hoewel ik gevoelsmatig de scheidslijn als volgt aan zou geven:

cachen
Er komt een aanvraag binnen. Is de laatste opgeslagen gerenderde html up to date? Zo ja: geef die weer, zo nee: render de content, sla de gerenderde content op in de html en geef de content weer.

HTML laten renderen
Er staat altijd HTML, zodra er een wijziging gedaan wordt in de database wordt de HTML die gebrowsed wordt up-to-date gemaakt.

Maar dat is geen meden en perzen verhaal ofzo, maar zo zou ik het wel omschrijven.