K čemu je v PHP dobré použít framework?

registrovany123 · « **kdy:** 02. 06. 2025, 06:17:54 »

Nikdy jsem v PHP nedělal, až poslední 2-3 roky jsem se naučil Vue a React, a následně jsem měl možnost něco dělat v PHP a jsem celkem některými věcmi překvapen.

Předně, mě je úplně jasné, že v tomhle jazyce se na webových projektech nachází napsaný totální binec, s mixováním php kódu a template, jak jsem to viděl, kde ještě ke věcmu místo aby autoři kódu v templates používali shorthands, tak tam dávají samé echo.

Ale.

Když si dávám pozor, abych měl PHP kód měl nahoře a HTML kód dole, a v tom HTML kódu používal pouze shorthands, tak to není méně přehledné, než když napíšu kód třeba v Reactu nebo ve Vue.

Ukázkový kód:

Kód: [Vybrat]

<?php
// Connect to SQLite
$db = new PDO('sqlite:items.db');
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

// Define order options as indexed array
$orderOptions = ['name DESC', 'price DESC'];

// Get filter and selected order index
$filter = isset($_GET['filter']) ? $_GET['filter'] : '';
$orderIndex = (isset($_GET['order']) && is_numeric($_GET['order']) && isset($orderOptions[$_GET['order']]))
    ? (int)$_GET['order']
    : null;

// Build SQL
$sql = "SELECT * FROM items WHERE 1=1 AND (:filter IS NULL OR name LIKE :filter)";
$params = [];

$params[':filter'] = $filter !== '' ? "%$filter%" : null;

if ($orderIndex !== null) {
    $sql .= " ORDER BY " . $orderOptions[$orderIndex];
}

// Fetch items
$stmt = $db->prepare($sql);
$stmt->execute($params);
$items = $stmt->fetchAll(PDO::FETCH_ASSOC);
?>

<!DOCTYPE html>
<html>
<head>
    <title>Item List</title>
</head>
<body>
    <h1>Items</h1>

    <form method="get">
        <input type="text" name="filter" value="<?= $filter ?>" placeholder="Filter by name">
        <select name="order">
            <option value="">-- Order by --</option>
            <option value="0" <?= $orderIndex === 0 ? 'selected' : '' ?>>Name ↓</option>
            <option value="1" <?= $orderIndex === 1 ? 'selected' : '' ?>>Price ↓</option>
        </select>
        <button type="submit">Apply</button>
    </form>

    <table>
        <thead>
            <tr>
                <th>ID</th><th>Name</th><th>Price</th>
            </tr>
        </thead>
        <tbody>
            <?php foreach ($items as $item): ?>
            <tr>
                <td><?= $item['id'] ?></td>
                <td><?= $item['name'] ?></td>
                <td><?= $item['price'] ?></td>
            </tr>
            <?php endforeach; ?>
        </tbody>
    </table>
</body>
</html>

V Reactu.js by to bylo složitější, bylo by napsáno víc. Navíc, hrabal jsem se teď v DokuWiki zdrojácích, a jsem celkem překvapen, že je to celkem přehledné - a žádný framework to nemá.

Jediné co mi vadí je poněkud obstaróžní práce s fragmenty:

Kód: [Vybrat]

    <?php $text = 'Ahoj světe'; $href = 'page2.php'; include 'nav-button.php' ?>

Kde v Raactu bych to měl o něco hezčí:

Kód: [Vybrat]

   <NavButton text="Ahoj světe" href="page2.php">

No ale zase za cenu náročnější konfigurace, no a musel bych si napsat ten backend.

Reklama

registrovany123 · « **Odpověď #1 kdy:** 02. 06. 2025, 06:33:32 »

A ještě mi vadí další věc, že v PHP je nějaká kultura abuzu ECHO, viz úryvek z pluginu v DokuWiki:

Kód: [Vybrat]

                echo '<dt>';
                echo '<span class="datetime">' . hsc($dt) . '</span>';
                echo '<span class="log">';
                echo '<span class="msg">' . hsc($msg) . '</span>';
                echo '<span class="file">' . hsc($file) . '</span>';
                echo '</span>';
                echo '</dt>';

Který by šel přitom napsat jako

Kód: [Vybrat]

echo <<<HTML
<dt>
    <span class="datetime">$dt</span>
    <span class="log">
        <span class="msg">$msg</span>
        <span class="file">$file</span>
    </span>
</dt>
HTML;

BlackMagic · « **Odpověď #2 kdy:** 02. 06. 2025, 07:11:41 »

Citace: registrovany123 02. 06. 2025, 06:33:32

Který by šel přitom napsat jako

Kód: [Vybrat]
echo <<<HTML <dt> $dt $msg $file </dt> HTML;

To taky není nejlepší. Když už, tak echo do HTML:

Kód: [Vybrat]

<html>
<dt>
    <span class="datetime"><?= $dt ?></span>
    <span class="log">
        <span class="msg"><?= $msg ?></span>
        <span class="file"><?= $file ?></span>
    </span>
</dt>
</html>

Ten úryvek z pluginu je prostě prasácký styl psaní z doby tak někdy PHP 4.

Vít Šesták (v6ak) · « **Odpověď #3 kdy:** 02. 06. 2025, 09:05:46 »

Kód: [Vybrat]

$filter = isset($_GET['filter']) ? $_GET['filter'] : '';
Co když tam někdo předá pole? Když do URL dám filter[]=foo, je tam pole. (BTW, v kombinaci se zapnutým zobrazení chyb je to často snadný způsob, jak trošku analyzovat cizí kód.)

Vhodný framework (nevím přesně situaci u PHP) to nejspíš zvládne ošetřit, včetně třeba ověření is_numeric u dalšího

Kód: [Vybrat]

<td><?= $item['name'] ?></td>
To je učebnicová ukázka HTML injection, a tedy XSS, ne? Frameworky to typicky z velké části řeší, byť třeba u odkazů (kam může přijít třeba javascript:alert(location.href)) si je stále někdy potřeba dát pozor. (I když to asi může řešit CSP.)

Kód: [Vybrat]

<?php $text = 'Ahoj světe'; $href = 'page2.php'; include 'nav-button.php' ?>Uf, oproti Reactímu kódu vidím docela velké rozdíly:

1. Reactí komponenta dostává jen ty parametry, které mu explicitně předáte, zatímco ten kód v include dostane celý scope. I pokud ten includnutý soubor bude využívat jen to, co dostal, může to snadno přitáhnout moji pozornost. Ale snadnost se (třeba při refactoringu) může stát, že omylem využije i něco navíc a kód bude zapletený.
2. Důsledek #1: když zapomenu předat nějaký parametr nebo se uťuknu v názvu, nemusím dostat chybu. Místo toho se tam může předat nějaký parametr z minula.
3. Reactí komponenta neovlivní proměnné tomu, kdo je vkládal, include může. Stačí mít na obou místech stejně pojmenovanou proměnnou…
4. Estetická stránka věci je asi tak to poslední.

Pravda, na tyto problémy není nutně potřeba Reactí komponenta, na to stačí obyčejná funkce.

registrovany123 · « **Odpověď #4 kdy:** 02. 06. 2025, 09:30:24 »

Citace: Vít Šesták (v6ak) 02. 06. 2025, 09:05:46

Kód: [Vybrat]
$filter = isset($_GET['filter']) ? $_GET['filter'] : '';
Co když tam někdo předá pole? Když do URL dám filter[]=foo, je tam pole. (BTW, v kombinaci se zapnutým zobrazení chyb je to často snadný způsob, jak trošku analyzovat cizí kód.)

Pokud se tam předá pole, bude tam pole - to nezpůsobí nic, zabráním-li SQL injection pomocí parametrizovaných queries.

Eventuálně pro web pro nějakou firmu který je obnažený do Internetu, by šlo napsat nějakou jednoduchou Util metodu pro získání těch parametrů a validaci.

Citace: Vít Šesták (v6ak) 02. 06. 2025, 09:05:46

Kód: [Vybrat]
<td><?= $item['name'] ?></td>
To je učebnicová ukázka HTML injection, a tedy XSS, ne? Frameworky to typicky z velké části řeší, byť třeba u odkazů (kam může přijít třeba javascript:alert(location.href)) si je stále někdy potřeba dát pozor. (I když to asi může řešit CSP.)

Ano, ten kód vede k proveditelnosti HTML injection, správně by se mělo vše vykreslovat přes funkci:

Kód: [Vybrat]

htmlspecialchars($item['name'] )

Nelíbí se mi ale, že to komplikuje template, takže tady by se asi hodil nějaký framework.

Citace: Vít Šesták (v6ak) 02. 06. 2025, 09:05:46

Kód: [Vybrat]
<?php $text = 'Ahoj světe'; $href = 'page2.php'; include 'nav-button.php' ?>Uf, oproti Reactímu kódu vidím docela velké rozdíly:

1. Reactí komponenta dostává jen ty parametry, které mu explicitně předáte, zatímco ten kód v include dostane celý scope. I pokud ten includnutý soubor bude využívat jen to, co dostal, může to snadno přitáhnout moji pozornost. Ale snadnost se (třeba při refactoringu) může stát, že omylem využije i něco navíc a kód bude zapletený.

Ano, je to další nevýhoda toho zápisu. Přesto, na vadné vstupní parametry mě umí částečně upozorní IDE (PHP Storm).

Na závěr bych chtěl říct, že nejsem profi programátor Internetových webů, dělám jen technické Intranetové webovky, a jinak nějaké drobnosti jako koníček. A jednoduchost použití PHP mě docela překvapila - jenom se vezme index.php, hodí se to do "/var/www/html" a je to, mám web.

Ještě o stupínek složitější, ale taky pořád jednoduché, je použít Python s Bottle třeba a k tomu templates.

Např. ani jeden z "jednoduchých" webů, které jsem dělal v Reactu, tak nemá tak dobře vyřešenou navigaci přes uri parametry, jako to udělá defaultně PHP. V Reactu se to musí naprgramovat, aby byla page řízená parametry přítomnými v URI, načež následně fungují dobře tlačítka Zpět a Vpřed v browseru, že.

Co mi ale na těch Server side technologiích trochu vadí je třeba to, že browser neumí uživatele vrátit zpátky na pozici na stránce, kde se nacházel při kliknutí na nějaký Submit. Jako např. že bych měl někde dole na vstupu formulár:

- Zadejte tel. číslo
- Button: Poslat ověřovací sms

Tak bohužel u server side renderingu neudělám to, že by browser nascroloval zpátky na to místo. Leda přes záložky, ale to se nechová idálně.

Reklama

Zopper · « **Odpověď #5 kdy:** 02. 06. 2025, 10:54:45 »

Citace: registrovany123 02. 06. 2025, 09:30:24

Co mi ale na těch Server side technologiích trochu vadí je třeba to, že browser neumí uživatele vrátit zpátky na pozici na stránce, kde se nacházel při kliknutí na nějaký Submit.

Tak ono by to šlo s javascriptem - ukládat scroll pozici do hidden field v tom formuláři, a pak se na to místo zas posunout.

cznarg · « **Odpověď #6 kdy:** 02. 06. 2025, 11:07:15 »

Citace: registrovany123 02. 06. 2025, 06:17:54

Předně, mě je úplně jasné, že v tomhle jazyce se na webových projektech nachází napsaný totální binec, s mixováním php kódu a template, jak jsem to viděl, kde ještě ke věcmu místo aby autoři kódu v templates používali shorthands, tak tam dávají samé echo.

Většinou ne, běžně se používá MVC pattern (a nějaký framework) který odděluje View od Modelu a Controlleru. Doba kdy se psaly takhle "běžně" skripty je už dávno pryč. Tak nějak od PHP5+

Citace: registrovany123 02. 06. 2025, 06:17:54

A jednoduchost použití PHP mě docela překvapila - jenom se vezme index.php, hodí se to do "/var/www/html" a je to, mám web.

No, to je právě ten problém kterým trpí PHP. Ono to takhle jde udělat ale nikdo se v tom nevyzná. Teda nikdo kdo programuje nějaký pátek. A úpravy budou porod.

Citace: registrovany123 02. 06. 2025, 06:17:54

Co mi ale na těch Server side technologiích trochu vadí je třeba to, že browser neumí uživatele vrátit zpátky na pozici na stránce, kde se nacházel při kliknutí na nějaký Submit. Jako např. že bych měl někde dole na vstupu formulár:

Ano, protože to je serverside. A prohlížeč musí načíst celou stránku znovu. Proto ten "reset" (neví že se jedná o tu samou stránku, jen třeba navíc s chybou). Osobně teď jsem třeba začal psát jeden soukromý projekt a už jsem to striktně začal oddělovat. SS jen API, front komplet Vue3 a všeobecně nějaký takový mix mě přijde jako nejlepší jak vytáhnout z obou světů to nejlepší

to_je_jedno · « **Odpověď #7 kdy:** 02. 06. 2025, 11:45:10 »

Proc framework?

1) proc pouzivas React ci Vue? Setri to praci.
2) kdyz nepouzijes framework tezko najdes ty (nebo zakaznik) kohokoliv, aby to upravil kdyz ty nebudes moct
3) proc vymyslet kolo?
4) prave s frameworkem omezujes bordel, delas kod prehlednym
5) kdyz pridas veci jako phpstan, phpunit, code standards tak se v ramci dobreho tymu stava PHP plně typovanym jazykem

PHP dnes je jine nez PHP 10 let zpatky (neco by bylo spatne kdyby to bylo stejne).

Decoupled sice prinasi nejakou komplexitu navic, ale zase umoznuje vyuzivat vyhody obou stran.

to_je_jedno · « **Odpověď #8 kdy:** 02. 06. 2025, 11:47:43 »

Citace: Vít Šesták (v6ak) 02. 06. 2025, 09:05:46

1. Reactí komponenta dostává jen ty parametry, které mu explicitně předáte, zatímco ten kód v include dostane celý scope. I pokud ten includnutý soubor bude využívat jen to, co dostal, může to snadno přitáhnout moji pozornost. Ale snadnost se (třeba při refactoringu) může stát, že omylem využije i něco navíc a kód bude zapletený.
2. Důsledek #1: když zapomenu předat nějaký parametr nebo se uťuknu v názvu, nemusím dostat chybu. Místo toho se tam může předat nějaký parametr z minula.
3. Reactí komponenta neovlivní proměnné tomu, kdo je vkládal, include může. Stačí mít na obou místech stejně pojmenovanou proměnnou…
4. Estetická stránka věci je asi tak to poslední.

Proto v PHP pouzivame napr Twig.

oss · « **Odpověď #9 kdy:** 02. 06. 2025, 12:26:15 »

Framework je v PHP dobry na to aby priniesol poriadok do PHP, ktory varili ako psicek a macicka (v JS je to rovnake).
A navyse, preco by clovek nechcel super sablonovaci jazyk, ktory bezi na inom sablonovacom jazyku?

speculatius · « **Odpověď #10 kdy:** 02. 06. 2025, 13:26:57 »

Framework za teba vyrieši veci, ktoré by si inak musel naprogramovať sám, prípadne sám lepiť dokopy rôzne knižnice. Napr:

- MVC architektúra, adresárová štruktúra projektu, routovanie URL na konkrétnu logiku, friendly URL, šablónovanie a tak
- formuláre, validácia vstupov, error handling
- security, authentication, authorization, RBAC, ochrana proti útokom ako SQL injection, XSS, CSRF...
- datová vrstva, najeký ORM systém, migrácie dát
- REST API, GraphQL API
- ...

Niektoré frameworky toho ponúkajú viac, iné menej (tzv "microframeworks"). Niektoré sú veľmi striktné ohľadom spôsobu ich použitia ("opiniated"), iné ti nechajú viac voľnosti. Stačí si vybrať.

Spomínal si, že poznáš React a Vue. Takže nejaký microframework s REST API a ORM by mohol byť pre teba fajn.

Ak plánuješ riešiť frontend priamo cez PHP bez JS frameworku, vyber si nejaký opiniated framework, ktorý poskytuje úplne všetko. Budeš mať menej priestoru urobiť nevhodné rozhodnutie.

to_je_jedno · « **Odpověď #11 kdy:** 02. 06. 2025, 15:04:46 »

Nez zacnes neco lepit tak se podivej na tyto pojmy: composer, PSR.

Vít Šesták (v6ak) · « **Odpověď #12 kdy:** 02. 06. 2025, 16:32:53 »

Citace: registrovany123 02. 06. 2025, 09:30:24

Citace: Vít Šesták (v6ak) 02. 06. 2025, 09:05:46
Kód: [Vybrat]
$filter = isset($_GET['filter']) ? $_GET['filter'] : '';
Co když tam někdo předá pole? Když do URL dám filter[]=foo, je tam pole. (BTW, v kombinaci se zapnutým zobrazení chyb je to často snadný způsob, jak trošku analyzovat cizí kód.)

Pokud se tam předá pole, bude tam pole - to nezpůsobí nic, zabráním-li SQL injection pomocí parametrizovaných queries.

Když se tam předá pole, často to způsobí maximálně warning, ale bez dalšího průzkumu těžko říct. Navíc uhlídat to u aplikace z která se vyvíjí, je dost náročné. Proto mi přijde jednodušší to prostě ošetřit a dál se spoléhat na to, že mám požadovaný typ.

Citace: registrovany123 02. 06. 2025, 09:30:24

Eventuálně pro web pro nějakou firmu který je obnažený do Internetu, by šlo napsat nějakou jednoduchou Util metodu pro získání těch parametrů a validaci.

Útočník může být i uvnitř sítě. Třeba malware na jednom stroji. A pokud uvažujeme o web bez HTTPS, je tam ještě více možností. Třeba pokud se neověřuje hlavička Host, pak DNS rebinding mi z prohlížeče uživatele udělá proxy, kterou se dostanu do vnitřní sítě. Nebo pokud jsou v síti přenosná zařízení, která se připojují leckam, může někdo udělat browser cache poisoning a jeho skript pak následně bude mít přístup k síti. Intranet za mě není důvod, proč se vykašlat na bezpečnost.

Ad util metoda – postupem času se takovéto věci nasbírají a najednou zjistíte, že si píšete vlastní framework…

registrovany123 · « **Odpověď #13 kdy:** 02. 06. 2025, 17:41:26 »

Tak díky za nadstandardně dobré rady, zejména panu Šestákovi, já měl představu, že to bude jednodušší, ale právě mi z toho asi vypadlo, že zůstane u mého komba Python Bottle + Vue.js (bez kompilace) pro moje jednoduché weby - a tohle schované za nějakým Apache nebo Nginx.

Jamile už nemůžu v PHP jednoduše něco udělat (Ty security omezení vyloženě tlačí do frameworku), tak to pro mě asi smysl moc nedává. Akorát teda - komunity, třeba herní nebo jiné, tak oni amatérsky znají PHP a mají rozjeté někdy i svoje hostující servery, takže tam to PHP má smysl, protože Vue a Pythonu by nerozuměli.

No a v práci stejně dělám backend v Javě, takže budu věřit, že vyjma SQL injection nemusím moc co v kombinaci s Vue.js řešit.

speculatius · « **Odpověď #14 kdy:** 03. 06. 2025, 13:56:21 »

Citace: registrovany123 02. 06. 2025, 17:41:26

No a v práci stejně dělám backend v Javě, takže budu věřit, že vyjma SQL injection nemusím moc co v kombinaci s Vue.js řešit.

PHP má oproti Jave tú výhodu, že backend rozbehneš na lacnom hostingu za pár desiatok eur na rok. Naproti tomu, pre Java backend budeš potrebovať aspoň VPS server, a to stojí rádovo 10x viac. Plus potrebuješ byť trochu zbehlý v administrácii vlastného servera. V závislosti od tvojich potrieb to možno zaváži, možno nie

Mimochodom, framework pre PHP má zhruba taký istý význam, ako framework pre Javu. Ten backend v práci určite nepíšeš v čistom Java Servlet API, ale používaš niečo ako Spring.

K čemu je v PHP dobré použít framework?

registrovany123

K čemu je v PHP dobré použít framework?

Reklama

registrovany123

Re:K čemu je v PHP dobré použít framework?

BlackMagic

Re:K čemu je v PHP dobré použít framework?

Vít Šesták (v6ak)

Re:K čemu je v PHP dobré použít framework?

registrovany123

Re:K čemu je v PHP dobré použít framework?

Reklama

Zopper

Re:K čemu je v PHP dobré použít framework?

cznarg

Re:K čemu je v PHP dobré použít framework?

to_je_jedno

Re:K čemu je v PHP dobré použít framework?

to_je_jedno

Re:K čemu je v PHP dobré použít framework?

oss

Re:K čemu je v PHP dobré použít framework?

speculatius

Re:K čemu je v PHP dobré použít framework?

to_je_jedno

Re:K čemu je v PHP dobré použít framework?

Vít Šesták (v6ak)

Re:K čemu je v PHP dobré použít framework?

registrovany123

Re:K čemu je v PHP dobré použít framework?

speculatius

Re:K čemu je v PHP dobré použít framework?