jo otlet, bar nagy CSS fajloknal problemat okozhat, hisz a latogatonak minden alkalommal le kell toltenie a stiluslapot. dinamikus CSS fajlokat en csak fejleszteshez hasznalnek, s mikor elegedett vagyok a szinekkel (meg minden egyebbel), akkor a generalt lapot elmentenem sima .css-kent, s a weboldalon azt hasznalnam.
Itt be lehet vetni Rasmus Lerdorf kedvenc megoldását, amit ő 404 trükknek hív. Ha nem létezik a CSS file, akkor a 404 kezelő fut le. Akkor az legenerálja a CSS-t, és elmenti a helyére. Legközelebb már ott lesz, és statikus állományként töltődik le (böngésző szépen kesseli). Ha frissíteni kell, mert át kellett írni a generáló programot vagy az adatok megváltoztak, akkor admin felületről is törölhető a CSS, és a következő request szépen legenerálja. Élesbe tenni CSS-t generáló PHP-t tényleg nem szerencsés.
Ezen az alapon fog nyugodni a PHP.net következő livedocs nevű dokumentáció megjelenítő rendszere is, ha egyszer elkészül :)
Élesbe tenni CSS-t generáló PHP-t tényleg nem szerencsés.
Esetleg le lehet kezelni PHP-bol is a Last-Modified headert. Igy is gyorsabb lesz, mintha mindig ujra generalnad, es le kene tolteni. Bar a statikus verzio nal picit biztosan lassabb lesz.
tegyuk fel, hogy egy blog bejegyzest szeretnek "kesselni", amit termeszetesen frissiteni szeretnek, ha uj hozzaszolas erkezik (azaz a motor letorli a kesselt verziot, majd ujat keszit helyette). ha ket hozzaszolas majdnem egy idoben erkezik, a motor ket kulonbozo verziot probal kesziteni (ergo valamelyik hozzaszolas elveszik), vagy a kesobbi hozzaszolas megvarja az elsot? valami olyasmire gondolok, mint adatbazisok eseten a "concurrency control".
weblabor szojegyzek
direkt csak az elso rovidites elofordulast csereli le egy hozzaszolasban, vagy ez egy bug (aka: undocumented feature)?
Ha nincs fájl, akkor PHP szolgál ki. Mivel az adatok továbbra is adatbázisban vannak, ezért nem történhet meg olyan eset, mint a számlálónál.
Azaz ha jön az első hozzászólás, akkor törlődik a fájl. Ha jön közben egy oldallekérés, akkor a PHP kiszolgálja az oldalt, majd elkészíti a fájlt. Egyféleképpen fordulhat elő gond, ha a második hozzászólás törli a fájlt, közben jön egy oldallekérés, az elkészíti a fájlt, majd a hozzászólás kapcsán bekerül az adatbázisba az új hozzászólás. Ekkor az eggyel előző állapot marad kinn a weben. A tanulság: előbb be kell szúrni az adatbázisba a hozzászólást, és csak utána törölni a fájlt. Ekkor nem lehet probléma.
szójegyzék
Direkt működik így. Teljesen felesleges az oldal méretét azzal növelni, hogy minden előfordulást lecserélünk. :)
szojegyzek: logikus, csak gondoltam megkerdezem ;)
404:
megneztem Lerdorf eloadas foliajat, de mivel az elegge vazlatos (meglepo), biztosra szeretnek menni (eddig meg nem probalkoztam dinamikus tartalom "kesselesevel"). az en peldamnal maradva, a kovetkezo pszeudokod jo megoldas?
tartalom modositas: a form kezelo frissiti az adatbazist, s letorli a fajlt
404: adatbazisbol general, fajlba ir es megjelenit
cache
404 handler
Ezen az alapon fog nyugodni a PHP.net következő livedocs nevű dokumentáció megjelenítő rendszere is, ha egyszer elkészül :)
[i]Élesbe tenni CSS-t gener
Esetleg le lehet kezelni PHP-bol is a Last-Modified headert. Igy is gyorsabb lesz, mintha mindig ujra generalnad, es le kene tolteni. Bar a statikus verzio nal picit biztosan lassabb lesz.
Felho
404 trukk es weblabor szojegyzek
404 trukk
tegyuk fel, hogy egy blog bejegyzest szeretnek "kesselni", amit termeszetesen frissiteni szeretnek, ha uj hozzaszolas erkezik (azaz a motor letorli a kesselt verziot, majd ujat keszit helyette). ha ket hozzaszolas majdnem egy idoben erkezik, a motor ket kulonbozo verziot probal kesziteni (ergo valamelyik hozzaszolas elveszik), vagy a kesobbi hozzaszolas megvarja az elsot? valami olyasmire gondolok, mint adatbazisok eseten a "concurrency control".weblabor szojegyzek
direkt csak az elso rovidites elofordulast csereli le egy hozzaszolasban, vagy ez egy bug (aka: undocumented feature)?Re: 404 trukk es weblabor szojegyzek
404
Ha nincs fájl, akkor PHP szolgál ki. Mivel az adatok továbbra is adatbázisban vannak, ezért nem történhet meg olyan eset, mint a számlálónál.Azaz ha jön az első hozzászólás, akkor törlődik a fájl. Ha jön közben egy oldallekérés, akkor a PHP kiszolgálja az oldalt, majd elkészíti a fájlt. Egyféleképpen fordulhat elő gond, ha a második hozzászólás törli a fájlt, közben jön egy oldallekérés, az elkészíti a fájlt, majd a hozzászólás kapcsán bekerül az adatbázisba az új hozzászólás. Ekkor az eggyel előző állapot marad kinn a weben. A tanulság: előbb be kell szúrni az adatbázisba a hozzászólást, és csak utána törölni a fájlt. Ekkor nem lehet probléma.
szójegyzék
Direkt működik így. Teljesen felesleges az oldal méretét azzal növelni, hogy minden előfordulást lecserélünk. :)-boogie-
re
404:
megneztem Lerdorf eloadas foliajat, de mivel az elegge vazlatos (meglepo), biztosra szeretnek menni (eddig meg nem probalkoztam dinamikus tartalom "kesselesevel"). az en peldamnal maradva, a kovetkezo pszeudokod jo megoldas?
Igen?
-boogie-