Description
As someone who regularly works with Django’s Class-Based Views (CBVs), I’ve found hx_requests to be confusing because it tries to follow the CBV pattern but deviates in small but significant ways. These inconsistencies make it hard to use with existing CBV libraries and disrupt the familiar Django workflow.
Key Issues:
Object Attribute in Detail View:
In Django’s DetailView, the object is accessed with self.object, but hx_requests uses hx_object, which feels unnecessary and confusing.
Method Signatures:
Django CBVs convert kwargs into view attributes automatically, making them easy to access. hx_requests passes **kwargs directly into methods, which doesn’t align with how Django does things.
Form Handling:
Django passes the form instance to form_valid and form_invalid, which makes handling forms straightforward. hx_requests instead sets self.form instead of passing the form to the appropriate form handlers.
Model and Fields Definition for Form Views:
Django FormView allows setting model and fields in the Meta class, but hx_requests forces the creation of a custom form class, adding unnecessary steps.
Proposed Solution:
I think hx_requests classes would be much more intuitive as a view mixin. This way, we could use it with existing Django views without having to rewrite or work around the existing API. We could add custom views that inherit from Django’s generic views and include the relevant hx_request mixin to make it easier to use as an htmx view.
This approach would make hx_requests easier to work with and more consistent with Django’s CBV system.
Description
As someone who regularly works with Django’s Class-Based Views (CBVs), I’ve found hx_requests to be confusing because it tries to follow the CBV pattern but deviates in small but significant ways. These inconsistencies make it hard to use with existing CBV libraries and disrupt the familiar Django workflow.
Key Issues:
Object Attribute in Detail View:
In Django’s DetailView, the object is accessed with
self.object, buthx_requestsuseshx_object, which feels unnecessary and confusing.Method Signatures:
Django CBVs convert kwargs into view attributes automatically, making them easy to access. hx_requests passes
**kwargsdirectly into methods, which doesn’t align with how Django does things.Form Handling:
Django passes the form instance to form_valid and form_invalid, which makes handling forms straightforward.
hx_requestsinstead setsself.forminstead of passing the form to the appropriate form handlers.Model and Fields Definition for Form Views:
Django
FormViewallows setting model and fields in the Meta class, buthx_requestsforces the creation of a custom form class, adding unnecessary steps.Proposed Solution:
I think
hx_requestsclasses would be much more intuitive as a view mixin. This way, we could use it with existing Django views without having to rewrite or work around the existing API. We could add custom views that inherit from Django’s generic views and include the relevanthx_requestmixin to make it easier to use as an htmx view.This approach would make hx_requests easier to work with and more consistent with Django’s CBV system.