mesour / DataGrid

Mesour DataGrid for Nette with options like to dump tree, inline edit, export to csv, create sub grids and sub items, sort data using jQuery.ui.nestedSortable and much more

Home Page:http://grid.mesour.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

DoctrineDataSource support

juniwalk opened this issue · comments

Dobrý den,
je v plánu přidat podporu pro doctrinu?

Povedlo se mi rozjet data z doctriny prez ArrayDataSource data source ale musel jsem udělat par uprav do BaseGrid.php, bylo by dobré vytáhnout získávání názvů sloupců do IDataSource abych mohl pracovat s objektem implementujícím ArrayAccess.

Pokud by jste zvážil tuto úpravu IDataSource, mohl bych se pokusit DS pro Doctrinu napsat a poslat PR.

Dobrý den,

no ArrayDataSource má ale omezené nastavení podmínek. Nejdou zanořovat.

getColumnNames bych mohl přidat, bylo by to čistější :-)

Jinak DoctrineDataSource už vytvořila jedna firma. Sešel jsem se s nimi a
říkali, že pošlou pull request, ale už je to dost dlouho a nic, tak se jich
zeptám a když nic, tak na ně kašlu a něco dáme dohromady ;-)

M.

Dne 9. března 2015 15:27 Martin Procházka notifications@github.com
napsal(a):

Dobrý den,
je v plánu přidat podporu pro doctrinu?

Povedlo se mi rozjet data z doctriny prez ArrayDataSource data source ale
musel jsem udělat par uprav do BaseGrid.php, bylo by dobré vytáhnout
získávání názvů sloupců do IDataSource abych mohl pracovat s objektem
implementujícím ArrayAccess.

Pokud by jste zvážil tuto úpravu IDataSource, mohl bych se pokusit DS pro
Doctrinu napsat a poslat PR.


Reply to this email directly or view it on GitHub
#26.

Dobře, děkuji za rychlou odpověď a za zvážení.

@mesour Dobrý den, je nějaké info ohledně toho DataSource pro Doctrine?

Dobrý den,

koukal jsem zběžně na ten náhled a určitě by tam bylo potřeba udělat nějaké
úpravy. Nejdůležitější bude, aby to prošlo testy, které jsou zatím napsané
jenom pro DataSourcy. Tohle bylo někdy kolem toho, když jste mi psal.

Nedávno jsem se na to chtěl mrknout, ale už jsem nenašel ten váš náhled,
takže z toho zatím sešlo. Do nové desetinkové verze bych jí už chtěl dát.
Budu rád, když mi pošlete znovu ten náhled. Starý link zdá se nefunguje.

M.

Dne 19. května 2015 14:41 Martin Procházka notifications@github.com
napsal(a):

@mesour https://github.com/mesour Dobrý den, je nějaké info ohledně
toho DataSource pro Doctrine?


Reply to this email directly or view it on GitHub
#26 (comment).

To protože jsem jej smazal, bylo to velice špatně napsané. Já s Doctrine pořádně neumím, takže asi nebude nejlepší nápad, abych to implementoval já.

No koukal jsem na to a ideálně bych to asi udělal přes query builder. Já Doctrine nepoužívám na žádném projektu. Takže kdyby k tomu měl někdo nějaký komentář, tak určitě uvítám jakékoliv nápady, připomínky a kritiku :-)

@juniwalk Jak to myslíš s tím vytáhnutím získávání názvů sloupců do IDataSource? A k čemu je to důležité?

Ják jsem udělal ten DataSource, používal jsem tam přímo entity, tedy objekty ale DataGrid si s objekty nerozumí.

Pravděpodobně to není potřeba, protože bych měl vracet array z QueryBuilder-u.

Tak tohle jsem trochu nepochopil. V čem je problém s entitami tedy
objekty... Proč by si s tím Grid jako neměl rozumnět?

Ideální by samozřejmě bylo kdyby to bylo pres entity aby se to pak dalo
plně vyuzit :-) Stejně tak nette data source bude vracet ActiveRow ;-)
On Jun 5, 2015 4:17 PM, "Martin Procházka" notifications@github.com wrote:

Ják jsem udělal ten DataSource, používal jsem tam přímo entity, tedy
objekty ale DataGrid si s objekty nerozumí.

Pravděpodobně to není potřeba, protože bych měl vracet array z
QueryBuilder-u.


Reply to this email directly or view it on GitHub
#26 (comment).

Nejde to, protože by ta entita musela implementovat ArrayAccess :)

Jo takhle už to chápu. Grid s daty pracuje jako s polem. Tak se to bude muset nějak upravit a sjednotit, aby bylo možné výsledné data plně využít.

Kdyby někdo měl nápad, jak na to, tak uvítám vše :-) Mě napadlo akorát, že by všechny na fetchAll vracely pole objektů ActiveRow nebo Entit. Akorát pro ArrayDataSource by se to navíc muselo hodit do nějakého ArrayHashe, aby se to sjednotilo.

Ano, sjednocení by to chtělo. Když jsme u toho, k čemu je IDataSource::fetch() metoda? Vím co to dělá a k čemu se to používá, jen nevím proč je to vytaženo do metody zvlášť.

Používá se pouze pro zjištění názvů sloupců, pokud nenastavím žádný sloupec, tak si z fetch() vezme array_keys a udělá TextovéSloupce.

Od v2.1 by měl fetch() jít pryč a měla by ho nahradit přímo getColumnNames() nebo něco podobného.

Rozumím, u Doctriny je problém, že potřebuje mit property nastavené jako protected, aby entity fungovali jak měli a potom nejde udělat jednoduché array_keys((array) $entity);, funkce get_object_vars($object) je specifická na scope, takže by se musela volat uvnitř entity.

Jediná možnost, jak tohodle docílit bude asi reflection.

Jasně, přes reflection to nebude problém. Tuhle logiku by v sobě měl mít ideálně ten source :-)

Napadlo mě rovnou udělat dva DataSourcy, jeden pro Entitu a druhý pro QueryBuilder ;-) Využije se to?

Vzhledem k tomu, že grid by měl časem být nezávislý na Nette (pouze budou bridge pro Nette). Tak si myslím, že Doctrine DataSource bude potřeba mnohem víc než do teď ;-)

Jak je myšlen ten pro entitu? QueryBuilder je jasný, bez něj se to v podstatě neobejde.

Mimochodem, já pak zkusil začít dělat na novém DataSource využívajícím QueryBuilder, ale ještě jsem pořádně neměl čas k tomu sednout.

Mam jen toto: https://gist.github.com/juniwalk/0d1b71e35742d19afb8f

No v podstatě, když nad tím přemýšlím, tak je to blbost. Jak jsem říkal, s Doctrine nepracuji a vím jen základy. Takže byl ten můj komentář asi dost mimo :-D

No asi jinak. QueryBuilder umí nějak vracet výsledky jako pole Entit nebo nějaký ResultSet? Nebo pouze jako pole?

K tvému rozdělanému DataSourcu. Nemám čas to teď podrobněji procházet. Ale třeba pro fetchAll potřebuješ limity i whery, ale pro fetchForExport už potřebuješ jenom whery. Ty třeba v applyLimit nastavuješ limit přímo query builderu. V fetchForExport by limit byl taky, protože se může volat klidně až po tom co grid aplikuje limit. Proto mám třeba zde metodu getSelection, které řeknu, zda chci limity a whery a ona vždy udělá klon a nastaví to co potřebuji ;-)

ve fetchForExport bych udělal clon QB a vymazal z něj limity, není problém. :) QueryBuilder může vracet pole Entity nebo pole Array dat, záleží na té Hydrataci kterou tam uvidíš.

Já tam dal array, protože DataGrid teď nezvládá pracovat přímo s entitami, háže to errory.

Aha, pokud z něj lze mazat, tak je to pak vyřešené :-) Ale počítej s tím, že někde budeš chtít vymazat whery, které přidal filtr, ale budeš chtít zachovat ty, které uživatel nastavil ještě před tím, než QueryBuilder poslal DataSourcu.

Nutnost ArrayAccessu odstraním, ale kdy se k tomu dostanu vážně nechci slibovat, mám toho teď nějak moc...

Nic se neděje, též nevím, kdy se dostanu k tomu dodělat ten DataSource.

Tak jako tak to pak bude chtít nechat projít někým zkušeným, napadá mně @fprochazka, když bude tak hodný.

Jasně :-)

Myslíš nechat projít vnitřek toho sourcu? To už bychom pak nějak s někým domluvili :-)

Ano, já mám málo zkušeností s Doctrine na to, aby se to dalo považovat za stable.

Tak jsem dnes zkusil napojit ten kód co jsem posílal sem na jeden z mých projektů a byl jsem mile překvapen, že se mi povedlo to zprovoznit s pouze jedinou úpravou do dataSourcu. :D

Filtrování sice ještě nepůjde, ale to je jasný, není to ani z daleka hotové, :)

@juniwalk kdybys to otevřel jako pullrequest aby se to rozumě komentovat, tak klidně kouknu, jestli tam neuvidím nějaké problémy :)

Btw, hodnoty z Doctrine entity číst buď pomocí ClassMetadata nebo https://github.com/symfony/PropertyAccess.

@fprochazka Tak PR vytvořeno :)

EDIT: Není to ani zdaleka hotové, s QueryBuilderem se stále seznamuji, hlavně tvoření WHERE podmínek.

Ahoj, jak to vypadá s Doctrine datasource?

Zdravím, narazil jsem na menší problém přímo v DataGridu, bude to vyžadovat trochu větší úpravy.

Ahoj, nějaký pokrok? Potřebuješ s něčím pomoct?

Ahoj, bohužel nn, makám teď na obrovském projektu a tahám si práci aj domů, vůbec na tohle nemám čas.

@Daaarkling @juniwalk: Můžete se inspirovat zde:

V nové verzi jsem to rozdělil na více souborů, ale v podstatě je tam veškerá logika, která je potřeba, jenom to vykuchat a odladit :)

Ale myslím, že nyní už je lepší si počkat na stable a sáhnout rovnou verzi 3.0

DoctrineDataSource je již dostupný ve verzi 3.0, která má stable release. Tento issue už nemá moc smysl.