taipy
taipy copied to clipboard
Avaiga
Default behaviors of edit, add, and delete for tables
Description The goal would be to have default behaviors for add, delete, and edit features of tables to facilitate their use. This way, a user wouldn't be forced to create specific functions (on_add, on_delete, and on_edit). In most cases, these functions could manipulate the data as wanted. If the user wants a specific behavior, they could create their specific functions as it is done now.
Acceptance Criteria
- [ ] Ensure new code is unit tested, and check code coverage is at least 90%
- [ ] Propagate any change on the demos and run all of them to ensure there is no breaking change
- [ ] Ensure any change is well documented
I would like to see this feature too. I guess on_add may not have a reasonably obvious default behavior (perhaps a row with all nan?), but I think on_edit and on_delete have a pretty clear intended behavior
I am interested in it. Here is basic but fully editable table example I used. I believe it should be the default behavior, so no need to implement it all the time.
def get_table():
dic = {"key": [1,2,3], "Value":[3,4,5]}
return pd.DataFrame(dic)
table = get_table()
page_content = """
<|{table}|table|show_all|on_edit=on_edit|width=100%|>
"""
pages = {"content": page_content}
def on_edit(state, var_name, action, payload):
cp = getattr(state, var_name).copy()
cp.loc[payload["index"], payload["col"]] = payload["value"]
state.assign(var_name, cp)
gui = Gui(pages=pages)
gui.run()
Of course, this only works for pandas.DataFrame, but should not be hard to implement same default behavior for the 2 other types Taipy can handle according to the documentation.
Hello, Any news on the issue ? Is it a feature that will end up in the product sometime?
Thank you for your answer.
The documentation is great. This issue is about adding a default behavior for the edition, addition and deletion which I think we could help
Hello,
I concur with Jacta. It is not a matter of documentation but of the default table behavior.
My team is using taipy on a daily basis to quickly share data frames. It is boring to have to write the same code again and again every time we want to collectively work on a table.
As a workaround, we sometimes use the data_node widget which natively includes the edition. But this is mainly feasible when we have some scenarios. It's a bit cumbersome to configure a data node when your data does not need to be persisted nor shared by multiple users.
Almost every week, we discuss this feature internally and as a user, I like this feature. The problem that comes with it is about best practices. It could be error-prone and lead to confusion. If you, @FabienLelaquais, want to elaborate on it
I don't get why it can be error-prone. I can understand it can be difficult to define a default function for the add method. What would be the default value for each column ?
But for the two others, the edit and the delete, I believe the default behavior is obvious.
Question by @bobbyshermi
Thank you for implementing this. That's great.
A few questions, based on the example you gave:
<|{table}|table|show_all|editable|not on_add|>
By default, the table is not editable, right?
What is the not on_add property? What is its default behavior and the default values for each column?
Thanx
1/ by default the table is not editable 2/ when editable == True, you can block default behavior by overriding the on_* handlers with False in this case, the table is editable but it is not possible to add a new row
we also made the default behavior public methods of Gui, so that you can call them in your own implementation (for example, after validation) documentation to be completed: https://docs.taipy.io/en/develop/manuals/reference/taipy.gui.Gui/#taipy.gui.Gui.table_on_add
