Generovanie formularov z DB

nie, tak napriklad nam v db tabulku osoba, ktora ma urcite atributy a potrebujem nato vytvorit form…

Pavel Kravčík napsal(a):

V nové verzi umí také generovat kód pro formuláře. Ale jen část v createComponent bez validátorů.

http://imgur.com/a/wr54L

Zkoušel jsem nainstalovat verzi 4.3.0 a nenašel to tam, mohl bych poprosit o link?

EDIT: Už to vidím, dg/adminer-custom je ten správný adminer s nette forms exportem

Editoval Ravenss (11. 4. 2017 13:38)

Šaman napsal(a):

CZechBoY napsal(a):

@cujan a jak by ten generátor měl vědět co za políčka tam má dát a co vše má jít editovat, jaký vazby atd? Pro jednoduchou editaci databázi můžeš použít Adminer Editor.

Políčka tam má dát pro každý sloupec jedno. Typ taky zjistí z db. Výsledkem je hrubá kostra, ale když entita obsahuje velké množství statických údajů, tak to ušetří práci.

Pokud vím, tak takový jednoduchý generátor je v Doctrine a jde použít i pro některé podobné ORMy.
(Aha, tam to ale nedělá z databáze, ale z definicce entity. A jiný genrátor naopak umí vygenerovat SQL schema pro tu entitu.)

a oplati sa aj namale projekty pustat do doctrine?

Jako vždy doporučím YetORM s Ublaboo. Trochu jsme si přiohnuli řešení a vytvořit CRUD s gridem, který ukládá do DB je otázka hodinky a ještě to hezky vypadá. :) A mohlo by to být rychlejší nebýt manuálního renderování formulářů.

Ale v podstatě je to použitelné jen u nás. Ten čas, který jsme do toho investovali, abychom nějaký v budoucnu ušetřili (intranet je plný tabulek a formulářů) se nám však několikanásobně vrací.

Pointa byla, že i na malé řešení se může použít třeba Doctrina, pokud to máš pěkně připravené a rozumíš tomu. V bývalé firmě se dokonce administrace generovala dle zadaných entit v yaml. Ale to si pamatuji jen matně, jak to bylo. Už to nějaký pátek bude.

Editoval Pavel Kravčík (12. 4. 2017 12:41)

@akadlec Začnu obšírněji.

Popišme si situaci, kterou je potřeba řešit: model v databázi a postup: formulář → databáze, databáze → vypsat data.
Pokud je situace jiná, bude jiná i odpověď.

Doctrine se skládá z kotel částí, to jsem si neuvědomil.

Pro tento typ problému můžu použít vícero databázových vrstev, jednou z nich je Doctrine DBAL. Proč ne. Pokud není moc složitá na použití, moc pomalá, a je to infrastruktura, kterou v projektu snesu, ok, použijme Doctrine DBAL.

Můj původní příspěvek narážel na použití Doctrine ORM, to jsem nezmínil. Pro tento typ problému je ORM naprosto zbytečná komplikace. Model máme v databázi, ale abychom mohli použít objektově-relační mapování, musíme mít druhý model – objektový. Takže jsme si zcela uměle přidali další reprezentaci modelu.
Další problém je údržba – o objektový model se budeme muset starat.
Další problém je výkon – je mapování objektů na relace jednoduchý problém? Nikoliv, takže nás bude ORM krásně brzdit.
Benefit ORM? Žádný. Protože nemodelujeme objektově, ale relačně.

Je úplně zbytečné komplikovat situaci s doctrinou pokud se jedná jen o přelití dat z DB do šablony :D navíc nevidím výhodu v problematice, kterou tohle téma začlo … asi jako jít s dělem na komára. Problém je asi jen v tom dokola psát komponenty pro formy … nicméně řešit v tom ještě přehazování dat přes doctrinu mi přijde úplně zbytečné.

@SvaťaŠimara takze misto toho, abych pouzil ORM, ktery se mi postara o mapovani, relace atd., tak budu delat vlastni „orm“?

Začněte psát blog Sváťo. Doména je koukám volná. https://hosting.wedos.com/…n-check.html?…

Mno nevím, form nemám vždy jen o jedné tabulce ale i o X závislých joinech, doctrine za mě tyto joiny vyřeší, dostanu z něj zpět objekt který potřebuji včetně všech „form kontejnerů“ a pak jednoduše mapperem si form naplním. Negeneruju form automaticky na základě struktury dat, protože občas po něm chci specifické věci a těch pár řádek definic mě nezabije. Nicméně přelití dat z DB před Doctrine do formu a z5 a pak z DB přes Doctrine do gridu je poměrně jednoduché. Navíc díky tomu že entity mají nějakou definovanou formu, tak nemusím mít zdroj dat DB ale klidně filesystém a grid nepozná co jsem mu předal.