Oznámení
LeanMapper: jaké argumenty dostávají filtry
- Vojtěch Dobeš
- Člen | 1317
Ahoj, na různých místech jsem objevil různé informace :). Zajímalo by
mě, co kromě LeanMapper\Fluent
instanec filtry dostávají za
argumenty.
Komentáře
Záleží na tom co se nastaví při registraci filtru:
// e => entity (entita, ve které se filtr volá)
->registerFilter('sort', [@translator, 'sort'], 'e')
// ->sort(Fluent $statement, Entity $entity)
// p => property (property, kde se filtr používá)
->registerFilter('sort', [@translator, 'sort'], 'p')
// ->sort(Fluent $statement, Property $property)
// ep => entity & property
->registerFilter('sort', [@translator, 'sort'], 'ep')
// ->sort(Fluent $statement, Entity $entity, Property $property)
// ep je to samé jako pe, s tím, že se mění i pořadí argumentů
Způsob „ep“ se dá použít i při registraci v non-nette kódu, nebo
se dají použít konstanty WIRE_ENTITY
,
WIRE_PROPERTY
, WIRE_ENTITY_AND_PROPERTY
třídy Connection
Funguje to a mám to odzkoušené
Zdroj
Cool, díky :)!
před 5 lety- Tharos
- Člen | 1042
@vojtech.dobes Ahoj, mám teď trošku nabito, ale pokusím se do odjezu na dovču v sobotu na všechny Tvé podněty/otázky odepsat. :) Díky za trpělivost!
- Tharos
- Člen | 1042
Existuje několik druhů parametrů a pořadí, v jakém se filtrům předávají, se od toho typu odvíjí.
Instance Fluent
Prvním parametrem předaným filtru je zpravidla Fluent statement, který má filtr za úkol nějak upravit.
Parametry předané přes auto-wiring
Pokud je spuštěn filtr, který je zaregistrován v Connection a při jeho
registraci bylo řečeno, že se mu má také předávat „iniciující“
entita, property nebo obojí, ty následují. Tyto parametry se samozřejmě
mohou předat pouze v situacích, kdy se filtr spouští při traverzování
mezi entitami. Implicitní filtr, který se spouští z repositáře v rámci
createFluent
, pochopitelně žádný z těchto parametrů
neobdrží.
Adresované parametry
V následující ukázce: m:filter(foo,bar#true)
jsem filtru
bar předal něco, čemu říkám adresovaný parametr. Jedná se o parametr,
který ze dvou uvedených filtrů obdrží pouze filtr bar. Tyto parametry
následují za těmi předanými přes auto-wiring.
Dynamicky předané parametry
V následující ukázce:
$author->getBooks(TYPE_EBOOK, TYPE_PAPER)
jsem všem filtrům,
které jsou zaregistrované u property Author::books
dynamicky
předal dva parametry (TYPE_EBOOK, TYPE_PAPER). Ty se připojí úplně
na konec.
Košatý filtr tedy může dostat v krajním případě následující parametry:
Fluent $fluent, Entitiy $entity, Property $property, $targetedArg, $dynamicArg1, $dynamicArg2, ...
Filtry lze používat nejen pomocí m:filter
, ale i ve
vlastních přístupových metodách uvnitř entit například při volání
metody getValueByPropertyWithRelationship
. Pod touhle úděsně
pojmenovanou metodou se skrývá možnost, jak získat nějaké související
entity na základě vazby nadefinované pomocí anotace, ale za použití ad-hoc
nadefinovaných filtrů předaných jako instance Filtering
. V té
instanci se dají velejemně nadefinovat parametry, které se předávají,
protože se dá použít i use
u closure.
Dá se takhle také aplikovat něco, čemu říkám anonymní filtry:
/**
* @property int $id
* @property string $name
* @property Book[] $books m:belongsToMany(#union)
*/
class Author extends Entity
{
public function getNewestBook()
{
$books = $this->getValueByPropertyWithRelationship('books', new Filtering(function (Fluent $statement) {
$statement->orderBy('pubdate')->desc()->limit(1);
}));
return empty($books) ? null : reset($books);
}
}
Přiznám se, že osobně tohle využívám velmi často a vlastně už skoro
vůbec nevyužívám příznak m:filter
. Ten používám skutečně
jenom u filtrů, které se opakují na mnoha místech. Typicky si
v aplikacích vystačím s implicitními filtry (pro soft-deleted entity a tak
podobně) a s těmito anonymními.
Edit: Opravil jsem ukázku, měl jsem v ní pár chybek.
Editoval Tharos (27. 6. 2014 10:18)