ugrás a tartalomhoz

Embedding PHP In CSS

virág · 2009. Ápr. 15. (Sze), 08.35
PHP kód beágyazása CSS-be
 ■
1

Végülis nem css

Delawer · 2009. Ápr. 15. (Sze), 09.34
Amikor meglestem a címet, elgondolkoztam, hogy is lehet ez?
Majd beleolvastam a cikkbe és végül is nem css-be ágyazott php, hanem php által generált css-t kapunk.

Amihez pesze szükséges, hogy pár beállítást elvégezzünk, mint pl.:

AddType application/x-httpd-php .css (a példában a .htaccess -be ajánlja ezt)
Innentől kezdve érvényesülhet a stylesheet php-ból való megalkotása.
2

Elvetélt ötlet

Adam · 2009. Ápr. 15. (Sze), 10.17
Miért kell minden egyes alkalommal legenerálni? Miért nem lehet előre generálni élesítéskor és a felhasználónak gyorsabban – több felhasználónak ugyanazzal a vassal – statikusan kiszolgálni?

Már több éve keringnek ilyen ominózus cikkek 10esével...persze ha naponta összesen huszanen nézik meg az oldalát az embernek, akkor nem fog számítani, de attól még törekedni kellene arra, hogy feleslegesen ne terheljük a rendszert – környezetvédelem! :)
3

környezetvédelemmel egyetértek

virág · 2009. Ápr. 15. (Sze), 10.28
...egyetértek, sőt ami a környezetvédelmet illeti érdemes lenne picit jobban elgondolkodni nekünk fejlesztőknek is, hogy mivel tudnánk még többet tenni ezen a téren :-) Minél kevesebb szerveridőt pazarolni.
Ez a technika nem újdonság, csak egy megvalósítási tipp - ki tudja mikor jöhet jól egy ilyen ötlet, ezt cachelni is lehet stb. stb. - nem szabad semmit vaskalaposan elutasítani :) - szerintem.
7

Miért lenne az

Joó Ádám · 2009. Ápr. 15. (Sze), 22.32
Furcsa beidegződés, miszerint a CSS statikus tartalom kell legyen. Már miért kéne?
Pont ugyanazért nem generálod le előre, amiért a HTML-t sem, holott megtehetnéd. Erőforrás-takarékosságra ott a gyorsítótár.
A nyáron pl. csináltam egy oldalt, ahol minden cikkhez külön mezőben megadhatók voltak CSS szabályok, ezek az adatbázissorban vannak tárolva a szöveg mellett. A HTML-be ekkor csak egy hivatkozás van beszúrva, és ha a cikk címe /cikkek/loremipsum, akkor /cikkek/loremipsum/css címen érhető el a hozzá való stíluslap. Works like a charm.
9

Futási idő

janoszen · 2009. Ápr. 15. (Sze), 23.54
Lehet csinálni dinamikus CSS-t, bár nem irígylem, aki a millió böngészőbug mellé még ezt is megkapja debugolásra.

Ami ebben engem zavar, hogy nem tudom letenni a CSS fileokat külön static szerverre valami abszolut minimális, ramdriveról kiszolgáló webszerverre, mert muszáj PHP értelmezőt futtatni ott is. Nem éppen erőforrás-barát, főleg ha azt vesszük, hogy még tömöríteni és egy fájlba tenni se nagyon lehet emiatt.
13

Valamit valamiért

Joó Ádám · 2009. Ápr. 20. (H), 17.12
Nos, valamit valamiért, de persze ha az ember nagyon akarja, ezzel együtt is megoldható, amit hiányolsz. Mérlegelni kell, hogy mennyire fontos az erőforrás-takarékosság.
10

Nem az a beidegződés

Török Gábor · 2009. Ápr. 16. (Cs), 07.05
Te nem generálod le a HTML-t, de én igen. Nem ez a beidegződés, hanem az, hogy minden legyen dinamikus – ahogy te is helyből támadod a statikus koncepciót.

Hogy a szóban forgó blogmarknál maradjunk: azontúl, hogy a leírás megtévesztő, én sem látom sok értelmét a felmutatott példának. Sőt: rossz a példa. Nem hiszem, hogy micsoda munkák spórolhatok meg azzal, hogy néhány helyen nem ismétlődnek bizonyos értékek, hanem kiemelem őket. A karbantartásnál majd valóban segíthetnek a CSS változók, de helyettük még egy külön réteget behívni a buliba nem feltétlenül szerencsés.

A te példádra visszatérve: magyarán, ha neked van egy kétszáz cikkes honlapod, akkor kétszáz különböző stíluslapod van, kétszáz CSS-t kell a böngészőnek gyorstáraznia. (Még ha a cikkhez nem is tartozik egyedi stílus, tehát a tartalmuk ugyanaz volna a CSS fájloknak, az eltérő URI miatt letölti a böngésző.) Nálam egyet.
14

De bizony

Joó Ádám · 2009. Ápr. 20. (H), 17.23
Te nem generálod le a HTML-t, de én igen. Nem ez a beidegződés, hanem az, hogy minden legyen dinamikus – ahogy te is helyből támadod a statikus koncepciót.


Nem mondom, hogy nem lehet létjogosultsága, de nem kifejezetten extrém látogatottságnál nem látom, milyen előnye lenne a (kiszolgálóoldali) gyorsítótárazással szemben. Valószínűleg nem véletlen, hogy HTML terén a statikustól haladunk a dinamikus felé. Ezzel szemben a CSS-t mint statikus tartalmat kezdtük el használni, és máig ódzkodnak tőle az emberek, hogy dinamikusan szolgáljuk ki.

A te példádra visszatérve: magyarán, ha neked van egy kétszáz cikkes honlapod, akkor kétszáz különböző stíluslapod van, kétszáz CSS-t kell a böngészőnek gyorstáraznia. (Még ha a cikkhez nem is tartozik egyedi stílus, tehát a tartalmuk ugyanaz volna a CSS fájloknak, az eltérő URI miatt letölti a böngésző.) Nálam egyet.


Nem, akkor annyi stíluslapom lesz, ahány cikkhez adnak meg saját szabályokat, a többihez értelemszerűen nem szolgálok ki. Emellett pedig én kiszolgálóoldali gyorstárazásról beszélek (amit persze ki lehet egészíteni jól használt ügyféloldalival is).
15

Ezzel szemben a CSS-t mint

Adam · 2009. Ápr. 21. (K), 10.40
Ezzel szemben a CSS-t mint statikus tartalmat kezdtük el használni, és máig ódzkodnak tőle az emberek, hogy dinamikusan szolgáljuk ki.
A képeket sem dinamikusan szolgálod ki, pedig azok is statikus tartalmak. Nem on-the-fly vízjelez a Flickr sem :)

Nem, akkor annyi stíluslapom lesz, ahány cikkhez adnak meg saját szabályokat, a többihez értelemszerűen nem szolgálok ki.
Ez vizuális kötekedés most, de akkor egyik cikk az oldalon sem követ egységes megjelenítést? A nagy hírlapoknál is van X meghatározott megjelenési mód — arculati szabályzat —, ami szerint kötelesek a tördelők megcsinálni a napi sajtót.
De hogy a szerkesztő – aki egyábként is csak nyers, formázatlan szöveget adhat le – megmondja, hogy mi legyen rózsaszín, meg így-úgy igazítva legyen a szöveg…
Amúgy jelen esetben lenne jogosultsága szvsz egyedül az inline style használatának. Inline style alatt jelen helyzetben azt értem, amikor a <style/> elembe írjuk a CSS-t.
16

Inline style +1

Török Gábor · 2009. Ápr. 21. (K), 12.29
Erre (is) jó megoldás szerintem is az inline style, erre használom én is.
18

Vizualitás

Joó Ádám · 2009. Ápr. 21. (K), 15.11
A képeket sem dinamikusan szolgálod ki, pedig azok is statikus tartalmak. Nem on-the-fly vízjelez a Flickr sem :)


Azért van egy kis különbség egy egyszer feltöltött és többé változatlan kép meg egy CSS állomány közt. Abba pedig szerintem bele se menjünk, hogy méretben mennyi a különbség egy fénykép és egy 20 soros stíluslap közt. Emellett pedig de, ha arra van szükség, akkor a képet is dinamikusan szolgálom ki, aztán meg van cache.

Ez vizuális kötekedés most, de akkor egyik cikk az oldalon sem követ egységes megjelenítést? A nagy hírlapoknál is van X meghatározott megjelenési mód — arculati szabályzat —, ami szerint kötelesek a tördelők megcsinálni a napi sajtót.
De hogy a szerkesztő – aki egyábként is csak nyers, formázatlan szöveget adhat le – megmondja, hogy mi legyen rózsaszín, meg így-úgy igazítva legyen a szöveg…


Dehogynem követ, azért van az alap stíluslap. Ez a lehetőség akkor áll rendelkezésre, ha egyedi formázásra van szükség; ha kétszáz cikkből csak az egyikben lesz parancssori példa, akkor nem érdemes az ahhoz tartozó formázást a fő stíluslapba írni. Ha pedig nem lennének egyedi esetek, akkor a nagy hírlapoknál se lenne szükség tördelőre, megcsinálná a számítógép.

Amúgy jelen esetben lenne jogosultsága szvsz egyedül az inline style használatának. Inline style alatt jelen helyzetben azt értem, amikor a <style/> elembe írjuk a CSS-t.


Az nem inline, hanem beágyazott, és csak annyit érünk el vele, hogy az nem gyorstárazható, szemben a külsővel. A valódi, képernyőre szánt inline pedig akkor is ott van, ha pl. nyomtatnám, tehát nem opció.
17

Elfogadom, hogy te nem látod

Török Gábor · 2009. Ápr. 21. (K), 13.02
Elfogadom, hogy te nem látod előnyét. Majd látod.

(Zárójelben azért mondok még egy „extrém” esetet: a Google hirdetési rendszere hamarosan az árkalkulációba beleveszi az érkezési oldal betöltődési sebességét.)
19

Miért nem írod le?

Joó Ádám · 2009. Ápr. 21. (K), 15.16
Miért nem írod le, mitől előnyösebb?
20

A generált html előnye többek

yaanno · 2009. Ápr. 21. (K), 16.06
A generált html előnye többek közt az, hogy csak a network latency-től meg a szerver throughputjától függ a sebesség, plusz sem a db-t, sem a dinamikus (akármilyen) szkripteket nem éri hit. Bizonyos látogatottság felett ez elengedhetetlen. Ha van pénzed újabb és újabb vasakat betenni, akkor is szembesülsz ezzel a klaszterezés, memcache és egyéb trükkök bevonásával. Végül: minden tekintetben ez a legolcsóbb megoldás. Összefoglalva: gyors, olcsó, takarékos.
22

Bizonyos látogatottság felett

Joó Ádám · 2009. Ápr. 22. (Sze), 00.17
És én el is ismertem, hogy lehet olyan nagyságrendű látogatottság, ahol ez már indokolt lehet, azonban az esetek nagy részében szerintem nem.
23

Nem kell nagy látogatottság.

Török Gábor · 2009. Ápr. 22. (Sze), 10.22
Nem kell nagy látogatottság. Elég egy terhelt hoszting, és a te alkalmazásod is szépen belassul. Aztán beszélhetnők a felhasználói élményről is. Lehet bármilyen bika a szervered, bármilyen jól megírt az alkalmazásod, ha dinamikus, reszponzívitásában nem tudja felvenni a versenyt egy statikus (előre generált) tartalommal. Ha szerinted a statikustól dinamikus felé tartó út a haladó nézet, akkor az evolúció következő lépcsője pont a statikus-dinamikus hibrid, amikor felismered, hogy azt szolgálod ki dinamikusan, amit kell, és nem többet.
24

Mi kell?

Joó Ádám · 2009. Ápr. 22. (Sze), 21.32
Rendben, de mi az, amit dinamikusan kell kiszolgálni? Hol húzod meg a határt? Ráadásul szerinted tényleg megéri pl. minden blogmark beküldésekor legenerálni mondjuk a Weblabor szinte összes (hány ezer is lehet ez?) oldalát, ahol látszanak az oldalsávon? Ilyenkor mi újság a reszponzivitással? Vagy hogyan gondolod?

Esetleg írhatnál egy példát.

Egy normál látogatottság mellett pedig szerintem többet vesztesz a hozzáadott komplexitással fejlesztési oldalon, még akkor is, ha csak azt szolgálod ki generált statikusan, amit könnyű. Éppenséggel írhatnánk Assembly-ben webszervert, belekódolva a weblappal, ha pusztán csak annyi a cél, hogy a lehető leggyorsabb legyen az oldal – mégse tesszük.
21

CDN

Poetro · 2009. Ápr. 21. (K), 16.09
Ha a weboldal valami CDNt használ, akkor a CSS átváltozik eléggé statikussá, ami valahol jó, mert a felhasználónak nem kell sok különböző CSS letölteni (böngésző cache), és jóval gyorsabb is tud lenni a kiszolgálás a CDN-nek hála. Az persze lehetséges, hogy időnként a CSS is generált (mondjuk design frissítéskor), és ekkor a CDN már az új változatot fogja majd kiszolgálni, miután is frissült. Több millió / milliárd oldal kiszolgálásakor azon spórol az ember hardvert, amin tud.
4

Kell ez?

MadBence · 2009. Ápr. 15. (Sze), 15.52
Ha bevezetik a CSS változókat hamarosan, akkor tulajdonképpen miért is kell ez? Terheli a szervert, és nem nyújt különösebben többet.
5

Mikorra implementálják?

Adam · 2009. Ápr. 15. (Sze), 19.14
Ez a kérdés, hogy mikortól tudjuk használni, illetve, hogy mikor fogadják majd el az ajánlást!
6

Webkit

MadBence · 2009. Ápr. 15. (Sze), 19.49
Ha jól tudom, Safariban már benne van, szóval (még ha egyelőre nem is szabványos) folyik az implementálás. Eddig szerencsére nem volt szükségem semmilyen "trükkre" (változók használatára), maximum 1-2 helyen kellett cserélgetni értékeket, hála a jó fölépítésnek (és az öröklődésnek). Persze ha minden böngésző támogatná rendesen (álmodozni csak szabad), én is aktívan használnám, mert tényleg praktikus.
8

Lehet szépen is

yaanno · 2009. Ápr. 15. (Sze), 22.56
Lásd például Inman mester megoldását (PHP). De a Ruby fejlesztők is el vannak kényeztetve :)
11

Érv mellette

Török Gábor · 2009. Ápr. 16. (Cs), 07.07
János, akkor nyilatkozzon: maga mint jeles sitebuilder, használ-e ilyen eszközt, és miért nem? :)
12

Házon belül és kívül

yaanno · 2009. Ápr. 16. (Cs), 08.57
Céges környezetben elég gyakran használunk preprocesszort (pp).

A css-ek esetében nincs lehetőség változók használatára, helyette van: tömörítés, cachelés on the fly, saját tag-szerűségek, amikkel böngészőspecifikus kódot írhatsz ugyanazon css fájlba, mert később a pp szétválogatja és elhelyezi a htmlben (szabványosan) sít. A js-ek esetében hasonló a helyzet: tömörítés, cachelés, saját operátorok.

Az egésznek a kényelmességét egyébként a konkrét implementáció adja, ami Tibornak köszönhető.

Cégen kívül nem használok ilyesmit, mégpedig azért, mert nincs rá szükségem. Csak magamról beszélek, de én úgy 1000-2000 sor css-ig egész jól átlátom a dolgokat, még ha sok kaszkád is van a kódban; js ugyanígy. E fölött aztán elkezdek izzadni, és gondolkodni, hogyan is kéne szervezni ezeket az állományokat, hol lehetne konstansokat (mindenki változókról beszél, pedig ezek konstansok igazából) bevezetni stb.

Összességében szerintem az esetek jelentős részében egyszerűen felesleges egy pp-t bevonni (pl. brosúrák, portfóliók, blogok) - sok olyan eset van/lehet amikor viszont igencsak jól jön. Utóbbiakról talán sikerül írnom valamit :)