FilterHelper – cesta k souboru

MW

Zdravím a prosím o radu – vysvětlení magie :)

Mám FilterHelper, který mám registrovaný v configu:

services:
	- App\Project\Latte\FiltersProvider

kde mám nějaký getFilters vracející helpery a samotný helper pak vypadá takto:

private function getIconForImageType($type)
 {
  switch ($type) {
   case 'image/jpeg' :
    $icon = "<img align='left' src='../images/icons/image.png'>";
    break;
    .............
  }
  return $icon;
 }

a teď …
když jej použiju v komponentě (přes nějakou továrnu), třeba datagrid, tak je vše v pořádku, ale když jej použiju v šabloně presenteru „jen tak“ vrátí to co má, ale ta cesta k obrázku je špatná.

Může mě prosím někdo vysvětlit, proč jsem pokaždé jinde? Přitom když dumpnu __DIR__ jsem stále v cache/latte …

Moc děkuji

jiri.pudil

Ten obrázek ale načítá až prohlížeč, takže cesta je relativní k aktuální URL.

MW

Aha, tomu bych asi rozuměl :)
Neměl by jsi radu, jak to nějak pořešit, aby to zustalo univerzalni? Tím myslím i pro Win a Linux …

Laboroval jsem s __DIR__ definovanou WWW_DIR a APP_DIR.. případně, jak se dostat k $basepath z toho helperu?

Moc díky

Editoval MW (14. 10. 2015 14:03)

jiri.pudil

No musíš ten obrázek mít v nějaké veřejně přístupné složce a dát tam cestu k němu třeba absolutně od document rootu, stejně jako kdybys to psal přímo do šablony. K basePath se dostaneš přes

/** @var Nette\Http\IRequest $httpRequest */
$httpRequest->getUrl()->getBasePath();

HTTP request si injectneš, je registrovaný jako služba.

MW

Zkouším to přes anotaci, ale asi dělám něco blbe :

/** @inject @var Nette\Http\IRequest $httpRequest */
	public $httpRequest;

	/**
	 * @param string $type
	 * @return string
	 */
	private function getIconForImageType($type)
	{

	    $basepath = $this->httpRequest->getUrl()->getBasePath();
	    .........

Call to a member function getUrl() on a non-object

Matey

@MW nezabudol si na:

use Nette;

jiri.pudil

Zkouším to přes anotaci

To funguje jenom v presenterech. Předej si to normálně přes konstruktor :)

MW

Super moc dekuji !
Jen se zeptám na malý offtopic názor.

Mám to ve třídě implementující rozhraní. Je velká prasárna mít v rozhraní konstruktor?

Díky!

norbe

K čemu by jsi ten konstruktor potřeboval? U rozhraní tě nezajímá jak daný objekt funguje, ale co umí. Mít v rozhraní konstruktor mi vůbec nedává smysl.

MW

No třeba tady, když jsem potřeboval injektnout ten httpRequest .. nebo to jde i jinak?

norbe

Ale na to to přece nepotřebuješ mít v interfacu. Představ si interface jako náplň do tiskárny, taky tě nebude zajímat, jaký stroj a materiál potřebuješ na výrobu, zajímá tě pouze aby to fungovalo s tvojí tiskárnou.

To že daná implementace má nějaké závislosti a uvede je v konstruktoru je v pořádku, ale zajímá tě to pouze v okamžiku vytváření instance a nemá to co dělat v interfacu, který pak někde jinde požaduješ.

MW

Ja chápu, ze je ten kontruktor blbost… nepatri to tam.. ale je jediny funkcni způsob ted…

Pouzivam kontretne toto .

A ja potrebuji dostat ten httpRequrest do te třídy.

At to udelam přes setXXX, injectXXX nebo přes anotaci tak to nejde..

Call to a member function getUrl() on a non-object

Jak to tam tedy správně dostat prosím?

jiri.pudil

Teď teda vůbec nechápu, o co se pokoušíš. Tam máš přece rozhraní, které ti poskytuje to rozšíření, a do kterého tudíž nezasahuješ. A mít konstruktor ve třídě implementující rozhraní je zcela standardní věc.

Editoval jiri.pudil (15. 10. 2015 10:04)

MW

@norbe psal, ze to tam v podstate nepatri. Tak patram po jiné moznosti..

Takhle pridavam do interface ještě ten konstruktor:

interface LatteFiltersProviderInterface
{
	function __contruct();

	/**
	 * @return callable[]
	 */
	function getFilters();

}

A u toho jsem se zarazil, jestli to nahodou není něco proti necemu…

Protože jinak to tam proste neumim dostat …

MW

Tak ted jsem právě zjistil, že v tom interfacu nemusi byt ten __contruct() .. ale předtím me to vyrvalo.. tak ja nevim… :)
Ale logicky tam vazne prece nemusi byt …

norbe napsal(a):

Ale na to to přece nepotřebuješ mít v interfacu. Představ si interface jako náplň do tiskárny, taky tě nebude zajímat, jaký stroj a materiál potřebuješ na výrobu, zajímá tě pouze aby to fungovalo s tvojí tiskárnou.

To že daná implementace má nějaké závislosti a uvede je v konstruktoru je v pořádku, ale zajímá tě to pouze v okamžiku vytváření instance a nemá to co dělat v interfacu, který pak někde jinde požaduješ.

Takže jsem ti tady nerozumel.. už chápu.. myslel jsem, že říkáš, ze je to blbost, tedy udělej to jinak.. ale ty jsi říkal, že tam byt nemusi :)

Editoval MW (15. 10. 2015 12:17)