[Megoldva] PHP extra whitespace

Internet: PHP, CGI, stb.

Hello!

Egy PHP programozással kapcsolatos kérdésem lenne azokhoz, akik esetleg már botlottak hasonló problémába. Erre jó régóta nem találom a választ sem ezen a fórumon, sem máshol. És elég igénytelenül tudom csak megkerülni a problémát.A kérdésem a következő: Amikor index.php-n request-elek/include-olok egy másik file-t, akkor az outputon miért kapok extra whitespace-t? Tökmind1, hogy azt a head tagek közé rakom vagy a html tageken kívül, akkor is fennáll a probléma.

A kódrészlet: http://pics.coldline.hu/pics/234159-20110515-b50CqT.png.

Ezt én csak úgy tudtam megkerülni, hogy a php tageket html-commentbe raktam, de ugye így kicsit kellemetlen később, amikor debuggolni kell a php-t.

Egy kép az outputról: http://pics.coldline.hu/pics/234155-20110515-vfLYwy.jpg.

  • 5129 megtekintés

( apal v | 2011. 05. 15., v – 13:44 )

figyelj arra hogy az include/require-olt file (db-akarmi.class.php) vegen, a ?> tag utan ne legyen semmi (se szokoz, se ujsor, se semmi). azt is lehet csinalni hogy nem teszed ki ezt a za'ro tagot, sok php-s modul igy nez ki, ez is teljesen fasza megoldas.

Tapasztalt PHP programozó ezért nem tesz ki soha ?> zárotaget.

Még tapasztaltabb ezért nem vegyíti soha a HTML és a PHP kódot. PHP kód az PHP kód. Nincs semmi nyitogatás-csukogatás, fájl leges-leges legelején ott a <?php és utána már csak a kód van.

Ami viszont extra szopatást tud jelenteni az a BOM. De ez már editor kérdése.

Ui: Pastebin-nel tessék megbarátkozni.

----------------
Lvl86 Troll

Igen, tudod, a nativ php kodnal valoszinuleg barmi, amit nativ php kodra forditani kell, gyorsabb. Ez teljesen fuggetlenul attol, hogy hanyszor csinalod meg. A PHP egy template nyelv, marhara szukseg van egy template nyelven futo template nyelvre szerintem is, ami aztan visszafordul az elozo template nyelvre.

(A kulon vicces hogy mindketto turing-teljes, de hogy a smarty minek, azt nem tudni)

Gratulalok a szakertelmedhez.

az hogy a php template nyelv, az mostmar kicsit tulzas.
Vesd ossze a smartyt es a php-t kenyelemben/olvashatosagban, vagy barmi masban.
Koszonom a velemenyedet a szakertelmemhez, igerem, csak rad hallgatok minden teren!:)
Az, hogy kenyelmi szempontbol a smarty messze veri a php-t, egyertelmu. Ennek ertelemszeruen ara van, de nem sok, mivel a smarty vissza van forgatva php-ra, majd az kerul include-olasra mindig, leszamitva a recompile eseteket.
Az persze, hogy a smarty altal generalt nativ kod lassabb mint az altalad szepen begepelt verzio, alairom, de ezen miert lepodik meg barki is? (csak nem annyival, hogy cpu zabalo szarnak nevezd)

Szerintem nem olvashatobb a smarty-s kod mint a kizarolag alternativ szintaxisu if-bol, for-bol, es <?= -bol allo PHP kod (hogy miert ezeket irom be: http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf ).

Es akkor innentol kezdve visszatertunk arra, hogy velemenyem szerint nem olvashatobb, tehat ha nekem ez a velemenyem, es azt allitom, hogy a velemenyem alapjan a smarty energiapazarlas. Nem azt mondtam, hogy szar, azt mondtam, nincs ertelme [ismet: ha nem tartom olvashatobbnak, mert bizonyos konvenciokat betartok].

Na akkor azt dontsuk el, hogy ez csak akkor van-e igy, ha nem ertek hozza.

Olvasni marpedig tudni kell.

1) Nem azt mondtam, hogy zabalja, azt mondtam, pazarolja. Mellesleg nem nem csak a CPU idot, de az emberi idot is, de mindegy
2) Mielott barmi mast akarnal belerakni egy template-be, talan olvasd el a cikket, hogy miert nem szabad.

(BTW: a fent linkelt irodalom eredetileg google-os berkekbol van nagyon nepszerusitve, biztos ok se ertenek hozza.)

( Aadaam | 2011. május 16., hétfő - 15:26 )
Olvasni marpedig tudni kell.
@

Mint hogy érvelni is tudni kell! Egy nyúlfarknyi hsz -hez hozzácsapott 10 oldalas angol szöveg átolvasása úgyvélem nem elvárható senkitől, aki veszi a fáradságot és reagál arra amit irsz. Inkább Neked kellett volna kiemelni a szövegből a lényeget és azt magyarázattal ellátva beidézni, h kedvet kapjon az ember az olvasáshoz.

Nekem kozbe termelni kell am a nemet GDP-t, nem erek ra pusztan flame-elni :)

A Parr cikk egy eleg meghatorozo cikk, ami arrol szol, hogy hogy lehet azt biztositani, hogy a template-edben nincs olyasmi, aminek nem kene ottlennie, mit jelent az, hogy nem kene ott lennie, es hogyan bizonyithato, hogy tenyleg nem kene ott lennie. Ezt nagyjabol 10 oldalon szepen ossze lehet foglalni, amit Parr meg is tett, szeretjuk is erte.

( Aadaam | 2011. május 16., hétfő - 13:15 ) írta:
velemenyem alapjan a smarty energiapazarlas. Nem azt mondtam, hogy szar, azt mondtam, nincs ertelme
@

Hála a saját szintaxisnak a Smarty lehetőséget ad olyan korlátozásra, h a dizájner ne is lássa a php -t, vagy csak engedélyezett php hivásokat használhasson.
Azt h mi pazarlás és mi nem, azt a feladat körül generálodó környezet határozza meg. A kérdés úgy merül fel értelmesen, h a különböző erőforrások közül minek van nagyobb prioritása - minthogy minden CPU időt, tárhelyet, memoriát, stb fogyaszt - vagy a te terminológiádban 'pazarol'. Az MVC miért nem pazarlás szerinted? További aspektusok is léteznek: pazarlásnak tekinthető egy tetszőleges másik template nyelv használatának a kierőszakolása, ha a fejlesztők a Smarty-t ismerik, arra hivatkozva, h a Smarty több CPU-t időt használ mint egy lebutított sprintf('Hello %s', $name) megoldás. Igen lehet, h ez igaz, csak nem érv a fejlesztési idővel v. rendelkezésre álló tapasztalattal szemben egy adott esetben. Aminek valóban nincs értelme: egy kiragadott aspektusból sommás igazságot levonni - ez lehet a hozzáértés egyik kritériuma is.

Oke, akkor most nezd meg az oldal elejet, mit latsz? En egy sracot latok, aki nem tokeletesen jartas meg a PHP-ban. Szerintem nem a tulokositott (Parr...) Smarty-ra van szuksege, hanem a PHP, es annak kulonbozo arcainak megertsere.

Mindezt persze ugy mondod, mintha en azt jelentettem volna ki, hogy a smarty-nak egyaltalan, soha nincs ertelme. Nem ez a helyzet; a smartynak az esetek jelentos reszeben nincs ertelme, a vezeto frameworkok egy resze - Zend Framework, lasd meg: ki "gyartja" a PHP-t -vagy Symfony - nem hasznal Smarty-t, es Rasmus Lerdorf vonatkozo MVC cikkeben (link) is hasonlo eljarast hasznalt.

Nyilvan ha van egy Smarty rendszered, vagy nem volt olyan programozo a piacon, aki keptelen kilepni a Smarty-bol, vagy valami erdekes sitebuilder-fejleszto szetvalasztasod van, ahol smarty-ul tudnak csak PHP-ul nem, igy jartal,, csak mondjuk en latok ipari folyamatokat nagy PHP felhasznaloknal (itt tobbmillio sort es sokszazas, sokezres PHP gepparkokat kell erteni) hogy irtjak kifele, es allnak at erre a nyers template-megoldasra.

Nyilvan amugy egy egoista barom vagyok, es kb. a dolog arrol szol, hogy MCsiv kollega bejelentette, azert mondom azt, hogy cpu-pazarlas a smarty (a jelen esetben), mert nem ertek hozza..

Remelem most mar eleg vilagos, hogy nem ezert mondom.

De ez egyebkent egy velemeny pusztan, nem enforcing, en azt mondtam, hogy szerintem itt es most ennek a topicnak a temajaban nem erdemes smarty-zni. Ettol meg a smarty nagyon szepen csinalja azt, amivel nem ertek egyet, hogy kene csinalnia, vagy hogy szukseg lenne ra. De ettol persze lehet meg hasznalni

Az MVC az egyik leggyonyorbb architekturalis minta, viccen kivul, a zsenialitasa a rekurzivitasaban rejlik, ill. abban, milyen szepen abrazolja az ember-szamitogep kapcsolatot, es hogy tukrozodik ez vissza a retegekben.

"Nyilvan amugy egy egoista barom vagyok, es kb. a dolog arrol szol, hogy MCsiv kollega bejelentette, azert mondom azt, hogy cpu-pazarlas a smarty (a jelen esetben), mert nem ertek hozza.."
Ezzel tenyleg csak annyi a problema, hogy en azt akartam kifejezni, hogy akkor pazarlas, ha az ember szarul allitja be.
Atlagos felhasznalasrol beszelunk (nem a sokcsillios szerverparkos futtatasrol), ahol a smarty elonyei (nativ kodba valo forditas, cache etc.) igen meghatarozoak, foleg fejlesztesi idoben (ugyanezen okbol hasznalsz keretrendszert is, mivel nem akarsz mindent ujra feltalalni).
Masreszt mind a view resz, mind a controller resz igen csinosra kihozhato smarty hasznalataval (szebbre mint php eseteben), masreszt rengeteg olyan egyeb built-in feature van benne, aminek hasznalata mondjuk ugy, hogy valoban jo.

( Aadaam | 2011. május 16., hétfő - 21:08 ) irta

MVC az egyik leggyonyorbb architekturalis minta
/../
smartynak az esetek jelentos reszeben nincs ertelme, a vezeto frameworkok egy resze - Zend Framework, lasd meg: ki "gyartja" a PHP-t -vagy Symfon
@

Jó, de nem ez volt a kérdés. A Smarty is gyünyörű a maga nemében, ha már itt tartunk - persze izlés kérdése.
Feltehetően nem azzal érveltél volna, hogy ki gyártja a PHP -t, ha tudnád, h ki gyártja a Smarty-t! Mivel Andrej Zmievski a társszerzője, aki a PHP-GTK -án és a PHP6 unicode bevezetesén dolgozott a Zendnél. :-D.

A kérdező pedig csak nyugottan barátkozzon meg a Smarty-val, sokat fog neki segíteni!

Bizonyára méltán tölt el Téged egészséges büszkeséggel, h ilyen komoly infrastruktúrával dolgozol. De azért talán nem túlzás kijelenteni, h nem tekinthető általános fejlesztési feladatnak több ezer gépre fejleszteni. Attól pedig, h specializált igényeknek esetleg kevesbé felel meg valami, attól még lehet annak értelme.

Bocs, szerintem a smarty nem gyonyoru, amennyiben belevesszuk valamibe, hogy nem l'art pour l'art fejlesztunk. De itt megint az jon elo, hogy nekem a velemenyem az, hogy a Smarty nem valami olyasmi, amit barhol is hasznalni kene ugy igazan. A PHP-GTK-t pedig remeltem, mar mindenki elfelejtette :)

(Persze ez nem kisebbiti Andrej szakmai erdemeit, egyszeruen nem vagyok vele egy velemenyen, ennyi :)

Most egyebkent tisztan JS-es cegnel vagyok, mondjuk ez se kicsi (3.-4. legnagyobb IT ceg a vilagon?) Nyilvan fejlesztettem egyes nagy PHP rendszerekben is.

A kerdezo baratkozzon csak a PHP-val, ertse meg, mi micsoda, es ebben a smarty - ismet, velemenyem szerint - leginkabb hatraltatja.

Tudod, az ember az idő során fejlődik, új nyelveket/lehetőségeket/keretrendszereket ismer meg és használja, elvégre ez a dolga, nem lehet mindenütt barkácsolt tpl-t és tpx-eket használni.
Ha meg annyira sebesség kritikus a dolog, akkor úgy se php-ban kezdek neki (esetleg max a controller részt, a modelt es a viewt meg be lehet rántani valami értelmes nyelven).

Azt esetleg elarulhatnad, hogy mibajod a PHP sebessegkritikussagaval.

Ezt a dumat mar annyiszor hallottam, valahogy megis a PHP-ban irt Facebook, meg a tarsai szallnak, a javaban irt iwiw meg haldoklik.

(Tudom, hogy nem minden eleme van a fb-nek php-ban implementalva, mielott megjegyezned.)

Errol mar mashol - tema-specifikusabb - forumokon kifejtettem a velemenyemet, hogy az architekturalis szintu parhuzamos elvalasztast nehez lenne uberelni barmivel is.

Talan mert a facebook a sajat enginejevel futtatja a sajat PHP kodjat, sot, a hiphop nevezetu csodajaval forditjak at c++ kodra a PHP scripteket.

Az hogy egy jol megirt c, c++ kod parezerszer gyorsabb mint a php, mar meg sem lepodom.
Sot, a java is gyorsabb a PHP-nal, az, hogy a javaban irt iwiw-et hasonlitsd ossze a PHP-ban irt(c++ kodkent forditott) facebook-al, nevetseges, egyszeruen nem csak kod szintjen, de semmi masban sem egy kategoria a ketto.

Arra probaltam ravilagitani, hogy a kulcsszavas memorizalassal ellentetben gondolkodva igenis lehet gyonyoruen teljesito PHP rendszereket irni. Mindaz, amit a PHP hatranyakent szoktak behozni, altalaban nem lenyeg.

De ehhez az kell, hogy az orrod elott ott legyenek azok a rendszerek, amik ezt csinaljak es nem pedig az, hogy forumokon itt-ott osszeszedett informaciok alapjan letezzel.

Ezt kipróbáltam! Nekem nem jött ki ilyen drasztikus a különbség de valóban.

php 2.258s
c++ 0.019s

Szerintem smarty nem feltétlenül szükséges, de nagyon kényelmes! Fejlesztési időt is lehet vele spórolni, és pl cachelése nagyon jó, illetve ha a compile módot kikapcsolja az ember akkor majdnem csak a natív becachelt php -t futtatja. Szóval nem árt érteni is hozzá. Persze egy plussz layer, ami nyilván lassíthatja, bonyolítja a rendszert.

es ha ehhez hozzaveszed, hogy a c++ fordito mar alapszinten is kioptimalizalja azt, hogyha nem irsz ki semmit, akkor semmi nem tortenik, igy mar meg is van az ures program bekapcsolasi ideje.

Ezen kivul mar csak azt kene figyelembe venni, hogy a c++ explicit fordul, a PHP meg on demand, tehat kb. egy masodik futas szamitana eCache-sel vagy zend optimizerrel.

na es akkor mar csak ott kene lenni, hogy "es ki lehet-e kerulni / szet lehet-e osztani tobb gepre" a feladatot, de en mar inkabb nem irok semmit.

es rakj a for ciklusba valami szamolast is, drasztikus kulonbsegek jonnek elo.
Egy for ciklus hasznalata meg nem a vilag. Atlag hasznalatban 10x lassabb durvan a php, cachelessel ez duplajara gyorsithato.
Ha az ember masszivabb szamolasi dolgokat is akar vegezni, nemritka hogy 100x vagy meglassabb.
Erre is mondtam azt, hogy amit lehet, megirok c++ -ban, majd extensionkent illesztem a php-hoz.
Ez nem is olyan reg, egy ugyviteli rendszernel jott elo, ahol eleg sok szamitas volt. Ezeket szerveztem ki c/c++ modulba, majd 600x sebessegnovekedest elerve.

a szamok kiiratasa csaloka is lehet, mivel a php bizonyos meretig buffereli az output-ot (flush), illetve a konzol sebessege is bejatszik onnantol (egyik eredmenyt javitva, masikon csalva).
for ciklust merni csaloka egyebkent is, rakjatok bele szamitast (par szorzas/osztas/osszeadas/kivonas).

A teszt kedvéért. :D Egyébként tisztában vagyok, hogy php iszonyat lassú csak szeretek kísérletezni.

Teszt:
For ciklus 100 000 szer. A ciklus belsejében kisebb számítási művelet majd eredmény kiíratása. Konzol sebességét kiküszöbölve a scriptek outpuját fileba íratom.

PHP 1.018s
C++ 0.081s

Telepítek egy hip-hop os teszt környezetet is.

hip-hop -al mar lelki szemeim elott latom, hogy olyan 0.250~ kornyeken fog vegezni:)
Kiserleteztunk vele anno, de annyira korulmenyes "tomegtermelesbe" hasznalni, hogy egy-ket eseten kivul tobb szivas volt vele, mintha megirtuk volna mi a c++ kodot:).

Ha az ember sebessegkritikus dolgot ir php-ban, a legjobb megoldas az, hogy a leheto legtobb dolgot kulonbozo php extension formaban ir meg, majd ezeket hasznalja (pl.: van egy smarty szeru extension mar alapbol). Igy az MVC harmasbol a Controller reszt lehet meghagyni a PHP szamara, ezzel megmarad a php azon elonye, hogy gyorsan modosithato a mukodes, viszont a sebessegkritikus reszek a leheto leggyorsabban porognek:)

Igen elég nagy szívás volt telepíteni, meg bepattintani hip-hop -ot. :S Egy egy nagy terhelésű szolgáltatáshoz kiváló megoldás, de egyébként nem.
Erre az extension -os megoldásra én is ráfigyelek. Mindig tanul valamit az ember.

Mondjuk az is nagyon sokat segít, hogy mindent, amit csak lehet sql -re bízni, php -ban csak pár if, kis formázás.

Akkor több mint tippeltem, de egész jól mutatja a különbözőségét az adott platformoknak.
c/c++ -ban, php-hoz képest pár ezerszeres gyorsítás is elérhető. Az ember meg eldönti, hogy mennyire fontos a különböző fejlesztési megközelítés (én annak vagyok a híve, hogy inkább legyen jól megírt a kód és gyorsan fusson, mint egy komplett szerverfarmot aláb@szni).
Mindig mondogatják, hogy olcsóbb a vas, mint a fejlesztő és ilyenkor elgondolkozom, hogy vagy én dolgozok túl olcsón, vagy mások hihetetlenűl drágák (mert két racknyi szerver áráért örömmel optimalizálom a kódomat:))

Lehet hibás a mérési eredmény, mert consolból nem lehet úgy futtatni ( tudtommal ) hip-hop -ot mint pl php -t ( php-cli ), vagy C++ -t. Leszámoltam a kapcsolódási időt stb, és kb ez jött ki, több méréssel is. AB -val majd meg mérem mind a 3 versenyzőt bár az erőviszonyok jól láthatóak.

Amúgy nem tudom pontosan, hogy egy C++ -os és egy php -s fejlesztő órabére közt mennyi a különbség, de gyanítom elég tetemes. PHP-zni ma már mindenki "tud". Ill. szerintem php -ban sokkal gyorsabban és könnyben lehet kivitelezni egy webes alkalmazást mint C -ben.

Az ilyen "mindenki tud" PHP taknyolók után kell kurvasok mérnökórát kifizetni, hogy kiganézzuk a kódot. Szóval, igenis tudni kell PHP-hoz is az alapokat, tudni kell, hogy mi az, hogy referencia és érték szerinti átadás, ismerni kell az adatszerkezeteket, algoritmusokat, előnyeit, hátrányait, stb.

Már, ha az ember nem a 3 statikus HTML lapból álló + vendégkönyvből álló oldalt csinál.

----------------
Lvl86 Troll

A PHP-vel az a baj - ami másfelöl előny - hogy a belépési szint viszonylag alacsony ahhoz h bárki elkezdjen benne csinálni valamit. Ennek oka az ingyenesség, egyszerüsége és a kiváló doksi. Következménye pedig, h mivel sokan vélik értőnek magukat lenyomják a fejlesztők bérét. A másik fő gond sztem - ezért nyilván megköveznek majd egyesek - az a Drupal. Sztem a legroszabb dolog ami történhetett a PHP-val az a Drupal, mivel olyan hype van körülötte, h mindenki abban fejleszt mindent - már az űrhajók is Drupállal mennek. A Drupal primitévségének és a fejlesztők alacsony képzettségének vektora találkozik azzal igénnyel amit a fejlesztő cégek tulajdonosai, mint dilettáns munkaadók támasztanak, azaz hogy a cégen belüli fruktuáció minél kisebb fennakadást okozzon a munkában. A saját rendszert - akár jó minőségű rendszert - fejlesztő cégek kénytelenek azzal szembesülni, hogy minden új embert be kell tanítani, míg a Drupál az Drupál mindenhol és betanítás nélkül is értik. Tehát sok cég vezetője úgy gondolkodik, h nem éri meg saját rendszert fejleszteni, mert az egyrészt sokáig tart, másrészt az elöbb részletezett jelenség miatt sem. Ergo nincs értelmes innováció, a szürkeállományt egyrészt lefoglalja, másrészt elhajtja (mondjuk Java v. .Net területre) a Drupál konfigurálás/fejlesztés.

Egyszer majd probalj java-pistike kodot ganezni; szerintem egy honapon belul feladod.

egy 10 eves(!), tobbezer soros php kodot (ami egyetlen case volt egy nagy switchben.. egy nagyon nagy switchben) egy ulto helyemben irtam at rendes MVC-re, controllerekkel, formabsztrakciokkal, adatbazismodellel, nullarol, ugy, hogy register globalsot hasznalt eredetileg, es olaszul volt a fele.

Igaz, ez 32 oras ules volt, de egyreszt siettunk, masreszt mindenki mas ugy gondolta, hogy beleir meg 500 sort aztan annyi. Orulok, hogy a kollega akinek egy honapja volt arra, hogy teljesitse az 'egy honap alatt aze' rendbe lehet ezt rakni' parancsot, es belesz.rt a kov. heten magatol mondott fel, nem nekem kellett kivagnom.

igen, ezzel en is igy vagyok, hogy ha valamit rendesen meg lehet csinalni es van is ra ido, akkor megcsinalom normalisan. Ha nincs ra ido, akkor ertelemszeruen a helyes mukodes visszaallitasa a cel, de hat valamit valamiert.

Java-Pistike kod: alapbol sem szeretem a java-t, viszont lattam mar gyonyoru es hihetetlenul ganyolt kodot, eg es fold a ketto.

Probalj meg egy szimpla for ciklust, pl 10.000.000 -ig, ugyanezt c-ben.

Ez nagyon életszerű volt! Kérlek áruld el nekünk, hogy ezt az algoritmust hányszor implementáltad az elmúlt 7 év alatt éles rendszeren?

Ha választanom kellene, akkor az elsődleges szempont az lenne, hogy milyen gyorsan lehet az adott eszközben nagy projekteket kifejleszteni és ami talán még fontosabb, gondozni. A dupla fejlesztési sebességért simán beállítanék dupla szerverkapacitást.

lasd fentebb, ez csak egy pelda volt, hogy ket for ciklus kozott is mas nyelven mekkora kulonbsegek vannak (tobb mint 10x-es).
Ha ennel komplexebb feladatokra probalod ravenni a PHP-t, akkor par ezerszeres sebesseg kulonbseg is lazan elojon.
Itt meg az ember elgondolkodik hogy az ember megfizeti egy jo programozo 2x beret, vagy berak meg 10 kontenernyi vasat a szerverterembe (sajnos nem az van, hogy a jo programozo inkabb 3x bert kap es biztos hogy jol megcsinalja).

igenam, csak az atlag futasi idod jelentos reszet az IO/network/mysql etc. teszi ki, innentol kezdve mar nem olyan fontos a webes fejlesztes szempontjabol, hogy primkereses, vagy hanoi tornyait hol oldod meg gyorsabban.
viszont a te logikad szerint a pure assembly-t kellene ajanlgatnod, nem a C-t.
ja hogy az overkill? legtobb website ala a C is, raadasul sokkal nagyobb szakertelmet igenyel "helyes" kodot C-ben megirni, mint php-ban.

Tyrael

Ez egyertelmu, nem is tagadtam, de bonyolultabb dolgokat tenyleg nem celszeru php-ra bizni.
Legutobb ez egeszen pontosan egy terkep alkalmazas fejlesztesenel jott elo, ahol kulonbozo geometriai feladatokat is el kellett latni, valos idoben. Ugyanazon keplet PHP alatt kozel 10 percig futott, c-ben, php extensionkent behuzva 140ms.
En sem azt mondtam hogy mindent abban celszeru megoldani, hanem vannak feladatok amire a php alkalmatlan, illetv hoy alapbol sem egy gyors joszag szegeny. Ennek ellenere en is hasznalom, nagy portalok fejlesztese eseteben is, csak lehetoseg szerint MVC eseten legalabb a Controller, de a View resz kikerul php kodba.
Nem vagy orult hogy plusz es felesleges munkat csinaljak magamnak.

Illetve visszaterve az altalad felvetett, primszam/hanoi dologra, nem mindegy hogy egy egysegnyi user mennyi processzor idot visz el, i/o ide vagy oda. Pont ugyanezert hasznalsz mysql-t is, mert gyorsabb, mintha file-ban, xml-kent tarolnad az adatokat.

"Tapasztalt PHP programozó ezért nem tesz ki soha ?> zárotaget."

Én nem vagyok tapasztalt PHP programozó. Ez miért jó? Nem lenne egyszerűbb az includeolt fileban odafigyelni, hogy ne legyen a záró után whitespace? És mi zárja az includeolt nyitótaget?

"Még tapasztaltabb ezért nem vegyíti soha a HTML és a PHP kódot. "

Ezt én is szeretném elkerülni, milyen technikák vannak rá? Ha kiechozza az ember a HTML-t akkor az már vegyítés. Meg nem is tetszik, a HTML olvashatatlan lesz tőle. Szerk: itt valami MVC szerűt tudnék elképzelni, már amennyiben jól értettem a koncepciót. Tehát maga a HTML adott, és egy egy PHP függvény írja ki a dinamikus adatokat. Viszont table esetében, vagy ismétlődő adatformánál szintén PHP-ből kell kiechózni a HTML-t a ciklusból.

>> "Tapasztalt PHP programozó ezért nem tesz ki soha ?> zárotaget."
> Én nem vagyok tapasztalt PHP programozó. Ez miért jó?

Ebből flame szokott kialakulni, ezért inkább mindenki döntse el maga (a PHP lezártnak értelmezi, ha a fájl végéig se találja a lezárást).

> Ha kiechozza az ember a HTML-t akkor az már vegyítés

Szerintem úgy értette, hogy nem.

Én gyakran használom így: 


print <<< EOS
...
EOS;

Több soros, változókat beilleszt, nem kell se a szimpla, se a dupla idézőjeleket eszképelni. Ha ennél több kell, akkor már tényleg smarty vagy valami keretrendszer.

Mert felesleges es csak a szopas van vele.

Felesleges, mert:
- minek, ha nincs ra szukseg?
- semmi pluszt nem ad onmagaban, a kod veget a fajl vege is ugyanugy jelzi
- +1 zavaro feleslegesseg
- meg erre is figyelni kell
- meg hogy ne legyen utana enter, es ugye nem kodol mindenki whitespace jelolessel
- meg normlais ember amugy se mixeli a PHP-HTML kodot, csak ha tudja, hogy mit csinal es ez a legritkabb igy meg vegkepp felesleges.

Es nem egyszerubb odafigyelni ra. Egyszer valaki megnyitja valami onjelolt editorral, ami kerdezes nelkul odatolja a \n-t a fajl vegere, merthogy szerinte azt ugy kell (ilyenkor azert a true unix linux warriorokat megkerdeznem, hogy akkor hogy is van az a rendszer ne onallositsa magat alapelv) es maris kesz a baj.

MVC-nek meg koze nincs a templatekhez. MVC arra szolgal, hogy az alkalmazasod _kodjat_ kulon retegekre bontsd, a template rendszer arra, hogy az alkalmazasodhoz tartozo kodot es a kimenethez tartozo kodot kulonvalaszd.

Es nem kell mindjart agyuval verebre loni (smarty), kicsi rendszerhez mar az is eleg tud lenni, ha legalabb kulon fuggvenyekbe ki van szedve a HTML kod, kicsit nagyobban meg lehet egyszerubb template rendszert epiteni, aztan nagyon nagyokhoz egyeni izles szerint barmi.

Jomagam pl. meg mindig azt a megoldast - igaz valamennyire tovabbfejlesztve - hasznalom, amit anno a muPortalhoz csinaltam. (Koddal csak ovatosan, meg erosen kozepsuli masodik fele volt az az idoszak, amikor aktivan fejlesztettem, azota azert talalnek rajta nagyon sok ujrairnivalot.

Smartyval mondjuk csak annyi a - szemelyes - problemam, hogy minek Smarty, mikor kb. ugyanarra talaltak ki eredetileg a PHP-t.

----------------
Lvl86 Troll

"Smartyval mondjuk csak annyi a - szemelyes - problemam, hogy minek Smarty, mikor kb. ugyanarra talaltak ki eredetileg a PHP-t."

+1

Szerintem teljesen jó, egyik helyen csak a php és a logika, a másik helyen csak a php és a megjelenítés, a kettő nem érintkezik. Mivel jobb ennél a smarty? Egyébként pl. rails-nél dicsekedni szoktak vele hogy mindent ruby-ban old meg.

( zeroms | 2011. 05. 16., h – 11:35 )

Igen, tipikus kezdo PHP programozo hiba.
Az includeolt fileban a 

<?php es ?>

tageken kivul eso sorokat mar nem a PHP ertelmezi es e miatt azok mint HTML kod jelennek meg a forrsaban. Javaslom, hogy minden php file elso sora a nyitotaggel kezododjon (<?php) es bevett szokas, hogy a php fileok vegere nem tesszuk ki a zaro taget (?>).

Igen, kb ez volt az amire kíváncsi voltam, konkrétan. Köszönöm neked is meg saxus-nak is, még1x!

A smarty-ról meg annyit, h volt alkalmam dolgozni vele. Igaz, nem túl nagy CMS rendszerekben, már több kisebb web fejlesztő cégnél is. Én csak annyit vettem észre, h leggyakrabban csak bonyolítja a fejlesztést.

Nem állítom, h nem lehet hasznos a smarty a megjelenítés leegyszerűsítésében, de szvsz ahhoz már egy sokoldalú, nagyméretű CMS - vagy akármilyen - rendszer kell, hogy lássuk a hasznosságát.

-------
It is our choices that define us.

+1

A smarty csak nagyon keves esetben feltetlenul szukseges, a legtobb esetben a short_open_tag = On boven eleg hozza. Persze, ha olyan appot kell fejleszteni, ami ettol a beallitastol fuggetlen, az megneheziti a dolgokat, akkor indokolt lehet a hasznalata.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( nephlim | 2011. 05. 25., sze – 10:34 )

Szerintem nem kéne a Smarty-n vitatkozni, főleg, hogy abszolút off topic.
A whitespace-k egyébként azért vannak, mert extra whitespace van a kódodban. :)

Ez nekem is fejtörést okozott egy ideig, aztán rájöttem, hogy úgy lehet eltűntetni, ha

  • egyrészt különválasztod az alkalmazáslogikát a template-ktől
  • másrészt nem teszel whitespace-ket a templatekbe

Tehát:

(ez itt whitespace, csak valamiért nem jelenik meg)<?php foreach($a as $b): ?>

(ez itt whitespace, csak valamiért nem jelenik meg)<?php endforeach; >

helyett:

<?php foreach($a as $b): ?>

<?php endforeach; >

ezen kívül a template fájljaid végén mindig legyen egy üres sor. Ez valamiért be szokott zavarni a php-nak.
Mióta így csinálom a dolgokat nincsnek fura whitespace-k.

Amúgy meg a whitespace max téged zavar, vagy egy hasonszőrűt, aki az oldalad html kódját böngészgeti.

A probléma még mindig nem oldódott meg teljesen.

Kipróbáltam azt is amit te mondtál;

Ezek között van egy ControlPage.class.php, ami annyit csinál, hogy példányosítja smarty-t és megjeleníti a tpl-em. Az eredmény pedig ITT. Amint látod, ez nem csak nekem zavaró, mivel a külső header id-jű div felett alapból nem kellene az a fehér csík, amit a felesleges/rejtélyes whitespace-szindróma okoz.

És ebben az egész rendszerben egy nyomorult PHP lezáró tag ( ?> ) sincs.

-------
It is our choices that define us.

Enyhén off, de egy jótanács a jövőre nézve: a header részek legyenek a legutolsó dolgok, amiket legenerálsz, különben esélyed nem lesz a title tag tartalmának módosítására vagy pl. további JS/CSS fájlokat behívni, ha kell. Na meg HTTP headereket módosítani.

----------------
Lvl86 Troll

Köszönöm a jótanácsokat! :) Ez egy abszolút nem éles szerverre szánt kód, hanem már egy össze-vissza szétszedett cumó, aminek annyi értelme van, h végre rájöjjek, mi az Istenért nem tudom megoldani ezt a nyomorult problémát. :) Nem így kódolok, ha komoly projekten dolgozom.

Azért thx még1x.

-------
It is our choices that define us.

( s7stM | 2012. 01. 08., v – 19:52 )

Ezt csak azért írom meg, ha valakit esetleg érdekelne és botlott már hasonló problémába. A megoldás annyira végtelenül egyszerű és kézenfekvő volt, hogy az nem is igaz...(én mindig az ilyeneken akadok fent -.-) Mivel én sem zárom le már a php tag-eket és teljesen külön volt a html és a design, magától a php-től, így ezek nem is releváns tippek voltak. (MVC modell szerint gondolkodom és programozok.)

Mindössze annyi volt a baj, hogy a php fájlokat ANSI character encoding-gal kell tárolni, én erre UTF-8at használtam, mert azt hittem, az az elterjedt, persze indokolatlanul hittem. De szembesülnöm kellett vele, hogy a szerverek többsége alapból ANSI-ra van állítva vagy UTF-8 BOM nélkül.... Ezzel minden whitespace problémám megoldódott. A tpl fájlok és minden egyéb js stb. ezek már utf-8-asra vannak állítva a html tag-gel együtt.

Köszöntem.

-------
It is our choices that define us.

"Mindössze annyi volt a baj, hogy a php fájlokat ANSI character encoding-gal kell tárolni"
nem azzal kell, de a php interpreter valoban nem ismeri a BOM-ot, ezért ha BOM-mal mentesz UTF-8as fájlt, akkor a BOM output-ként ki fog menni.
a BOM a masodik kommentben meg lett emlitve, mint szopas, de az nem ilyen tüneteket okozna(hanem furcsa karakterek jelennének meg minden html forrás előtt, ), szoval egeszen biztos vagyok benne, hogy a whitespace-es problemat nem az encoding es a BOM okozta.

Tyrael

Ok, elhiszem neked. A második post elkerülte akkor a figyelmem, most nem volt türelmem végigolvasni a kommenteket még1x, nyáron meg akkor nem figyeltem eléggé.

Mindenesetre pusztán azzal, hogy átállítottam ANSI-ra, már nem áll fent a probléma semmilyen böngészőben és semmilyen szerveren sem. ;)

-------
It is our choices that define us.