tiny ‘n’ smart
database layer

Odkazy: dibi | API reference

Oznámení

Omlouváme se, provoz fóra byl ukončen

LeanMapper: jaké argumenty dostávají filtry

Vojtěch Dobeš
Člen | 1317
+
0
-

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

VojtaSim:

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

před 4 lety
Vojtěch Dobeš:

Cool, díky :)!

před 4 lety
Tharos
Člen | 1036
+
0
-

@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 | 1036
+
0
-

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)