Bezbolestná integrace Doctrine 2 ORM do Nette – Kdyby/Doctrine

@matej21 nette/database jsem smazal. Pokud v config.neon budu mít jen obecně platné konfigurace musím vytvořit ještě něco jako config.production.neon a v boostrap ho nastavit?

Už jsem pochopil princip, díky.
podrobnější vysvětlení je zde kdyby někdo hledal

@Tomáš Votruba: no zatím nic veřejného ne, ale pracuješ s tím jako by tam translation nebyl. A automaticky ti to vytahuje ty překlady co máš nastaveno jako locale. ale asi se to dá snadno realizovat i bez rozšíření.

Ahoj, chtěl bych se zeptat, jestli existuje něco jako sandbox nebo demo aplikace Kdyby/Doctrine?
Jsem docela zmatený, snažil jsem se inspirovat v tomto tématu https://forum.nette.org/…est-practice, ale zatím bez pokroku.
Díky za odpověď

@Tomáš Votruba: ok tak se něco pokusím. Používám balíček rixiho jak už uvedl Filip. Konfigurace v neonu je jednoduchá, jako jakákoliv jiná extension:

gedmo:
	translatableLocale	: en_US
	defaultLocale		: en_US
	# Enabled extensions
	loggable		: on
	sluggable		: on
	softDeleteable	: on
	sortable		: on
	timestampable	: on
	translatable	: on
	tree			: on
	uploadable		: on
	blameable		: on

pozn: já si rixxiho balík upravil abych zapínal/vypínal konkrétní doplňky gedma

K nastavení doctrine je asi potřeba přidat ještě filtr pokud chceš využívat SoftDeletable

doctrine:
	....
	....
	filters:
		# without this softDeleteable won't work......probably
		soft-deleteable	: Gedmo\SoftDeleteable\Filter\SoftDeleteableFilter

No a pak pokud chceš dělat entity s překlady tak stačí nějak takto: https://gist.github.com/akadlec/9505625
Máš tedy dvě entity, jedna je hlavní a to co v ní chceš přeložit doplníš o anotaci @Gedmo\Translatable (popřípadě podle toho jak si připojiš namespace gedma) a druhou entitu která ti bude shromaždovat jednotlivé překlady.

když děláš save klasicky, tj. nic nepřidáš tak ti to uloží ve výchozím locale jaké máš pro gedmo nastavené (v tomto příkladu en_US)

$widget= new Entities\Widgets\Widget;
$widget->setName('my name in en');
$em->persist($widget);
$em->flush();

pokud chceš uložit v jiné jazykové mutaci tak jen si přidáš konkrétní locale dané entitě:

$widget= new Entities\Widgets\Widget;
$widget->setName('my name in de');
$widget->setLocale('de_de'); // zmena locale entity
$em->persist($widget);
$em->flush();

co se pak týká načtení překladu tak je to stejné, v základu se ti načte entita s locale co máš nastaveno, ale máš možnost si z tentity vytáhnout všechny překlady:

$translations ´$widget->getTranslations();
/* $translations contains:
Array (
    [de_de] => Array
        (
            [name] => my title in de
        )

    [en_us] => Array
        (
            [name] => my title in en
        )
)*/

Nastavení výchozího locale podle toho v jaké jazykové verzi jsou stránky přepnuty provádím zatím dost nešikovně v presenteru v metodě startup:

// Modify GEDMO listeners
$this->context->getService('gedmo.gedmo.translatable')->setTranslatableLocale("cs_CZ"); // nebo en_US atd

Já z GEDMO ještě používám blameable co loguje editora/autora entity automaticky při akci a loggable co mě verzuje vybrané entity, takže ve startupu ještě upravím tyto listenery:

// User is logged in...
if ( $this->user->isLoggedIn() ) {
	// Set user for blameable interface
	$this->context->getService('gedmo.gedmo.blameable')->setUserValue($this->user->getIdentity());
	// Set username for loggable interface
	$this->context->getService('gedmo.gedmo.loggable')->setUsername($this->user->getIdentity()->getUsername());
}

pozn: vím že je to v presenteru/startup prasárna, ale nevím jak jinak ty data do gedma předat.

A v podastě je to vše pro základní využití GEDMO extension. Ono samotná práce s entitama (vytažení, filtrování atd. je závislá na tom jak s nima pracuješ ale v podstatě pokud ti stačí tahat překlady podle aktuálního locale tak ti stačí vždy nastavovat ten listener a ten zajistí že ti z DB příjde požadovaný překlad.

Jinak GEDMO má sice asi trochu chaoticky popsanou ale snad pochipitelnou dokumentaci v repu

akadlec když tu řešíte Gedmo, jak vám funguje Gedmo\Tree, je pořád třeba upravovat zdroják gedma? Jako píšeš tady? ale mco se mi to nelíbí… + si tam vždy pro pohodlnost přepisuju na EntityDao

@akadlec: Díky tvým spiskům jsem implementoval možnost předání locale translatorem (v mém případě Kdyby\Translation). Překopal jsem rixxi extension (pull pošlu zítra).
Vše co stačí: https://gist.github.com/…ruba/9509314

Tím pádem není potřeba nic řešit v presenteru.

Pak ještě nastavit správně název služby translatoru zde (v mém případě $this->getService('translation.default')->getLocale()).

(Pozn.: Řeším pouze rozšíření translatable).

Editoval Tomáš Votruba (12. 3. 2014 19:26)

@Tomáš Votruba: zajímavý hint, díky. Já to chtěl původně taky vyřešit v extension, včetně předání těch useru pro blameable a loggable, ale narážel jsem na problémy s cirkulací. Zkusim znova nějak pořešit.

@Tomáš Votruba díky ušetřil si mi práci ;) Služba gedmo.gedmo.loggable se brala přímo z gedma, resp jeho extension. Já jsem si tu extension napsal trochu jinak než ji měl @mishak

Zdravím,

jak řešíte ukládání dat z formuláře? Já jsem to v mém UserManageru vyřešil následovně –

public function updateUser(App\Entity\User $user, $values)
	{
		foreach ($values as $name => $value)
		{
			$user->$name = $value;
		}

		$this->userDao->save($user);
	}

Má někdo lepší řešení? Nechce se mi to dělat pole po poli.

Editoval Ripper (17. 3. 2014 13:51)

A to vezmu kde?

Filip připravuje Kdyby\DoctrineForms, které by mělo tyhle věci mapovat automaticky. Jinak já osobně používám Zend\StdLib\Hydrator…

@Ripper, @Jiří Nápravník – A co požít DoctrineModule – Hydrator? :)

Editoval David Zadražil (17. 3. 2014 20:01)

Ahoj, hraju si s tímhle doplňkem.. Je super vše mi funguje až na jednu drobnost a to je cli rozhraní. Když dám v rootu projectu:

php www/index.php hodí mi to:

ERROR: the server encountered an internal error and was unable to complete your request.

Nikde jsem nenašel jak zprovoznit a používat cli rozhraní s tímto doplňkem. Prosím poraďte, díky.

Ahoj, zkus se kouknout do logs na ladenku.

@Tomáš Votruba no tipuju to na problém s tím že kde chce dostat uživatele, ten se má získat z identity, identita bere uživatele z jeho fasady a uživatelská fasada se inicializuje až po gedmo ;)

Ahoj, mohu porosit o drobné nakopnutí? Lze si nějak při použití Gedmo Tree sáhnout na childrenHierarchy(), abych nemusel vytvářet vlastní výpis stromu kategorií?

Předem díky za Vaše rady

Přesně chci docílit tohoto https://github.com/…/doc/tree.md#…

Ale ať se k tomu snažím přistoupit jakkoliv, tak stále Call to undefined method.

//EDIT: Vyřešeno vlastním vykreslením stromu v HTML

//EDIT 2:
Tak jsem zjistil, že nelze volat žadné pomocné funkce z Gedmo tree. Konkrétně mi jde o https://github.com/…/doc/tree.md#…, konkrétně funkce moveUp a moveDown. Při pokusu jí volat přes DAO mi píše Call to undefined method Kdyby\Doctrine\EntityDao::moveUp(). Pokud si tam předám EntityManager,

/**
 * Je jedno jestli předám
 * @var Kdyby\Doctrine\EntityManager
 * nebo
 * @var Doctrine\ORM\EntityManager
 */
public $em;

public function __construct(EntityManager $em)
{
	$this->em = $em
}

Tak mi to stále vyhazuje chybu Call to undefined method Kdyby\Doctrine\EntityDao::moveUp()

Pokud u DAO nebo u EntityManageru použiji ještě funkci findAll(), tak se začne tvářit, že uvedené funkce existují, ale hodí následující chybu Call to a member function moveUp() on a non-object. Má někdo nějaký nápad jak to vyřešit?

Děkuji za případné rady.

Editoval Helda (22. 3. 2014 2:58)

Ahoj, rad bych zacal pouzivat Kdyby\Doctrine, o Doctrine toho mam spoustu nacteno, par veci je mi ale nejasnych – jeste jsem ani nezacal a nez zacnu tak bych mel rad jasno.

Nekde jsem se docetl, ze lze vygenerovat entity na zaklade hotove db a tak stejne lze vygenerovat db z entit, strasne rad bych chtel videt o priklad obou vyuziti, zaroven uvest co je lepsi, zda vytvorit db a z db vygenerovat entity, nebo vytvorit entity a nechat si vygenerovat db, co je doporucovany zpusob a proc?

Jak resit, pokud jsem zvykly mit v kazde tabulce sloupce nesouci info o tom kdo kdy a jak je vlozil (ins_dt, ins_user_id, ins_process, upd_dt, upd_user_id, upd_process), lze to udelat vlozenim traity do kazde entity, ktera by obsahovala properties s prislusnymi anotacemi?

Jak se resi default hodnoty, napr. pro vyse zmineny sloupec ins_user_id, jsem v NDB resil extendovanim Nette\Database\Table\Selection, ktera byla rozsirena o Nette\Security\User, jak vyresit default hodnotu CURRENT_TIMESTAMP pro datetime/timestamp sloupce?

Snad nejsou me otazky uplne stupidni, predem dekuji za odpovedi a objasneni.

@Lexi:
generovani entit/databaze – viz http://docs.doctrine-project.org/…e/tools.html#…, s kdyby/console se ti ty commandy registrujou a budou dostupny v cli

s traitama by to melo byt OK

propojeni s User – tady casto pomuzou kdyby/events a napojeni se na nejakou z udalosti

Ahoj,

je velice omezující, že Kdyby\EventsManager neni kompatibilní s Doctrine\EventsManager – metoda getEventListeners vrací jinak indexované pole. Tudíž nefungují některé doctrine behavioral extensions.

Nedalo by se stím něco do budoucna dělat?

Omlouvam se za flame :-) Díky!

Diskriminátor může být pouze jeden sloupec, ideálně nějaký string/int. Moc nechápu jak myslíš.

V discriminitaoru si určíš čím má doctrine rozlišit jednotlivé entity.

mkoubik napsal(a):

A jak jinak než kompozicí bys to chtěl reprezentovat v php, když nemá vícenásobnou dědíčnost?

Vícenásobná dědičnost není potřeba. Vždycky chci buď rodiče nebo potomky s atributy rodiče. Jde o to, že v tom discriminátoru nejde ukázat na více entit. On je to asi můj problém vnímat to zase jako objekty a ne jako tabulky. V relační databázi není problém mít v tabulce rodičů data, která potom načtu buď z prvního nebo z druhýho potomka, ale v objektech to nejde.