grid columns

[Massimo]

I made a change to Grid which allow to specify columns as in

Grid(columns = [db.table.id, db.table.otherfield, Column('name', lambda row: A(...))])

This way one can inject links, button, etc in any place in the grid.

I therefore thinks that the details, edit, delete buttons should be refactored and should be simply appended to self.param.columns. Instead of passing a lot of params to customize them, one would edit the properties of the column.

Thoughts?

Massimo

[Jim Steil]

I think this is good.  I just don't want to lose the functionality/syntax we already have.  I wouldn't want to be required to provide my button info to every instance.  I think you could turn off the current buttons using the create/read/edit/delete parameters and then add your own if you wanted.

With this possibility and the other about adding pandas/list/etc support, would it be easier to offer a 'new' grid and keep the old one so backwards compatibility wouldn't be necessary?  We could clean up the parameter list quite a bit that way.  Maybe implement a cleaner class/style builder similar to what you're doing with forms (use lists instead of strings).

-Jim

[Kevin Keller]

Yes, please don't abandon the current grid and start from scratch. 

I would rather have it we keep the grid as is right now and just have the pandas etc integration added even if thst means that some code is redundant or sparkling clean. 

But if it has to be the super clean way it would also rather keep the current grid as is and then introduce a second grid that offers more flexibility with pandas etc and also of course has the ability to add custom columns just as you have added it to the old grid right now. 

Maybe you can call it flexgrid etc. 

But is having 2 grids really so much better? 

If it helps to keeps thr old grid around however it's fine, I was just wondering. 

--
You received this message because you are subscribed to the Google Groups "py4web" group.
To unsubscribe from this group and stop receiving emails from it, send an email to py4web+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/py4web/7dfcca12-8316-4a36-aebe-6d9e972d7500n%40googlegroups.com.

[Jim Steil]

I really don't want 2 grids either, but adding all of this new functionality can make some other code seem like add-ons as opposed to being one cohesive design.  We've added a LOT of functionality over the past few months.  Instead of creating a 'new' grid we should probably just be focusing on documenting what we have today.

Hopefully our doc sprint will be helpful this weekend.

-Jim

[Kevin Keller]

Yes that is a great idea. 

Let's document what we have already so far and maybe over time we can refractor and clean everything up without loosing backwards compatibility.

That's the dream :).

To view this discussion on the web visit https://groups.google.com/d/msgid/py4web/2329a151-571b-4c28-9821-4417ac5d1dc7n%40googlegroups.com.

[Massimo]

I think we should have a single grid. I think we can add the desired functionality and keep is backward compatible. We should also try to keep the implementation simple. Will try.

[Kevin Keller]

For what its worth, I have tried to come up with an approach to create a flexible grid using mostly yatl. 

I would create 3 lists: 

1. List of the grid headers

2. List of the items 

3. list of the item db.ids (for the create, edit, view buttons etc.). Not implemented yet. The buttons just show as 1,2,3 etc. 

In my sample these a are 3 separate custom defined lists, but in reality you would use pydal to get the items and their ids from the db query. 

For search capabilities in the grid I would use list.js. 

no.css is also used as CSS. 

While I was at it, I was also playing around to see how yatl and pydal would play with flask as fun project, but anyway, the code 

is extremely easy to port to py4web. 

I am just sharing to see if you can use any of that logic for tne grid logic you are developing for lists and pandas etc. 

You need to create a new venv and install flask, pydal, flask-wtf, flask-table and yatl. 

Its all in the requirements.txt

And then fire it up. 

 flaskProject_grid_table_wtform.zip

--

You received this message because you are subscribed to the Google Groups "py4web" group.
To unsubscribe from this group and stop receiving emails from it, send an email to py4web+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/py4web/a4d207e5-5d57-43a7-b146-d34bc16fee91n%40googlegroups.com.

[Kevin Keller]

Also great news we are all aligned in keeping backwards compatibility for the refactor and addition of features. 

Its just I was poised to record some tutorials and write a Medium article now, especially after our document sprint. 

If we would break grid shortly after maybe some new users check out py4web it would be a bit of a shame I think. 

Thank you for your effort Massimo. This is really great.