ugrás a tartalomhoz

CSS Colors: Take Control Using PHP

Anonymous · 2004. Jún. 29. (K), 12.56
CSS generálása okosan PHP-vel
 
1

cache

zsepi · 2004. Jún. 29. (K), 22.15
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.
2

404 handler

Hojtsy Gábor · 2004. Jún. 29. (K), 22.23
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 :)
3

[i]Élesbe tenni CSS-t gener

Hodicska Gergely · 2004. Jún. 30. (Sze), 02.02
É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.

Felho
4

404 trukk es weblabor szojegyzek

zsepi · 2004. Jún. 30. (Sze), 09.02

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)?
5

Re: 404 trukk es weblabor szojegyzek

Bártházi András · 2004. Jún. 30. (Sze), 09.23

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-
6

re

zsepi · 2004. Jún. 30. (Sze), 11.31
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
7

Igen?

Bártházi András · 2004. Jún. 30. (Sze), 12.54
Én nem látok vele problémát.

-boogie-