Jak mockovat třídy, které jsou definované jako final nebo
některé z jejich metod jsou final?
Mockování znamená nahrazení původního objektu za jeho testovací
imitaci, která neprovádí žádnou funkci a jen se tváří jako původní
objekt. A předstírá chování, které potřebujeme kvůli testování.
Takže například místo objektu PDO s metodami jako query() apod.
vytvoříme jeho mock, který práci s databází jen předstírá, a místo
toho ověřuje, že se volají ty správné SQL příkazy atd. Více třeba
v dokumentaci
Mockery.
A aby bylo možné mock předávat metodám, které mají type hint
PDO, je potřeba, aby i třída mocku dědila od PDO. A to může
být kámen úrazu. Pokud by totiž třída PDO nebo metoda query() byla final,
už by to nebylo možné.
Existuje nějaké řešení? První možnost je final vůbec
nepoužívat. To ovšem nepomůže s kódem třetích stran, který final
používá, ale hlavně se tím ochuzujeme o důležitý prvek objektového
návrhu. Existuje dogma, že každá třída by měla být buď final, nebo
abstract.
Druhou a velmi šikovnou možností je použít Nette Tester, který od verze 2.0 disponuje
vychytávkou, která odstraňuje z kódu klíčové slovo final
on-the-fly. Stačí na začátku testu zavolat:
require __DIR__ . '/vendor/autoload.php';
Tester\Environment::bypassFinals();
A je to. Je za tím ukrytá neskutečně černá magie 🙂
Pokud nepoužíváte Nette Tester, ale třeba PHPUnit, nebudete ochuzeni,
stačí si nainstalovat BypassFinals:
composer require dg/bypass-finals --dev
A na začátku skriptu zavoláte:
require __DIR__ . '/vendor/autoload.php';
DG\BypassFinals::enable();
Názvoslovný oříšek: jak souhrnně označovat třídy a rozhraní? Jak
třeba nazvat proměnnou, která může obsahovat jak název třídy, tak
rozhraní? Co zvolit místo $class?
Dá se tomu říkat type ($type), nicméně to je zase
příliš obecné, protože typem je i řetězec nebo pole. Z pohledu jazyka
jím může být i něco komplikovanějšího, třeba ?array.
Navíc je sporné, co je v případě objektu jeho typ: je jím název třídy,
nebo je to object?
Nicméně souhrnné označení pro třídy a rozhraní skutečně existuje:
je jím slovo třída.
Cože?
- Z pohledu deklarace je interface hodně ořezaná třída. Může obsahovat
jen veřejné abstraktní metody. Což také implikuje nemožnost vytvářet
objekty. Rozhraní jsou tedy podmnožinou tříd. A pokud je něco
podmnožinou, tak to můžeme označovat názvem nadmnožiny. Člověk je savec,
stejně jako rozhraní je třída.
- Nicméně je tady ještě pohled užití. Třída může dědit jen od
jedné třídy, ale může implementovat vícero rozhraní. Nicméně tohle je
omezení týkající se tříd, samotné rozhraní za to nemůže. Obdobně:
třída nemůže dědit od final třídy, ale přitom final třídu pořád
vnímáme jako třídu. A také pokud třída může implementovat víc
rozhraní (tj. tříd, viz 1.), stále je vnímejme jako třídy.
A co traity? Ty sem vůbec nepatří, z hlediska OOP jednoduše
neexistují.
Tedy problém se společným pojmenováním tříd a rozhraní je vyřešen.
Říkejme jim prostě třídy.
classes + interfaces = classes
No jo, ale vznikl tady problém nový. Jak říkat třídám, které nejsou
rozhraní? Tedy jejich doplňku. Tomu, co se ještě na začátku článku
nazývalo třídy. Nerozhraní? Nebo implementations? 
To je ještě větší oříšek. To je pořádný ořech. Víte co, raději
zapomeňme na to, že rozhraní jsou také třídy, a tvařme se opět, že
každý OOP identifikátor je buď třída, nebo rozhraní. Bude to
snazší.
Jak se zbavit upozorňování PhpStormu, NetBeans nebo dalších IDE na
„undefined fields“ a aktivovat napovídání u objektu
$this->template v presenterech?
Tedy jak změnit tento pohled s podtrženým abc a prázdným
napovídacím okénkem:
Na tento?
Jednoduše. Stačí do presenteru (například BasePresenter) doplnit tuto
anotaci:
/**
* @property-read \Nette\Bridges\ApplicationLatte\Template|\stdClass $template
*/
abstract class BasePresenter extends Nette\Application\UI\Presenter
Pozn.: v nejnovějších verzích Nette 2.4 až je tato anotace přímo v kódu.
Třída šablony
Třída stdClass v anotaci je workaround pro PhpStorm, který
jinak všechny proměnné považuje za nedefinované. Nicméně zajímavější
je si vytvořit třídu se seznamem skutečných proměnných, které šablona
má, včetně jejich typů. Může vypadat třeba takto:
class ArticleTemplate extends Nette\Bridges\ApplicationLatte\Template
{
/** @var string */
public $lang;
/** @var int */
public $page;
/** @var string[] */
public $menu;
/** @var Model\Page */
public $article;
}
a potom ji v anotaci konkrétního presenteru uvedeme namísto
stdClass:
/**
* @property-read ArticleTemplate $template
*/
final class ArticlePresenter extends Nette\Application\UI\Presenter
Od této chvíle je napovídání perfektní:
Aktualizace: Latte
plugin už podporuje napovídání přímo v šablonách. Stačí přidat
{templateType App\Presenters\ArticleTemplate} na začátek
šablony.
A co se ani v dokumentaci nedočtete, včetně záplaty na
bezpečnostní díru a rady, jak zrychlit odezvu serveru a naopak ji
nezbrzdit.
Output buffering umožňuje, aby výstup PHP skriptu (především funkcí
echo) nebyl okamžitě odeslán do prohlížeče nebo terminálu,
ale byl uchováván v paměti (tj. bufferu). Což se hodí k celé
řadě věcí.
Zabránění vypisování na výstup:
ob_start(); // zapne output buffering
$foo->bar(); // veškerý výstup jde pouze do bufferu
ob_end_clean(); // buffer smaže a ukončí buffering
Zachytávání výstupu do proměnné:
ob_start(); // zapne output buffering
$foo->render(); // výstup jde pouze do bufferu
$output = ob_get_contents(); // obsah bufferu uloží do proměnné
ob_end_clean(); // buffer smaže a ukončí buffering
Dvojici ob_get_contents()
a ob_end_clean()
lze nahradit jedinou funkcí ob_get_clean(),
z jejíhož názvu se sice vytratilo end, ale skutečně output
buffering i vypíná:
$output = ob_get_clean(); // obsah bufferu uloží do proměnné a vypne buffering
V uvedených příkladech se obsah bufferu na výstup vůbec nedostal. Pokud
jej naopak na výstup poslat chci, namísto ob_end_clean() jej
ukončím funkcí ob_end_flush()
. Pro současné získání obsahu bufferu, odeslání na výstup a ukončení
bufferování existuje opět zkratka (i včetně chybějícího
end v názvu): ob_get_flush().
Buffer lze kdykoliv vyprázdnit i bez nutnosti jej ukončit, a to pomocí ob_clean()
(smaže jej) a nebo ob_flush()
(pošle jej na výstup):
ob_start(); // zapne output buffering
$foo->bar(); // veškerý výstup jde pouze do bufferu
ob_clean(); // smažu obsah bufferu, ale buffering zůstává aktivní
$foo->render(); // výstup jde stále do bufferu
ob_flush(); // buffer posílám na výstup
$none = ob_get_contents(); // obsah bufferu je nyní prázdný řetězec
ob_end_clean(); // vypne output buffering
Do bufferu se posílá i výstup zapisovaný na php://output,
naopak buffery lze obejít zápisem na php://stdout (nebo do
STDOUT), což je k dispozici pouze pod CLI, tedy při spouštění
skriptů z příkazové řádky.
Zanoření
Buffery je možné zanořovat, takže zatímco je jeden buffer aktivní,
dalším voláním ob_start()
se aktivuje buffer nový. Tedy ob_end_flush() a
ob_flush() neposílají obsah bufferu na výstup, ale do
nadřazeného bufferu. A teprve když žádný nadřazený není, posílá se
obsah na skutečný výstup, tj. do prohlížeče nebo terminálu.
Proto je důležité buffering ukončit, a to i v případě, že
v průběhu nastane výjimka:
ob_start();
try {
$foo->render();
} finally { // finally existuje od PHP 5.5
ob_end_clean(); // nebo ob_end_flush()
}
Velikost bufferu
Buffer může také zrychlit
generování stránky tím, že se do prohlížeče nebude odesílat
každé jednotlivé echo, ale až větší objem dat (například
4kB). Stačí na začátku skriptu zavolat:
ob_start(null, 4096);
Jakmile velikost bufferu překročí 4096 bajtů (tzv.
chunk size), automaticky se provede flush, tj. buffer
se vyprázdní a odešle ven. Téhož se dá dosáhnout i nastavením direktivy
output_buffering.
V CLI režimu se ignoruje.
Ale pozor, spuštění bufferingu bez uvedení velikosti, tedy
prostým ob_start(), způsobí, že se stránka nebude neodesílat
průběžně, ale až se vykreslí celá, takže server bude naopak působit
velmi líně!
HTTP hlavičky
Output buffering nemá žádný vliv na odesílání HTTP hlaviček, ty se
zpracovávají jinou cestou. Nicméně díky bufferingu je možné odeslat
hlavičky i poté, co se vypsal nějaký výstup, jelikož se stále drží
v bufferu. Ovšem jde o vedlejší efekt, na který neradno spoléhat,
protože není jistota, kdy výstup překročí velikost bufferu a
odešle se.
Bezpečnostní díra
Při ukončení skriptu se všechny neukončené buffery vypíší na
výstup. Což lze považovat za nepříjemnou bezpečnostní díru, pokud si
například v bufferu připravujete citlivá data, která nejsou určená pro
výstup a dojde přitom k chybě. Řešením je použít vlastní handler:
ob_start(function () { return ''; });
Handlery
Na output buffering lze navázat vlastní handler, tj. funkci, která obsah
paměti zpracuje před odesláním ven:
ob_start(
function ($buffer, $phase) { return strtoupper($buffer); }
);
echo 'Ahoj';
ob_end_flush(); // na výstup se dostane AHOJ
I funkce ob_clean() nebo ob_end_clean() vyvolají
handler, ale výstup zahodí a ven neposílají. Přičemž handler může
zjistit, která funkce je volána a reagovat na to. Používá se k tomu druhý
parametr $phase, což je bitová maska (od PHP 5.4):
PHP_OUTPUT_HANDLER_START při otevření bufferuPHP_OUTPUT_HANDLER_FINAL při ukončení bufferuPHP_OUTPUT_HANDLER_FLUSH při volání ob_flush()
(ale nikoliv ob_end_flush() nebo ob_get_flush())PHP_OUTPUT_HANDLER_CLEAN při volání ob_clean(),
ob_end_clean() a ob_get_clean()PHP_OUTPUT_HANDLER_WRITE při automatickém
flush
Fáze start, final a flush (resp. clean) mohou klidně nastat současně,
rozliší se pomocí binárního operátoru &:
if ($phase & PHP_OUTPUT_HANDLER_START) { ... }
if ($phase & PHP_OUTPUT_HANDLER_FLUSH) { ... }
elseif ($phase & PHP_OUTPUT_HANDLER_CLEAN) { ... }
if ($phase & PHP_OUTPUT_HANDLER_FINAL) { ... }
Fáze PHP_OUTPUT_HANDLER_WRITE nastává jen tehdy, pokud má
buffer velikost (chunk size) a ta byla překročena. Jedná se tedy
o zmíněný automatický flush. Jen pozor, konstanta
PHP_OUTPUT_HANDLER_WRITE má hodnotu 0, proto nelze použít
bitový test, ale:
if ($phase === PHP_OUTPUT_HANDLER_WRITE) { .... }
Handler nemusí podporovat všechny operace. Při aktivaci funkcí
ob_start() lze jako třetí parametr uvést bitovou masku
podporovaných operací:
PHP_OUTPUT_HANDLER_CLEANABLE – lze volat funkce
ob_clean() a souvisejícíPHP_OUTPUT_HANDLER_FLUSHABLE – lze volat funkci
ob_flush()PHP_OUTPUT_HANDLER_REMOVABLE – buffer lze ukončitPHP_OUTPUT_HANDLER_STDFLAGS – je kombinací všech tří
flagů, výchozí chování
Tohle se týká i bufferingu bez vlastního handleru. Například pokud chci
zachytávat výstupu do proměnné, nenastavím flag
PHP_OUTPUT_HANDLER_FLUSHABLE a buffer tak nebude možné (třeba
omylem) poslat na výstup funkcí ob_flush(). Nicméně lze tak
učinit pomocí ob_end_flush() nebo ob_get_flush(),
takže to poněkud ztrácí smysl.
Obdobně by měla absence flagu PHP_OUTPUT_HANDLER_CLEANABLE
zamezit mazání bufferu, ale opět to nefunguje.
A nakonec absence PHP_OUTPUT_HANDLER_REMOVABLE činní buffer
uživatelsky neodstranitelný, vypne se až při ukončení skriptu. Příkladem
handleru, který je vhodné takto nastavit, je ob_gzhandler,
který komprimuje výstup a tedy snižuje objem a zvyšuje rychlost datového
přenosu. Jakmile se tento buffer otevře, odešle HTTP hlavičku
Content-Encoding: gzip a veškerý další výstup musí být
komprimovaný. Odstranění bufferu by rozbilo stránku.
Správné použití je tedy:
ob_start(
'ob_gzhandler',
16000, // bez chunk size by server data neodesílal průběžně
PHP_OUTPUT_HANDLER_FLUSHABLE // ale ne removable nebo cleanable
);
Komprimaci výstupu můžete aktivovat také direktivou zlib.output_compression,
která zapne buffering s jiným handlerem (netuším, v čem konkrétně se
liší), bohužel chybí příznak, že má být neodstranitelný. Protože je
vhodné komprimovat přenos všech textových souborů, nejen v PHP
generovaných stánek, je lepší kompresi aktivovat přímo na straně HTTP
serveru.
What you can't learn from the documentation + patch for
security hole + advice on how to speed up server response.
…pokračování
PHP ssh2 thread safe binaries for Microsoft Windows:
Zmodernizoval jsem kód knihoven Dibi a Texy,
třídy přenesl do jmenných prostorů a využil syntaxe PHP 5.4. Zároveň
jsem doplnil mechanismus, aby knihovny fungovaly i s existujícím kódem,
který používá původní názvy tříd.
Výsledkem je Texy 2.8 (release notes) a Dibi
3.0 (release
notes).
Dibi mělo nést původně označení 2.4, protože krom vnitřního
refactoringu jsem nechtěl přidávat nebo měnit jakoukoliv funkčnost, jako
u Texy 2.8, ale nakonec jsem pár vychytávek přidal a výsledkem je právě
verze 3.0:
- nové výjimky
Dibi\ConstraintViolationException,
ForeignKeyConstraintViolationException,
NotNullConstraintViolationException
a UniqueConstraintViolationException
- MySQL: sloupec TIME se převádí na objekty DateInterval namísto DateTime
(BC break)
- SqlsrvDriver: doplněna podpora pro LIMIT & OFFSET
- vylepšen Dibi\Fluent při použití limit & offset
Zmizely ovladače pro SQLite 2 a MsSqlDriver, které nejsou od PHP
5.3 podporované, a MsSql2005Driver se nyní jmenuje SqlsrvDriver (funguje
i starý název). Statická třída dibi zůstává mimo jmenné
prostory. Pokud si píšete vlastní ovladač, došlo ke změně v rozhraní
u metod escape() & unescape() (viz).
Minimální požadovaná verze PHP je 5.4.4, obě knihovny jsou plně
funkční i pod PHP 7. Minifikovaná verze je ve formě archívu PHAR.
Dibi postupně pokrývám testy. Jelikož nepoužívám MS SQL Server, je
tento driver víceméně v rukou komunity. Pokud jej používáte, zkuste
prosím zjistit, proč neprocházejí testy používané
pro jiné servery a co je potřeba změnit.
Velmi pozvolna vzniká i Texy 3.0, ze kterého zmizí dnes už překonané
funkce, jako je třeba podpora jiného kódování než UTF-8, jiného formátu
než HTML5 atd.
Nová verze Nette 2.3.7 přináší spoustu
vylepšení, jedno z nich si ale rychle zamilujete. Jsou to chybové
hlášky, které se vám pokusí napovědět, pokud uděláte překlep.
Určitě jste už někdy narazili na podobnou chybu:
Chcete v šabloně vykreslit komponentu a ona prý neexistuje. Může to
mít celou řadu příčin, od nějakého opomenutí na straně presenteru, až
po chybu v šabloně. Nebo se komponenta jmenuje jinak?
Nejhorší ze všeho jsou triviální přelkepy, které nevidíte, takže
několikrát prověříte všechny možnosti a strávíte na tom dost času,
než chybu odhalíte.
Nejnovější verze Nette má ale šikovnější chybovou hlášku:
Did you mean ‚signInForm‘? Aha! Hned je jasné, že na vině byl
překlep a můžete ho rovnou opravit.
Pokud jste se někdy dlouze zasekli na velikosti písmenek, tj. že vám
{control MyComponent} hlásil chybu Component with name
‚MyComponent‘ does not exist, o to více oceníte dovětek did you
mean ‚myComponent‘?.
Pojďme k Nette\Database. Chybka v názvu databázového sloupce? Opět ji
dostanete na stříbrném podnose:
Mimochodem, stejná feature bude i v příští verzi dibi, kterou prosím
před vydáním
otestujte.
Nette napovídá překlepy v názvech funkcí, metod, proměnných atd.
Pokud vyvíjíte v IDE, neměly by se vám podobné chyby stávat, na druhou
stranu málokteré IDE dokáže plnohodnotně napovídat třeba v šablonách.
Ať už se spletete v názvu filtru nebo makra:
Případně v názvu proměnné:
Hláškou did you mean novinky zvyšující pohodlí nekončí. Nette vás
nově upozorní na celou řadu dalších, dříve špatně odhalitelných, chyb.
Jako například chybějící []
$myForm->onSuccess = [$this, 'myFormSucceeded'];
// namísto správného
$myForm->onSuccess[] = [$this, 'myFormSucceeded'];
nebo chybějící ()
{foreach $form->getErrors as $error}
// namísto správného
{foreach $form->getErrors() as $error}
či docela nebezpečné opomenutí, jelikož
$user->isLoggedIn je vždy truthy:
{if $user->isLoggedIn} ... něco tajného ... {/if}
// namísto správného
{if $user->isLoggedIn()} ... něco tajného ... {/if}
To nyní povede k varování Did you forget parentheses after
isLoggedIn?
Poznámka: pokud záměrně píšete v kódu metodu bez závorek, tj.
$cb = $obj->getItems, protože chcete využít vlastnosti
Nette\Object, která takto do $cb uloží callback na metodu
getItems, a objeví se varování, použijte prosím standardní
PHP zápis, tj. $cb = [$obj, 'getItems']. Při korektních běžných
použitích se varování nezobrazuje.
Dále Latte vás upozorní, když použijete modifikátor na místě, kde se
ignoruje, jako například:
{if $var |filter}
Did you mean „komfortněji“?
Nová verze Nette je tu od toho, aby vám usnadnila a zpříjemnila vývoj.
A jak je to napovídání boží si doopravdy uvědomíte, až to
vyzkoušíte.
Chrome 44 (beta) odesílá nově hlavičku HTTPS: 1,
která může způsobovat problémy.
Na některých hostinzích (z těch co používám třeba
WebSupport už to opravili) si pak PHP myslí, že požadavek je pod
šifrovaným spojením HTTPS. Tj. proměnná
$_SERVER['HTTPS'] === 'on'.
U aplikací v Nette, které neběží pod https, to pak způsobí
nekonečný redirect. Aplikace si prostě myslí, že k ní přistupujete přes
URL https://example.com a přesměrovává na
http://example.com.
Můžete to vyzkoušet z příkazové řádky pomocí:
curl -I --header "HTTPS: 1" http://example.com`
Že je hlavička HTTPS: 1 problematická se
už ví, takže je možné, že se změní a do Chrome nedostane.
Každopádně jako rychlý workaround, aby nedocházelo ke smyčce
přesměrování v betaverzi Chrome, je přidat na začátek bootstrap.php:
unset($_SERVER['HTTPS']);
Zároveň je dobré si uvědomit, že na některých hostinzích lze detekci
šifrovaného spojení velmi snadno ošálit.
Doplnění: Chrome 45 už hlavičku HTTPS: 1 neodesílá.
Jak jsem v projektech, které používají PHP 5.4 a
vyšší, převáděl starou syntaxi pro zápis polí array() na
novou [].
Samotný převod PHP souborů je úplně jednoduchý. Stačí použít PHP 5.4 Short Arrays Converter a
v repozitáři zavolat:
php /php54-arrays/convert.php .
Nástroj zamění syntax ve všech souborech *.php a
*.phpt v aktuálním adresáři a také ve všech
podadresářích. Změněné soubory jsem pak komitnul (příklad).
Oříšek je ale rebasování dalších větví na takto změněný
master.
Nakonec jsem na to šel přes filtry. Ale
plně zautomatizovat se mi to nepovedlo.
Nejprve je vhodné všechny větve rebasovat na master těsně před samotnou
změnou syntaxe.
Poté jsem si vytvořil filtr nazvaný phparray, který bude
on-the-fly překládat v PHP souborech [] na array()
při checkoutu a obráceně při komitování. Tedy aby slučování probíhalo
při použití staré syntaxe, ale komitnulo se s novou.
Filtr se vytvoří v souboru .git/config, v mém případě to
vypadalo takto:
[filter "phparray"]
clean = c:/php/php.exe w:/php54-arrays/convert.php
smudge = c:/php/php.exe w:/php54-arrays/convert.php -r
required
Aby se filtr při slučování používal (ale i při každém checkoutu,
cherry-picku atd), je nutné doplnit do .git/config ještě
následující:
[merge]
renormalize = true
Filtr se bude aplikovat na soubory *.php a *.phpt,
což se definuje v souboru .git/info/attributes (nepoužívejte
.gitattributes, protože jde o dočasnou záležitost a nechceme
ji komitovat):
*.php filter=phparray
*.phpt filter=phparray
Teď by ve větvi mělo fungovat git rebase master. Bez
konfliktů, které by bylo nutné ručně řešit. Jenže ouha, konflikty se mi
vytvářely (na Windows; je možné, že na Linuxu to půjde) a když jsem je
chtěl řešit v TortoiseGit, objevovala se hláška, že na souboru
.git/index.lock je zámek atd. Zkoušel jsem experimentovat
s dalšími nastaveními pro merge, ale bez výsledku.
Zkusil jsem dělat rebase ručně: což znamená nejprve větev resetnout na
master (git reset master --hard) a pak jednotlivé komity
přidávat pomocí git cherry-pick <hash>. Nedělal jsem to
z příkazové řádky, ale pomocí TortoiseGit. I nadále mi hlásil, že
některé soubory neumí automaticky sloučit a je vyžadován ruční zásah,
ale vždy stačilo soubor rozkliknout do TortoiseGitMerge a rovnou stisknout
Mark as resolved.
Bylo to otravné, ale fungovalo to a postupně jsem „rebasoval“ všechny
větve. Poté jsem filtr z .git/config a
.git/info/attributes smazal.
Proč to nešlo úplně automaticky, nemám páru, nicméně bylo snazší
hodinu klikat, než dva dny studovat Git.
