Represent hassle idea: use a class with multiple methods to cleanly split usecasesc

[laundmo]

This is just what my current ideas look like. I'm mostly putting this here because i think it'd be useful to have a discussion about the current state of things, and i think this is a solid starting point. Sadly i won't have time to work implementing anything like this, and neither do i expect anyone else to do so, but i feel it'd be a waste to not write out my thoughts.


Currently, field.represent and similar mechanisms cover a variety of usecases which overlap in currently implicit ways:
- Customizing the representation of a field globally (in their db model)
- Customizing the representation of a type in tables (Table.represent_by_type)
- Customizing the representation of a table, so that reference fields use this representation
- Customizing the representation by type globally (currently lacking)

I propose that, instead of leaving represent as a simple function, there should be Representer (or maybe Formatter? something else?) classes which can handle various cases and allow easier custom behavior through predefined options.
- fields would get a ByType representer by default, which is backed by a user-updateable mapping, analogous to Table.represent_by_type
- This mapping would have defaults for various field types like a ReferencedTable representer for reference fields which pulls in the referenced tables format
- Representers would need to handle nullable fields, either analogous to a wrapper like IS_EMPTY_OR or with an is_nullable=False parameter
- There should probably a FuncRepr class or something which can be used for backwards compat with val,row=None representers, Analogous to the OldWidgetCompat Widget in my new form widgets system). By turning Field.represent into a property, users could continue to assign a function to it directly and if it's a callable it's wrapped in FuncRepr - that way this new design ideally won't even need code changes.
- Represent classes should be designed such that they allow efficient DB querying by default - no more "individual query per row" for retrieving a field from another table. I'm imagining this would look similar to Column.required_fields, but it should allow for joins. This runs into the issue of rows being compacted by default and users being used to that, which means that it'll likely need to be done using something that lands in _extra or something.

[Massimo DiPierro]

My opinion here is that problems we have arise from the complexity of having a represent function in the DB at all. The function should never have existed and representation should only be handled by the form and/or grid.

Given that we have it, represent is thread safe and can be overwritten for each field so one can set it to what it should be before usage as a way to customize forms and grids.

I would not add additional complexity that makes it less intuitive and would require users to read the documentation.

Nothing already prevents users to create a function that takes a db and based on rules, sets the represent function for each one of its fields at any place in the code where it may be necessary.

What could be useful is to know if a field.represent was set manually or set by default. This would allow what you suggested in the other thread in order to give a better default for reference type fields.

I may work on that on the week-end.

Massimo