amisadmin / fastapi-amis-admin

FastAPI-Amis-Admin is a high-performance, efficient and easily extensible FastAPI admin framework. Inspired by django-admin, and has as many powerful functions as django-admin.

Home Page:http://docs.amis.work

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Sort Order of fields in Create and Update Dialog (_create_schema... are different)

swelcker opened this issue · comments

The Create Dialog uses exactly the sort order provided by the 'create_fields` list, the Update Dialog has a different sort order each time you start the ASGI instance.

Reason:
in _sqlmodel, the def _create_schema_update(self):and the def _create_schema_create(self): are very different. The createversion gives me the freedom to define which field i want to show for record creation, the update version checks against the 'readonly_fields' list, which seems to be a logical idea at first BUT takes the freedom away from me while i provide the ùpdate_fields`list.

Solution/Proposal:
Make the update function the same as create:

def _create_schema_update(self):
    if self.schema_update:
        return self.schema_update
    if not self.update_fields:
        return super(SQLModelCrud, self)._create_schema_update()
    modelfields = list(
        filter(
            None,
            [self.parser.get_modelfield(field, deepcopy=True) for field in self.update_fields],
        )
    )
    return schema_create_by_modelfield(f"{self.schema_name_prefix}Update", modelfields, set_none=True)

Hello, thank you for your suggestion, I looked for the key reason of order random is that set is used here, in the next version, it will be changed to list to solve this problem

Thx for the quick response and for planning those changes, i am stil wondering if it shouldn't treat the relationship between readonly_fileds the same in create and update. If the provided list would be exclusiv, then the developer using your library has all the freedom. However, i personally would prefer a consistent behaviour for create and update in the relationship to check or not against readonly_fields.

Maybe you want to change the primary key field.
This problem can be considered in other ways while keeping readonly_fields. A better way may be found later.
Now you can also achieve complete control by custom schema_update.