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.
http://docs.amis.work
Apache License 2.0
979 stars 144 forks source link

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

Closed swelcker closed 1 year ago

swelcker commented 1 year ago

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)
amisadmin commented 1 year ago

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

swelcker commented 1 year ago

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.

amisadmin commented 1 year ago

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.