Latte – addFilter – neni tam chyba?

pista5

Zdravim,
nainstaloval jsem si api-docu, kde je tento radek

$template->addFilter(null, 'Contributte\ApiDocu\TemplateFilters::common');

sel jsem tedy dal a dostal jsem se k Nette\Bridges\ApplicationLatte\Template.php, kde je:

	public function addFilter(?string $name, callable $callback): static
	{
		$this->latte->addFilter($name, $callback);
		return $this;
	}

a pak dal Latte\Compiler\Nodes\TemplateNode\Engine.php, kde je:

	public function addFilter(string $name, callable $callback): static
	{
		if (!preg_match('#^[a-z]\w*$#iD', $name)) {
			throw new \LogicException("Invalid filter name '$name'.");
		}

		$this->filters->add($name, $callback);
		return $this;
	}

Promenna $name najednou jiz nemuze byt NULL

m.brecher

@pista5

díky za upozornění, dle mého názoru se jedná o bug a je vhodné ho opravit.

V latte/latte 3.0.18 metoda

Nette\Bridges\ApplicationLatte\Template::addFilter(?string $name, …)

volá metodu:

Latte\Engine::addFilter(string $name, …)

ta volá preg_match(‚…‘, $name), kde druhý parametr je string

typehinty obou metod addFilter() jsou nastaveny odlišně a je potřeba je sladit (s funkcí preg_match()) – odstranit null typehint:

Nette\Bridges\ApplicationLatte\Template::addFilter(string $name, …)

PR: https://github.com/…ion/pull/334

Editoval m.brecher (12. 10. 9:57)

pista5

No nevim, zda odstranit NULL typehint, nebo naopak pridat a jen osetrit preg_match

V api-docu vidim tento radek, takze asi NULL muze nabyvat… nebo drive mohl a v nove verzi Lette jiz nemuze?

$template->addFilter(null, 'Contributte\ApiDocu\TemplateFilters::common');

Editoval pista5 (12. 10. 17:17)

Marek Bartoš

V nette/application je typ nullable, protože je kompatibilní s Latte 2 a v tom je typ nullable. A i v Latte 2 je tenhle zápis dlouho deprecated.
Řešení je používat funkci addFilterLoader nebo přidávat jednotlivé (pojmenované) filtry.

m.brecher

@MarekBartoš @pista5

V nette/application je typ nullable, protože je kompatibilní s Latte 2 a v tom je typ nullable.

Regulární výraz matchne neprázdný řetězec, který obsahuje alespoň jeden [a-z] znak, takže navrhovaná úprava v podaném PR dává z pohledu funkce smysl. Nemá cenu držet zpětnou kompatibilitu v API když tato kompatibilita umožňuje předat nevalidní hodnotu parametru což vede k vyhození výjimky. Otázkou kterou již nedokážu posoudit je, zda změna v api nezpůsobí nějaké jiné problémy.

Mě přijde správné to PR udělat – při předání null do $name to skončí výjimkou a nesprávný typehint vývojáře jenom mate – viz. toto vlákno.

Editoval m.brecher (12. 10. 11:14)