Portál AbcLinuxu, 4. května 2025 11:47
Po pěti letech od vydání verze 7.0.0 byla vydána nová major verze 8.0.0 skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Nejnovější větev PHP přináší celou řadu nových novinek a vylepšení. Vydána byla také příručka pro přechod z předchozích verzí.
Tiskni
Sdílej:
Neustale vyjasnovani rovnosti cisla a stringu je fakt vtipne
Pouziva to nekdo v roce 2020?Navrhni lepší alternativu. Cvičení: Python a třeba Flask → rezidentní aplikace trvale držená v paměti nebo příšerný overhead kompletní inicializace interpretru (nepoužitelné na multihostingu, kde je žilión takových věcí, na které skoro nikdo nechodí, na jednom stroji); v podstatě vynucený šablonovací systém místo napsání
27.11.2020 22:48
<?python kus_kódu(); ?> do existující stránky; z toho vyplývající „deploy“ a „reload“ a obecná nepřátelskost k lidem co se tomu nechtějí věnovat, ale chtějí rychle udělat jednu stránku se dvěma tabulkama.
chtějí rychle udělat jednu stránku se dvěma tabulkama.
+1
Přestože většinu softwaru píšu v Javě a mám ji rád, musím říct, že na takhle malé věci je PHP pořád asi nejlepší volba – a vlastně se mi v takových případech i líbí ten klasický přístup z dob, kdy PHP začínalo…
Ono sice pro většinu jazyků (včetně té Javy) existují líbivé tutoriály o tom, jak si uděláš webovou aplikaci napsáním pěti řádků kódu. Ale: jednak je to většinou větší prasárna než to PHP a skutečné aplikace se takhle nepíší a jednak to právě vyžaduje, aby na serveru běžel trvale nějaký proces a spotřebovával RAM. Přesně, jak píšeš:
rezidentní aplikace trvale držená v paměti nebo příšerný overhead kompletní inicializace interpretru (nepoužitelné na multihostingu, kde je žilión takových věcí, na které skoro nikdo nechodí, na jednom stroji)
Navrhni lepší alternativu. ... obecná nepřátelskost k lidem co se tomu nechtějí věnovat, ale chtějí rychle udělat jednu stránku se dvěma tabulkama.Je otazkou, pro co to ma byt alternativa. Matne si pamatuju, ze nekdy v davnych casech, rikejme jim devadesata leta, slo udelat, ze server identifikoval element <script> a tak se daly delat server-side scripty v JavaScriptu nebo Visual Basicu. Ani jedno z toho neni zrovna lepsi alternativa, ale kdyby misto <?php ?> slo pouzit libovolny jazyk podle potreby, mohl by spouste lidi stacit i ten obycejny Python bez flasku, a byl by to krok vpred. Pokud potrebujes rychle udělat jednu stránku se dvěma tabulkama je v zasade jedno, co pro to pouzijes, treba i bash. Problem u PHP je, ze rada projektu preroste sve puvodni urceni nebo spis schopnosti svych autoru a stanou se z nich desiva monstra, ktera se objevuji ve statisicich ruznych instanci. Wordpress nebo phpBB jsou dokonale priklady toho, jak by se nemelo programovat a (to nejen v PHP), pouzivaji prasarny, o kterych se uz pred dvaceti lety vedelo, ze to jsou prasarny, ale presto to lidi pouzivaji se vsemi dusledky. Je otazka, jestli u takto velkych veci uz by tou alternativou nebyl jiny civilizovany jazyk, treba ten Python nebo Java.
slo udelat, ze server identifikoval element <script> a tak se daly delat server-side scripty v JavaScriptu nebo Visual Basicu. Ani jedno z toho neni zrovna lepsi alternativa, ale kdyby misto <?php ?> slo pouzit libovolny jazyk podle potreby, mohl by spouste lidi stacit i ten obycejny Python bez flasku, a byl by to krok vpred.
Ono tím devadesátkovým stylem se dají psát i JSPčka – a taky se tak psala – prostě HTML stránka, do které sem tam vložím nějaký aktivní kód vykonávaný na serveru, sem tam třeba SQL dotaz atd. Víceméně se tak dá psát i dneska a je to hodně podobné tomu PHP.
Pak se na to <?php ?> taky můžeme dívat jako na instrukci zpracování XML (PI) a napsat si nějaký jednoduchý preprocesor, který rozparsuje XML, z těch ne-PI částí vyrobí něco jako echo "…" a ty PI části vloží doslova a výsledkem je skript v nějakém jazyce, který se akorát spustí a jeho STDIN (nebo výsledek volání nějakých metod/funkcí) se zase poskládá dohromady a pošle klientovi.
Takhle se dá snadno implementovat třeba <?bash ?>, <?perl ?>, <?python ?> nebo cokoli jiného. Není to těžké a dokonce jsem si říkal, že bych si to cvičně napsal. Ale úskalí tohoto přístupu je v tom, že se tu pracuje s textem, takže není zaručeno, že na výstupu bude validní XML/XHTML nebo že programátor nezapomene něco escapovat. Taky je to nešikovné pro plnění atributů. Dají se tím oIFovat třeba elementy nebo je namnožit v cyklu. Ale nepřijde mi to moc čisté. To už je lepší XSLT či XQuery. Pro jiné formáty než XML je taky potřeba, aby ten preprocesor rozuměl tomu vnějšímu formátu a věděl, co je instrukce zpracování a co tak pouze vypadá, ale ve skutečnosti je to třeba komentář nebo textový literál v tom daném formátu…
Ono tím devadesátkovým stylem se dají psát i JSPčkaTady nejde ani tak o styl, ten je dneska (dikybohu) vetsinou povazovany za prekonany. Ale slo mi o to, ze sel pouzit univerzalni element <script>, kde se v parametru nastavil jazyk a jestli se ma provest na klientu nebo serveru. Ale uz si nevzpomenu, kde a jak to fungovalo. V te dobe jsem byl rad, ze to nejak fungovalo a i tak jsem nakonec radeji mastil scriptu v Perlu. Matne si vybavuju, ze tam byly omezeni typu, ze tagy musi byt na zacatku radku, nesmi za nimi nic byt, apos.
Takhle se dá snadno implementovat třeba <?bash ?>, <?perl ?>, <?python ?> nebo cokoli jiného. Není to těžké a dokonce jsem si říkal, že bych si to cvičně napsal. Ale úskalí tohoto přístupu je v tom, že se tu pracuje s textem, takže není zaručeno, že na výstupu bude validní XML/XHTML nebo že programátor nezapomene něco escapovat.Vystupem nemusi byt validni XML/XHTML. A muzes to udelat jednoduse, jak se prekladaji JSP. Celou stranku prevedes na jednu velkou funkci/metodu/skript podle jazyka. Kde, co je textovy vstup (v tvem pripade XML) prevedes na nejako
28.11.2020 00:33
echo "<?xml..." nebo out.println("<?xml") a co je v processing instruction vlozis primo a pak to prozenes interpretem a co vypadne na STDOUT posles klientovi.
Pripadne pokud bys to chtel mit ala to moje reseni z davnych casu. Udelas si pruchod SAXem a narazis-li na element script vlozis kod a pokud nechces resit escapovani v kodu, vlozis to do CDATA.
To už je lepší XSLT či XQuery.To me preslo nekdy kolem roku 2002.
Celou stranku prevedes na jednu velkou funkci/metodu/skript podle jazyka. Kde, co je textovy vstup (v tvem pripade XML) prevedes na nejako echo "<?xml..." nebo out.println("<?xml") a co je v processing instruction vlozis primo a pak to prozenes interpretem a co vypadne na STDOUT posles klientovi.
Ano, přesně to jsem se snažil říct, tím:
jednoduchý preprocesor, který rozparsuje XML, z těch ne-PI částí vyrobí něco jako echo "…" a ty PI části vloží doslova a výsledkem je skript v nějakém jazyce
Přemýšlím, jestli by to bylo užitečné… na jednu stranu je to takové trochu prasení a člověk se tam může snadno střelit do nohy, na druhou stranu je to implementačně jednoduché a zároveň hodně mocné. V některých případech by mohl být výstupem i zdroják, který se přeloží na nativní binárku, která se pak bude pouštět jako CGI nebo volat jako sdílená knihovna. V jiných případech by se to jen interpretovalo jako skript.
Ještě mne napadá k tomu:
Taky je to nešikovné pro plnění atributů.
ono by v těch atributech šlo rozpornávat {} nebo ${} (viz syntaxe JSP nebo XSLT) a akorát na tom místě přerušit uvozovky echo "…" / out.print("…") a vložit tam (escapovanou) proměnnou nebo vyhodnocený výraz z {}.
Vystupem nemusi byt validni XML/XHTML. A muzes to udelat jednoduse, jak se prekladaji JSP.
Šlo mi spíš o to, že když budeš chtít generovat třeba CSS nebo JavaScript, tak ten preprocesor musí rozumět těmto jazykům a vědět, že nemá interpretovat třeba /** <?bash … > */ protože to v daném jazyce je zakomentované, zatímco v XML by to byly dva textové uzly a mezi nimi PI. Ale pak by bylo potřeba mít způsob, jak v syntaxi toho jazyka najít jeho PI… Nebo to brát pouze jako text, tzn. ta šablona by byla XML, akorát by bylo nějak řečeno, že se její kořenový element nemá vkládat jako element, ale že se má vložit jen jeho textový obsah a interpretovat PI.
<text content-type="text/css" xmlns="…">
body {
color: <?bash … ?>
}
</text>
Kde si ale veškeré escapování řešíš uvnitř těch skriptů, protože preprocesor té syntaxi kolem nerozumí a je to pro něj jen text.
... napsání <?python kus_kódu(); ?> do existující stránky...
Sice existuje libapache2-mod-python, ale ten zda se tohle embedovani neumi. A pritom by to bylo velice prakticke na takove to domaci bastleni.
Problém CGI je v tom, že se pokaždé dělá fork(), takže při vyšší návštěvnosti je to neefektivní. Ale tenhle problém řeší FastGCI.
Když to srovnáš třeba s tou Javou, tak tam už se pak volají jen metody. Procesy i vlákna jsou připravené předem a vše je načteno v paměti, takže je to hodně rychlé – ten fork() oproti tomu bude pomalý. Ale daň za to zase je to, že aplikaci musíš mít nastartovanou předem a žere ti RAM – což nechceš dělat pro ty spousty stránek, na které se jen občas přijde někdo podívat. Dá se to řešit různým uspáváním a případně i socket activation, kde pak uspaná aplikace nežere vůbec nic, protože běží jen super-server – rodičovský proces, který drží otevřený socket a v případě potřeby službu spustí. Ale k takovým optimalizacím většinou není potřeba přistupovat a obvykle stačí si vybrat jeden z těch základních přístupů (což někdy může být klidně PHP nebo CGI skript – a jindy zase klasický javovský aplikační server).
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
