Proposal: Unify handling of Form(db.table) and Form([db.table.field, db.table.field2])

[laundmo]

Hi Massimo and others,

Currently, the Form class seems more complex than necessary, since it contains, essentially, 2 code paths:
- When a Table object is passed
- When a list/tuple of Fields is passed

Having looked at it a bit, I think a good way to simplify this would be to convert one of them to the other. That means either of these:
- Standardise on List[Field]: When a Table object is passed, loop over all of the Fields that should be included (readable=True/writable=True) and extract them to the list of Fields.
- Standardise on Table: When a List[Field] is passed, create a clone of the Table (like with_alias does, should probably at that point move that logic from Table.with_alias to a new Table.clone) and set the readable/writable/required of all fields not in the List[Field] to False. Use this as the table. I don't have any idea how to handle custom fields with this. 

Personally, I prefer the first option, standardizing on List[Field] - its less complex and the handling of custom fields is likely going to be far easier. A variant of this idea is to convert both List[Field] and Table  to List[FormInput] or similar - a class which stores only whats needed to render and handle the Form, akin to the Column class for Grid. This could be very generic, with FormInput only defining methods for update/delete. Potentially, FormInput could also handle its own validation. This could then allow users far more flexibility for custom form inputs and their handling, such as completely custom update handlers. For delete, by default only the FormInput created from id Fields would handle delete, by deleting the corresponding row.

Does this seem like a work-able idea?

[Alan Etkin]

Hi Laundmo

I like the approach of a database-like object to be passed as parameter. That way, I think it would be easier to refactor the current implementation, which, AFAIK is based in a DAL oriented form handling

Regards

[Alan Etkin]

Moreover, in order to avoid breaking the current signature, I think that the best way would be leave the Field class list as parameter and then inside the constructor build a DAL instance to simplify the form construction and processing.

Regards

El miércoles, 15 de octubre de 2025 a la(s) 9:47:29 a.m. UTC-3, laundmo escribió:

[laundmo]

> I think that the best way would be leave the Field class list as parameter and then inside the constructor build a DAL instance to simplify the form construction and processing.

Exactly, this was part of the idea all along. The signature should be backwards compatible, but also allow the new class. This way those who want can use the new way, while projects should keep working.

[laundmo]

Though it won't build a DAL instance at all, it will be a class which stores the things needed to handle forms.