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.

Reply via email to