I also think the grid is obsolete and its code is ugly. The concept of pagination is old. I think it is much better to have an api and a [more] button that adds item at the bottom, until a new search is done. I will post a vue.js example of that as soon as I can.
On Tuesday, 1 August 2017 12:01:37 UTC-5, villas wrote: > > Hi Richard, > > Thanks for your points of view and I find the discussion interesting. > However I'm not sure that we are on the same page: > > For me, I would defenitly avoid using DTs as I found those kind of fancy >> grid too heavy (to many plugins, to many js, flash stuff, etc.) > > > Datatables is not that heavy and, anyhow, that isn't the problem because > it performs well when loaded, which sqlform.grid does not. > > I would prefer bare html/css closer solution, like build html table >> populate it and drop css from boostrap or other CSS lib. In this regard >> SQLFORM.grid is almost perfect > > > My point is that sqlform.grid is often totally inadequate for my needs: it > doesn't paginate loaded datasets, cannot populate via ajax, and makes far > too many queries. All of which means I have to make my own solutions > (which I am not very good at). > > Don't get me wrong, I am very grateful for what web2py does for me, but > I am just talking specifically about the grid here. > > I was interested in the vue.js, but I'm not entirely sure how it solves > my problem of producing an efficient data grid listing. > > Best wishes. > > > > > On Monday, 31 July 2017 17:25:59 UTC+1, Richard wrote: >> >> Yes Villas you get good points... >> >> I think Massimo's had talked about abandonning SQLFROM.grid. I never been >> able to fully levrage it. Most of the time, I prefer handle forms myself, >> as they most of the time more complexe the what .grid() can handle. So >> there is no gain to having them to me... Tough I think we should look at >> SQLFORM.grid as a prototyping tools as CRUD was more then an end solution >> for crafting our apps. You build a prototype app fast then you rewrite it >> and use proper customized tools for the real final product... But it far >> from ideal... But I am not sure any frameworks can meet expectations of the >> broad wild audience... Some will argue that they don't want you to specify >> the grid they are going to use, other want it built in... For me, I would >> defenitly avoid using DTs as I found those kind of fancy grid too heavy (to >> many plugins, to many js, flash stuff, etc.)... I would prefer bare >> html/css closer solution, like build html table populate it and drop css >> from boostrap or other CSS lib. In this regard SQLFORM.grid is almost >> perfect, but I think it should be rewrite entirely with proper requirements >> and to me it should be strip to it main purpose GRID... Like this you don't >> have to manage complexe redirection with args and vars, etc. It should >> accept complexe query, so you are not limited to use it over as single >> table, CRUD select was good in this respect. >> >> In the future w3p >> >> I guess in the future web3py will not offer anything like SQLFORM.grid, >> just me thinking, base on what Massimo's has mention so far about web3py... >> >> I think grid stuff will have to be handle more like this : >> >> https://vuejs.org/v2/examples/grid-component.html >> >> https://www.ag-grid.com/angular-getting-started/#gsc.tab=0 >> >> >> >> On Mon, Jul 31, 2017 at 11:16 AM, villas <vill...@gmail.com> wrote: >> >>> Hi Richard / everyone >>> >>> Those are good strategies. However, I also feel that it is a pity that >>> we are having to 'roll our own' solutions because the sqlform.grid just >>> seems too slow. >>> >>> Your idea of avoiding pyDAL seems to greatly reduce queries, and so I >>> am also tempted down this road. However, again, this undermines the >>> whole point of the framework. >>> >>> We need a more performant grid as part of the framework and my >>> observations are these: >>> 1. We need two options for loading data: all at once, and server-side >>> via ajax. >>> 2. We need to fill the grid with complex queries, including proper >>> 'left join on' syntax, and in-line selects. We can then suppress all >>> those magical data 'represents' queries which are all done with additional >>> row-by-row sub-selects. On one page of my sqlform.grid views it generated >>> almost a hundred queries. I was able to replace that with a single complex >>> query. >>> 3. Ideally, we should avoid reloading the whole page when we want to >>> edit the data. For example, using modal forms. >>> >>> Maybe I'm asking far too much. However, almost every app I write uses >>> a data grid and associated create/edit forms. In simple situations I am >>> very grateful for the sqlform.grid. In many other cases though, I find >>> myself writing similar code over and over to produce a more performant >>> listing. With my ideal framework, I cannot help but feel that I should >>> have a better starting point. >>> >>> I know that I should try and bring solutions to this group rather than >>> frustrations. My suggestion is therefore: let's leverage something like >>> Datatables! >>> If you got this far, thanks for listening! >>> >>> Best regards. >>> >>> >>> -- >>> Resources: >>> - http://web2py.com >>> - http://web2py.com/book (Documentation) >>> - http://github.com/web2py/web2py (Source code) >>> - https://code.google.com/p/web2py/issues/list (Report Issues) >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "web2py-users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to web2py+un...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.