Using Django's Template System for Custom Table Headers

Your approach of repurposing Django's widget system for table headers is actually quite clever. While it might seem "hacky" at first glance, you're essentially leveraging Django's template rendering capabilities for a different purpose, which is a valid approach.

Based on the Django documentation on form output styles, there are a few ways you could refine your approach:

1. Custom Template Tags

Instead of repurposing form widgets, you could create a custom template tag specifically for rendering table headers:

PYTHONCopied
# myapp/templatetags/table_tags.py
from django import template

register = template.Library()

@register.inclusion_tag('DataRepo/widgets/bstlistview_th.html')
def render_table_header(column):
    return {
        'column': {
            'name': column.name,
            'filter_control': column.filter_control,
            'sortable': column.sortable,
            'sorter': column.sorter,
            'visible': column.visible,
            'filter': column.filter,
            'FILTER_CONTROL_CHOICES': column.FILTER_CONTROL_CHOICES,
            'many_related': column.many_related,
            'strict_select': column.strict_select,
            'header': column.header,
        }
    }

Then in your template:

DJANGOCopied
{% load table_tags %}
{% render_table_header name %}
{% render_table_header animal__name %}
{% render_table_header tissue__name %}

2. Refine Your Current Approach

Your current approach using the Widget class is actually quite reasonable. To make it less "hacky," you could create a dedicated class hierarchy:

PYTHONCopied
class TableHeaderWidget:
    template_name = "DataRepo/widgets/bstlistview_th.html"
    
    def render(self, column, attrs=None):
        context = self.get_context(column, attrs)
        return self.render_template(context)
    
    def get_context(self, column, attrs=None):
        column_attrs = attrs or {}
        return {
            "column": {
                "name": column.name,
                "filter_control": column.filter_control,
                "sortable": column.sortable,
                "sorter": column.sorter,
                "visible": column_attrs.get("visible", column.visible),
                "filter": column_attrs.get("filter", column.filter),
                "FILTER_CONTROL_CHOICES": column.FILTER_CONTROL_CHOICES,
                "many_related": column.many_related,
                "strict_select": column.strict_select,
                "header": column.header,
            }
        }
    
    def render_template(self, context):
        from django.template.loader import render_to_string
        return render_to_string(self.template_name, context)

This creates a dedicated class for table header rendering without relying on Django's form widget internals.

3. Template Inheritance

Another approach is to use template inheritance with a base template for table headers:

DJANGOCopied
{# base_table_header.html #}
<th data-field="{{ column.name }}"
    data-valign="top"
    data-filter-control="{{ column.filter_control }}"
    {{ column.filter_data_attr|safe }}
    data-filter-default="{{ column.filter }}"
    data-sortable="{{ column.sortable }}"
    data-sorter="{{ column.sorter }}"
    data-visible="{{ column.visible }}">
    {{ column.header }}
</th>

Then in your view, you'd prepare each column object and pass it to the template.

Conclusion

Your current approach using Django's Widget class is actually quite reasonable and aligns with Django's philosophy of reusable components. The key improvements would be:

1. Make it more explicit that you're creating a custom rendering system rather than trying to fit into Django's form system
2. Consider creating a dedicated class hierarchy rather than extending Django's Widget class
3. Document your approach clearly for other developers

The approach you've taken allows for clean templates while maintaining flexibility, which is a good balance for complex UI components like data tables.