Framework vs. čistý kód

[registrovany123]

Ještě jednou pro méně chápavé, takto vypadá "Šablona je kód". Mám v PHP (JSP,ASP) tohle:

Kód: [Vybrat]

<h1>Seznam uživatelů</h1>

<ul>
<?php foreach ($users as $user): ?>
    <li><?= htmlspecialchars($user['name']) ?></li>
<?php endforeach; ?>
</ul>

A přeloží se to na tohle:

Kód: [Vybrat]

<?php
echo "<h1>Seznam uživatelů</h1>\n";
echo "<ul>\n";
foreach ($users as $user) {
    echo "    <li>" . htmlspecialchars($user['name']) . "</li>\n";
}
echo "</ul>\n";
?>

Není divu, že IDE, které má 100% podporu pro PHP, tak bez potíží i dokáže mít 100% podporu pro výše uvedené, aby se v tom dalo zcela bez výhrad refaktorovat.

[Reklama]

[Kit]

A přeloží se to na tohle:

K takovému překladu do PHP vůbec nedochází, ale obě zmíněné šablony jsou přeloženy do binárního mezikódu, který je následně interpretován.

[Filip Jirsák (forum)]

Ale já to chápu celou dobu – vymýšlíte si nemyslné termíny, kterým sám neorzumíte; a vymýšlíte si nesmyslné konstrukce.

Každá šablona se nakonec přeloží do instrukcí, které se provedou na procesoru. Někdy je tam víc kroků překladu, někdy jen jeden. Někdy se ty kroky překladu dají jednoduše serializovat, někdy jsou jen v paměti. Někdy se dokonce dají serializovat do nějakého běžného programovacího jazyka, jindy to je třeba jen nějaký AST. To, že se JSP překládaly do zdorjového kódu Javy, byla mezi šablonami spíše výjimka. A IDE to vůbec nijak nepomáhá – například pro to, že IDE potřebuje mít obousměrnou vazbu mezi kódem a jeho vnitřní reprezentací, a zatímco každé JSP můžete přeložit do Servletu, ne každý Servlet můžete přeložit do JSP. Takže používat v IDE pro reprezentaci JSP formu přeloženou do Servletu by bylo velmi kontraproduktivní.

[snugar_i]

100% fungují jen PHP, prvotní varianta JSP bez EL, nové JTE

JTE je jen další template engine, který má taky "vymyšlené svoje tagy". Jen mu prostě udělali dobrý plugin do Intellij. Není to, že to "samo funguje", protože to vypadá jako Java. Zdrojáky IDE pluginu mají 7247 řádků ve 136 souborech.

Navíc tyhle "template je kód" svádí k prasení, kdy po chvíli lidi začnou dělat DB dotazy v šabloně, protože to jde. Někomu to vyhovuje (než se v tom zamotá tak, že musí celý projekt zahodit/přepsat), jiní mají radši striktnější oddělení...

[Kit]

Navíc tyhle "template je kód" svádí k prasení, kdy po chvíli lidi začnou dělat DB dotazy v šabloně, protože to jde. Někomu to vyhovuje (než se v tom zamotá tak, že musí celý projekt zahodit/přepsat), jiní mají radši striktnější oddělení...

Kdysi jsem dělal import z XML do MySQL pomocí XSLT. Bylo to hnusné, ale všechny ostatní způsoby byly tak pomalé, že se ten import nedal stihnout do 24 hodin, což byl horní časový limit. Přede mnou to řešilo x lidí a právě XSLT to zvládl přes PI tuším za hodinu. Dnes doba pokročila a použil bych vhodnější metodu, protože to prostě bylo nečisté řešení.

V šabloně se dá udělat kdeco.

[Reklama]

[Filip Jirsák (forum)]

Kdysi jsem dělal import z XML do MySQL pomocí XSLT. Bylo to hnusné, ale všechny ostatní způsoby byly tak pomalé, že se ten import nedal stihnout do 24 hodin, což byl horní časový limit. Přede mnou to řešilo x lidí a právě XSLT to zvládl přes PI tuším za hodinu. Dnes doba pokročila a použil bych vhodnější metodu, protože to prostě bylo nečisté řešení.

V šabloně se dá udělat kdeco.

Pro zajímavost, co to bylo za procesor? U velkých objemů dat hodně záleží na tom, jestli se XSLT procesor pokusí načíst celé XML do paměti jako DOM a pak ho naivně prochází pomocí XPath výrazů, nebo jestli XML zpracovává jako stream (čemuž také musí být přizpůsobená XSLT šablona).

[Kit]

Kdysi jsem dělal import z XML do MySQL pomocí XSLT. Bylo to hnusné, ale všechny ostatní způsoby byly tak pomalé, že se ten import nedal stihnout do 24 hodin, což byl horní časový limit. Přede mnou to řešilo x lidí a právě XSLT to zvládl přes PI tuším za hodinu. Dnes doba pokročila a použil bych vhodnější metodu, protože to prostě bylo nečisté řešení.

V šabloně se dá udělat kdeco.

Pro zajímavost, co to bylo za procesor? U velkých objemů dat hodně záleží na tom, jestli se XSLT procesor pokusí načíst celé XML do paměti jako DOM a pak ho naivně prochází pomocí XPath výrazů, nebo jestli XML zpracovává jako stream (čemuž také musí být přizpůsobená XSLT šablona).

Byla to třída XSLTProcessor v PHP. Byl to asi milión položek ceníku, který jsem nejprve natáhl do DOM. SAXem to ani nemělo smysl parsovat, protože ten je v PHP šíleně pomalý. XSLT jelo rychle, úzkým hrdlem pak byla databáze. Je to už dávno, tenkrát bylo aktuální PHP 5.3.

[Kit]

Pro zajímavost, co to bylo za procesor? U velkých objemů dat hodně záleží na tom, jestli se XSLT procesor pokusí načíst celé XML do paměti jako DOM a pak ho naivně prochází pomocí XPath výrazů, nebo jestli XML zpracovává jako stream (čemuž také musí být přizpůsobená XSLT šablona).

Co bys použil, pokud bys potřeboval cca milión položek z XML (~150 MB) předžvýkat a nahrnout do MySQL?

[Filip Jirsák]

Pro zajímavost, co to bylo za procesor? U velkých objemů dat hodně záleží na tom, jestli se XSLT procesor pokusí načíst celé XML do paměti jako DOM a pak ho naivně prochází pomocí XPath výrazů, nebo jestli XML zpracovává jako stream (čemuž také musí být přizpůsobená XSLT šablona).

Co bys použil, pokud bys potřeboval cca milión položek z XML (~150 MB) předžvýkat a nahrnout do MySQL?

Já? Ten objem dat není moc velký, takže pokud bych nad těmi daty nepotřeboval před nalitím do databáze provádět nějakou složitější byznys logiku, použil bych XSLT (Saxon). Pokud by tam byla složitější logika, napsal bych si to v Groovy nebo v Javě s použitím dom4j.

[Kit]

Co bys použil, pokud bys potřeboval cca milión položek z XML (~150 MB) předžvýkat a nahrnout do MySQL?

Já? Ten objem dat není moc velký, takže pokud bych nad těmi daty nepotřeboval před nalitím do databáze provádět nějakou složitější byznys logiku, použil bych XSLT (Saxon). Pokud by tam byla složitější logika, napsal bych si to v Groovy nebo v Javě s použitím dom4j.

To zní zajímavě, ale pokud vím, Saxon neumí přímo zapisovat do MySQL. Byla tam sice potřebná nějaká logika, ale s tou si XSLT snadno poradilo. Poradí si Saxon třeba i s apostrofy v datech? V injektovaném PHP jsem na to použil prepared statements.

[Tomas-T]

Použít XSLT nebo vlastní kód na ty potřebné úpravy je OK, ale na samotné rychlé nalití výsledku do MySQL je doporučováno použít LOAD DATA příkaz.

[Filip Jirsák]

To zní zajímavě, ale pokud vím, Saxon neumí přímo zapisovat do MySQL. Byla tam sice potřebná nějaká logika, ale s tou si XSLT snadno poradilo. Poradí si Saxon třeba i s apostrofy v datech? V injektovaném PHP jsem na to použil prepared statements.

Saxon je jen XSLT 3.0 procesor s nějakými rozšířeními. Placená verze má rozšíření SQL, ale já jsem takové věci řešil tak, že jsem pomocí XSLT vygeneroval SQL skript. Kdyb potřeboval přímo při práci s XML spouštět SQL příkazy, spíš bych to napsal v Groovy nebo Javě. Pokud bych to řešil v XSLT, apostrofy v datech bych asi vyřešil funkcí replace.

Do Saxonu se dají psát i vlastní funkce a rozšíření, ale už to není tak jednoduché, takže pro jednorázovou věc se to nevyplatí.

Ale ono to hodně závisí na konkrétní situaci. Někdy jsem to XML třeba potřeboval nejdřív prozkoumat, takže jsem psal různé XPath výrazy, abych zjistil, co je tam vlastně za data. A pak už jsem měl sadu XPath výrazů, které stačilo jen trochu obalit do XSLT a bylo hotovo. Jindy k tomu zase potřebuju dodělat stažení souboru odnkěud z HTTP, rozzipování, nějaké zpracování textů uvnitř elementů. A to XML je jen posloupnost záznamů, vpodstatě XSV převedené do XML – tak to radši zpracuju v Javě nebo Groovy, protože pracuju vždy jen s jedním záznamem, takže bych nevyužil sílu XSLT, a dokážu tak zpracovat potenciálně nekonečný XML.

[Michal Šmucr]

To zní zajímavě, ale pokud vím, Saxon neumí přímo zapisovat do MySQL. Byla tam sice potřebná nějaká logika, ale s tou si XSLT snadno poradilo. Poradí si Saxon třeba i s apostrofy v datech? V injektovaném PHP jsem na to použil prepared statements.

Saxon pro jednorázové importy i velkých dat (různé číselníky, exporty) používám taky. Zrovna u MySQL je výhoda, že má přímo funkci pro natažení XML, která je relativně velmi rychlá (v rámci zpracování s jedním připojením).
https://dev.mysql.com/doc/refman/8.4/en/load-xml.html
Takže vstupní XML transformuju podle XSLT Saxonem na dočasný XML pro import se strukturou cílové tabulky (nebo víc, pokud je potřeba), a následně natáhnu zmíněným LOAD XML třeba přes mysql konzolový klient.
Samozřejmě pokud by šlo o něco periodického nebo bych třeba chěl využít třeba segmentování dat a víc spojení do db, něco bych si napsal.

[Kit]

To zní zajímavě, ale pokud vím, Saxon neumí přímo zapisovat do MySQL. Byla tam sice potřebná nějaká logika, ale s tou si XSLT snadno poradilo. Poradí si Saxon třeba i s apostrofy v datech? V injektovaném PHP jsem na to použil prepared statements.

Saxon je jen XSLT 3.0 procesor s nějakými rozšířeními. Placená verze má rozšíření SQL, ale já jsem takové věci řešil tak, že jsem pomocí XSLT vygeneroval SQL skript. Kdyb potřeboval přímo při práci s XML spouštět SQL příkazy, spíš bych to napsal v Groovy nebo Javě. Pokud bych to řešil v XSLT, apostrofy v datech bych asi vyřešil funkcí replace.

Do Saxonu se dají psát i vlastní funkce a rozšíření, ale už to není tak jednoduché, takže pro jednorázovou věc se to nevyplatí.

Na ty mé účely vyhovuje XSLT 1.0, které poskytuje utilita xsltproc nebo v PHP třída XSLTProcessor. Právě to druhé jsem použil, protože umožňuje v XPath použití php:function(...)

Ale ono to hodně závisí na konkrétní situaci. Někdy jsem to XML třeba potřeboval nejdřív prozkoumat, takže jsem psal různé XPath výrazy, abych zjistil, co je tam vlastně za data. A pak už jsem měl sadu XPath výrazů, které stačilo jen trochu obalit do XSLT a bylo hotovo. Jindy k tomu zase potřebuju dodělat stažení souboru odnkěud z HTTP, rozzipování, nějaké zpracování textů uvnitř elementů. A to XML je jen posloupnost záznamů, vpodstatě XSV převedené do XML – tak to radši zpracuju v Javě nebo Groovy, protože pracuju vždy jen s jedním záznamem, takže bych nevyužil sílu XSLT, a dokážu tak zpracovat potenciálně nekonečný XML.

Tohle vše zvládá i PHP, ve kterém byl napsán celý e-shop. Jen s tím nekonečným XML by to bylo trochu horší, protože SAX je v PHP docela pomalý. Tedy aspoň tenkrát byl.

Saxon pro jednorázové importy i velkých dat (různé číselníky, exporty) používám taky. Zrovna u MySQL je výhoda, že má přímo funkci pro natažení XML, která je relativně velmi rychlá (v rámci zpracování s jedním připojením).
https://dev.mysql.com/doc/refman/8.4/en/load-xml.html
Takže vstupní XML transformuju podle XSLT Saxonem na dočasný XML pro import se strukturou cílové tabulky (nebo víc, pokud je potřeba), a následně natáhnu zmíněným LOAD XML třeba přes mysql konzolový klient.
Samozřejmě pokud by šlo o něco periodického nebo bych třeba chěl využít třeba segmentování dat a víc spojení do db, něco bych si napsal.

Saxon je asi nejlepším nástrojem, ale pokud vím, tak nespolupracuje s PHP. Musel bych tuto část aplikace poskládat jinak. LOAD XML mi tenkrát nechtěl fungovat podle mých představ.

Pokud vím, tak žádný framework tohle neřeší. Přesněji podle původního algoritmu to trvalo víc než 24 hodin a bylo to nutné spouštět automaticky denně.

[Filip Jirsák (forum)]

Chápu, ž epoužíváte, co máte dostupné v nástrojích, na které jste zvyklý.  Ale nemůžu nezmínit, že XSLT 2.0 je výrazně bohatší, než XSLT 1.0 – umožňuje to přímo v XSLT řešit spoustu věcí, které se v XSLT 1.0 musely složitě obcházet nebo řešit pre- nebo post-processingem.

Existuje i varianta SaxonC, která se dá použít z PHP. Ale víc o tom nevím a nevím, jak je na tom v porovnání s „originálním“ Saxonem v Javě.

To php:function(…) je samozřejmě mocný nástroj. V tomhle měla Java nevýhodu, že vkládat do Javy skripty nebylo snadné. Pak vzniklo Java Scripting API a dnes by bylo nejlepší napojit to na GraalVM Truffle, ale pokud vím, nic z toho Saxon out-of-box nepodporuje.