Plánuje se Exploreru přidat podporu datových typů, jako to mají formuláře a latte?

Vidím, že to podobně řeší víc lidí.

Felix napsal(a):

klidne jako rozsireni do contributte/database.

Pokud to správně chápu, tak contributte/database není samostatná databázová knihovna, ale seznam knihoven nadstavujících/upravujících chování nette/database?

neznamy_uzivatel napsal(a):

Felix napsal(a):

Udelal jsem si misto active row vlastni “active row per tabulka”.

Nebyla by prosím malá ukázka jak na to? Vůbec si to nedovedu představit..
Já si primitivně posílám ActiveRow do konstruktoru objektu, kde foreachem projdu data a nasypu to do public properties, takže když potřebuju něco upravit při výpisu, tak to dělám v getteru..

Dělám to stejně. :D

Bulldog napsal(a):

No já to dělám tak, že si vytvořím třídu konkrétní entity, například User, která v konstruktoru bere ActiveRow, které může být nullable a má privátní proměnnou typu array s názvem třeba $data

Takže to není ani zapouzdřené, ani to nenapovídá atributy. K čemu je takový kontejner dobrý?

@KamilValenta

Kamil Valenta napsal(a):

Bulldog napsal(a):

No já to dělám tak, že si vytvořím třídu konkrétní entity, například User, která v konstruktoru bere ActiveRow, které může být nullable a má privátní proměnnou typu array s názvem třeba $data

Takže to není ani zapouzdřené, ani to nenapovídá atributy. K čemu je takový kontejner dobrý?

Bulldog napsal(a):

Pak tato entita zprostředkovává všechny properties, co potřebuju.

Tím je myšleno, že entita vypadá například takto:

/**
 * @property string $email
 * @property string $password
 */
class User extends Entity
{

    public function getEmail(): string
    {
        return $this->getColumn('email');
    }

    public function setEmail(string $email): void
    {
        $this->changedColumns['email'] = $email;
    }

    public function getPassword(): string
    {
        return $this->getColumn('password');
    }

    public function setPassword(string $password): void
    {
    	if (empty($password)) {
    		return;
		}
        $this->changedColumns['password'] = $password;
    }

}

a Entity.php:

/**
 * @property-read int|string|null $id       Primary key identifier. Null if key does not exists (not inserted into the database yet)
 */
abstract class Entity implements IteratorAggregate, ArrayAccess
{
    use SmartObject;

    protected array $changedColumns = [];
    protected ActiveRow|null $row = null;

    public function getIterator(): Traversable|Iterator
    {
        return new ArrayObject($this->toArray());
    }

    public function offsetExists($offset): bool
    {
        return (bool) $this->offsetGet($offset);
    }

    public function offsetGet($offset)
    {
        return ($this->$offset ?? null);
    }

    public function offsetSet($offset, $value)
    {
        $this->$offset = $value;
    }

    public function offsetUnset($offset)
    {
        unset($this->changedColumns[$offset]);
    }

    public function update(): int
    {
		// ověřování
        return (int) $this->row->update($this->changedColumns);
    }

    public function related(BaseRepository $repository): DataCollection
    {
		// ověřování
        return new Selection($this->row->related($repository::getTableName()), $repository::getEntityClass());
    }

    public function delete(): int
    {
		// ověřování
        $retVal += $this->row->delete();
		$this->changedColumns = [];
		return $this->setActiveRow(null);
    }

    public function toArray(): array
    {
        // tady trošku pracuju s reflexí, aby jsem měl v návratové hodnotě klíče podle properties, ne podle sloupců v DB
    }

    public function __toArray(): array
    {
        return $this->toArray();
    }

    public function getId(): int|string|null
    {
        return $this->getColumn('id');
    }

    public function setActiveRow(ActiveRow|null $row): void
    {
        $this->row = $row;
    }

    public function getActiveRow(): ActiveRow|null
    {
        return $this->row;
    }

    protected function getColumn(string $columnName): mixed
    {
        return $this->changedColumns[$columnName] ?? ($this->row->$columnName ?? '');
    }
}

Pro samotnou Selection to mám podobně, aby jsem forwardoval funkčnost přes PROXY, jelikož chci využívat fičury lazy načítání atp.
Takže je to zapouzdřené i napovídá.

Editoval Bulldog (12. 11. 2021 12:38)

Upravil jsem puvodni prispevek. Je to tam jako bod 4.

Nápad na použití

Třída:

/**
 * @property string $name name    		// $name je název property pro appku a name je název sloupce v DB
 * @property string $content			// pokud poslední parametr neuvedeme, tak je překlad 1:1, ale CamelCase vs snake_case
 * @property int $authorId author_id	// tady je jasně vidět překlad
 */
class Article implements ActiveRow // nebo jiný rozhraní případně dědit třídu. Důležité je, aby byla editovatelná
{ }

config:

database:
	mapping:
		article: App\Model\Entity\Article    	# formát   nazev_tabulky: trida
		user: App\Model\Entity\User
		- App\Model\Entity\Comment				# V případě, že neexistuje klíč, tak název tabulky je název entity ale v snake_case, tedy comment

Čtení:

$article = $this->db->table(Article::class)
	->where() ... 	// tak jak to známe nad klasickou Selection
	->fetch(); 		// Vrátí instanci třídy Article naplněnou daty z tabulky article

$author = $article->author; // Vrátí instanci třídy User, naplněnou daty z tabulky user
$comments = $article->rel(Comment::class); // Vrátí GrouppedSelection, která v případě fetch() bude vracet instance třídy Comment z tabulky comment

//////////////////////

$user = $this->db->table('user')->get(5); 		// Vrátí instanci třídy User
$setting = $this->db->table('setting')->get(5); // Vrátí instanci třídy ActiveRow, jelikož není v configu specifikováno mapování.

Zápis:

$this->db->insert($article); 	// provede insert dat z instance uložené v proměnné $article do databázové tabulky, kterou zjistí z configu podle $article::class
$this->db->update($article); 	// provede update...
$this->db->delete($article); 	// provede delete...
$this->db->save($article); 		// Provede insert nebo update na základě toho, jestli je v $article nastavena proměnná reprezentující PK v tabulce article

$this->db->insert($setting)		// Error, setting je instance ActiveRow a neví se, do které tabulky se má uložit
$this->db->insert([
	'name' => 'Robert',
	'surname' => 'Pěšinka',
])								// Error posíláme pole, takže zase nevíme, kam data uložit

$this->db->table('setting')->insert($setting); // OK je specifikovaná i tabulka
$this->db->table('article')->insert($article); // OK sice je specifikovaná tabulka zbytečně, ale pro zpětnou kompatibilitu. :)

$thsi->db->table(Comment::class)->insert($article); // Error snažím se něco, co patří do tabulky article vložit do tabulky comment. Díky tomu není třeba ani dělat dotaz, jelikož tato chyba se dá odchytit již v insertu.

Editoval Polki (12. 11. 2021 21:15)

Já si myslím, že mu popis odpovídá docela dobře. To, že si místo do konstruktoru udělal setter a getter pro ten ActiveRow a že se ta privátní proměnná jmenuje changedColumns místo data a je protected díky dědění základních fičur si myslím, že je jen detail. Klidně si tam ten konstruktor, který očekává ActiveRow můžeš přidat a proměnnou changedColumns přejmenovat a bude to přesně odpovídat.

A taky si myslím, že odpovídá i zbytek…

Pak tato entita zprostředkovává všechny properties, co potřebuju.

Z toho je podle mě jednoznačně jasný, že ta entita má v sobě properties, přes které se přistupuje k obsahu proměnné data, nebo toho ActiveRow, takže napovídání, integrita dat apod. je zajištěná ne?

Setter uloží novou hodnotu do $data pod klíčem z db tabulky a getter se podívá, jestli tato hodnota existuje v poli $data a pokud ano, tak ji vrátí. Pokud ne, tak se podívá jestli je nastavený ActiveRow a pokud ano, tak vrátí hodnotu z něj a pokud ne, tak vrátí null, nebo vyhodí error neinicializovaná proměnná.

Tady je to dokonce detailněji popsaný, díky čemuž už musí být tutově jasný, že ta třída vystavuje jako rozhraní gettery a settery nějakých properties a když je specifikováno, že data jsou privátní a AR se bere v konstruktoru, ale nepíše se, že by bylo zpřístupněno veřejně, tak to imho dává smysl.

No a dále moje entita User se chová jako takový osekaný PROXY nad ActiveRow, takže má třeba metody ref, related, update, delete, které jen forwarduje na ten vnitřní ActiveRow.

A tímhle dokonce říká, že se ta třída chová jako PROXY nad ActiveRow a doufám, že všichni, co se naučili s Nette umí i návrhové vzory, z čehož by taky mělo být jasný, že nejde přistupovat napřímo k ActiveRow uvnitř, takže nutně musí taky být privátní a musí se k němu (jeho hodnotám) přistupovat přes ty Gettery/Settery.

Za mě je to úplně v pohodě popis, který reflektuje zaslaný příklad.
Schválně jsem podle popisu teď dal 2 kolegům napsat výsledek a vypadal stejně jako na příkladu, jen místo getteru a setteru byl konstruktor a vnitřní proměnná changedColumns se samozřejmě jmenovala data

Editoval Polki (12. 11. 2021 21:17)

Hoši hoši. To člověk chce úplně ráno zapnou práci, kouknout se jak dopadlo vlákno na fóru a vidět tohle…
@Polki Vždyť je to jedno měl jsem za to sice, že jsem použil dost implikace ve svých výrocích, ale může se stát, že jsem to napsal špatně, nebo to někdo nevidí. Zeptat se je podle mě v pohodě. Jak se říká líná huba holý neštěstí.

@KamilValenta Ohledně toho, co jsi napsal Polkimu, tak třeba my ve firmě jedem podle toho, jak to psal on v tom příspěvku už pěkně dlouho. Jediný, proč jsme mu nedali zapravdu je, že nám přišlo zbytečný se kvůli tomu registrovat na fóru. Ostatně si můžeš na netu sám dohledat, že stored procedures vznikly jen proto, že programátoři neumí psát efektivní SQL dotazy a díky tomu potom dotazy dost zhoršovaly performance aplikace, tak experti na databáze přidali do DB systémů procedury, díky kterým oni sami mohli napsat efektivní dotazy na straně DB a programátorům zprostředkovávali jen ‚API‘ s těmito procedurami, což je podle tvého popisu v tom vlákně i tvůj případ.

Každopádně bych ocenil, kdyby jsme řešili jen to, o čem téma je. Svoje problémy si můžete říct soukromě díky. :)

Možná jo, možná ne.
Bez urážení to zní jako konstruktivní debata, ke by se mohly obě strany něco přiučit a odnést si nové poznatky.
Ve všech případech to však není debata na toto vlákno a už vůbec ne na toto fórum. Vyřešte si to osobně v soukromí. Díky.

MKI-Miro napsal(a):

Ahojte

Nasiel by sa teda nejaky konkretny/finalny/funkcny priklad ako to spravit?

vdaka

Ahoj, v podstatě vše finální od Milana Šulce. Může se lišit verzí Nette.
Já jsem to teď testoval na svém starém, ale stále udržovaném soukromém projektu.

V práci to za mě vyřešil šikovnější kolega, ale je to moloch a já jsem potřeboval vlastní ActiveRow pro každou tabulku a tam si případně doplnit nějaké pomocné metody, které mi nějakým způsobem doupraví data. A nechtěl jsem to mít stylem v každém modelu / repozitáři nad každým výběrem dat ty data procpat právě takovouhle Entitou / Přepravkou (obzvlášt když mám i dotazy co vrací jen Selection a ne rovnou ActiveRow).

Navíc je to nudné, otravné a člověk na to stejně může zapomenout.

Takže to řešení od Milana Šulce je defakto funkční s tím, že v mojí verzi Nette (2.4) je to takto:

• místo convetions, je to reflection.
• řve to vícenásobné služby Nette databa, proto je tam vyplé autowirování (autowired: false)
• v ukázce od MŠ je název třídy CustomContext, ale registruje to jako CustomExplorer (takže opravit/přepsat)
• pak to padá na 4 argumentu Contextu, jelikož je CacheStorage definováno jako privátní property, takže nutno předat ručně
• pak si naplníš pole kde tabulka ⇒ třída (já to nechci plnit ručně, ale mám to pres class_exists)

a pak skutečně můžeš na ActiveRow řádku (nyní už na tvém "Cosi"ActiveRow) volat metody z oné třídy.

<?php
foreach ($section as $row) {
	\bdump($row->getCoolName());  // metoda z NoteActiveRow
}


class Note extends ActiveRow
{

    public function getCoolName()
    {
        return $this->name . ' -> COOOOOL';
    }
}
?>

<?php

services:
	mydatabase:
		factory: App\CustomContext(@database.default.connection, @database.default.structure, @database.default.reflection)
		autowired: false

	database.default.context: App\CustomContext(@database.default.connection, @database.default.structure, @database.default.reflection)

?>

Vím, že je to staré vlákno, ale třeba se to někomu bude hodit tak jako mně.

@Klobás

já jsem potřeboval vlastní ActiveRow pro každou tabulku a tam si případně doplnit nějaké pomocné metody, které mi nějakým způsobem doupraví data.

I já jsem řešil, jako asi každý kdo používá Nette Explorer jak přidat k ActiveRow metody, které by upravovaly surová data z databázové tabulky – úpravy, které není vhodné řešit v šabloně.

Já to nakonec vyřešil koncepcí stavby šablony a modelové třídy:

modelová třída:

final class ArticleModel
{
   // .....

    public string $basePath;

    public const PhotoDir = '/photo';

    public function getSrc(ActiveRow $photo): string
    {
        return $basePath.$this::PhotoDir.'/'.$photo->filename;
    }
}

presenter:

final class ArticlePresenter extends BasePresenter
{
    public function __construct(private ArticleModel $articleModel)
    {}

    public function actionView()
    {
        //....
        $this->template->model = $this->articleModel;
    }

}

šablona latte:

{varType App\Model\ArticleModel $model}

{var  $article = $model->getOne() }
{var  $photos = $model->related('photo')->order('photo.sort')}

{foreach $photos as $photo}
    <img src="{$model->getSrc($photo)}">

{/foreach}

Tedy místo komplikovaného řešení jak doplnit do ActiveRow příslušné metody aplikuji na ActiveRow (obvykle v cyklu {foreach}) metodu modelové třídy. Tím, že do šablony nepředávám Selection v proměnné $photos, ale předávám celou modelovou třídu tak:

a) kód presenteru se zjednoduší a sjednotí
b) šablona je přehlednější, díky {varType} získáme nápovědu a časem bude jistota, že je v šabloně správná modelová třída – až se dotáhne typování šablon do konce
c) není nutné modifikovat ActiveRow samotný, což jsem pár pokusů dal, ale nedopadlo to dobře

Místo $photo->src se použije o trochu, ale ne o moc složitější zápis $model->getSrc($photo).

Editoval m.brecher (10. 3. 3:34)

@Klobás

K napovídání, varType je jen Nettí věc, nikde jinde to nefunguje, resp. funguje to jen v PHP Stormu, ten nepoužívám.

S řešením, které momentálně mám jsem maximálně spokojený, je určeno pouze pro Nette, PHPStorm a Latte.

To čemu ty říkáš model a vkládáš ho do šablon, není defakto model

Model dle definice MVC je ta část aplikace která reprezentuje business logiku. To je hodně obecná definice. V souladu s definicí MVC označuji třídy které zapouzdřují databázové tabulky suffixem Model. Ať si každý zvolí suffix jaký mu vyhovuje.

je spíš nějaká kolekce filtrů/helprů

Není, filtry a helpry mám bokem, v modelových třídách mám business logiku, příklad s getSrc() byl vyjímečný, byl to jen příklad.

Jakmile budeš mít v šabloně referenci na vazební tabulky, musíš tam navkládat další kolekce filtrů/helperů.

Vazbu na referenced table mám vyřešenou, ale ono to celé řešení je dost rozsáhlé a už OT.

NDB neumí než uplně první řešení a to je prohnat Entitou výpis v modelu

„prohnat Entitou výpis v modelu“ nevím přesně co máš na mysli?

Tvoje řešení nekritizuji, držím mu palce a jenom jsem napsal svoji zkušenost, že mě moje řešení maximálně vyhovuje.

Editoval m.brecher (10. 3. 16:47)

David Grudl napsal(a):

V říjnu

to sa uz asi nestihne ci ? :)