Subclass UnicornView?

[nerdoc]

Just a generic question before trying out too much.

I'd like to subclass UnicornView - to create another "template" for a component. Example: I'd like to create a component that has support for model editing, like a ModelView, but with Unicorn. I have a PolymorphicModel that has similar child models - a block on a website, each with slightly different additional fields.
I want to edit all those blocks in one View. Now I want to create a Unicorn component as base for all blocks to edit them.

Is it possible/useful to subclass UnicornView further? Like:

class BlockView(UnicornView):
    title = ""
    # ...

class NewsEditor(BlockView):
    news_headline = ""
    # ...

is that a bad idea?

I am thinking further, and creating a "generic" UnicornView that createst its fields and their corresponding form fields dynamically.
@adamghill Just wanted to know you opinion about that before I start something stupid that is not possible with Unicorn...

[adamghill]

Is it possible/useful to subclass UnicornView further?
I can't think of a reason why you would run into problems subclassing as much as you want. The only issue would be if you override a method that Unicorn expects to be there (same as just overriding UnicornView itself).

creating a "generic" UnicornView that createst its fields and their corresponding form fields dynamically
This would be super interesting and I think would work as long as you created the fields at the right time. Because Python is the way it is (dynamic!), as long as it looks correct to Unicorn it won't be the wiser.

I look forward to hearing how this goes. 👍

[nerdoc]

I was thinking it might make sense to have a dictionary in Meta that could be set that would {'field_name': 'unicorn_attribute'}. Something like:

class SomeFormView(UnicornFormMixin, UnicornView):
    name: str

    class Meta:
        form_attributes = { 'name': 'unicorn:model' }

Yes, I thought about tht too - the code I wrote in the PR at this place is just a stub - First I thought about a dictionary too, but then I experimented with different needs, and found out that sometimes you need to use .lazy when on the field named something_input, and then, you need a .defer when you are in a combobox.
So IMHO the best way to keep it flexible is a function like:

            field.widget.attrs.update(self.get_widget_attr(field_name, field))

That is called instead (maybe you find a better name?), and that flexibly returns the attrs, I updated the code here - this should be a bit better.

But, there also might be something that could be done in the Form itself? Maybe with widgets? It's been a while since I read through the forms code, though so I'm not sure.

Yes, the form can change the widgets' attrs too - but it makes sense to keep that in groups as well (for all BooleanFields e.g.) - this is better done in the view class.

So - you can jump in from here on - I don't have much time next week anyhow for coding I'm afraid. 😨

[nerdoc]

ATM this code is completely broken. Adam, do you have some time to discuss this a bit further? UnicornView takes self.form_class to validate the class attribute fields against. But IMHO this is a very unclean API, and does not help further with forms, because you have to add all the fields anyway to the UnicornView, and to the form. Which does not work at all when using a ModelForm - which is one of the greatest advantages of Django.
The current docs at https://www.django-unicorn.com/docs/validation/ are very confusing.

I would suggest to concentrate on having an API for Unicorn that works with any form, so ModelForm too:

# models.py
class Book(models.Model):
    title = models.CharField(max_length=100)
    publish_date = models.DateField()

# book_form.py
from django_unicorn.components import UnicornView
from django import forms
from .models import Book

class BookForm(forms.ModelForm):
    class Meta:
        model = Book
        fields = [__all__]

class BookView(UnicornView):  # or even UnicornFormView?
    book = Book.objects.none()
    form_class = BookForm

    def save():
        

<!-- book_form.html -->
{{ form }}
{# or {% crispy form % } #}
<button u:click="save()">Save</button>

This is not correct, and not working, but just a rough idea.

• get the form into the context: Easy done with get_context_data(), context["form"]=self.form_class(instance=self.book) - then the form gets correctly rendered.
• get the unicorn:model attrs into the fields: using field.widget.attrs["unicorn:model"] = "<field-name>"
• define how a save method should be called
  • normal legacy submit with preventdefault?
  • Just a custom save()?
  • form_valid() like in ModelViews?
• how does get_context_data know about the model? name it model like in ModelViews?
• standard way for validation

Please tell me what you think about that.

[iltoga]

The fact that unicorn doesn't play well with ModelForm is the main reason why I am marginally using it in my applications and I believe it would be a game changer for the project to have it integrated.
A very useful stack would be: unicorn View ('controller' style component) -> ModelForm ( field definition and validation) --> template (render with {{ form|crispy}})

[nerdoc]

I can only second that. I always have a look back at Unicorn (I moved to htmx meanwhile) just to see if there has anything changed at this topic. Forms are the spine of many applications, and to write your html form by hand is a task you never want to do again if you have ever worked with crispy. It would be super easy to tweak crispy to add the unicorn:model attribute to every form field automatically - but Unicorn has to implement the form rendering i the first place for components.
<hint>@adamghill This would be really a fast forward step for Django-Unicorn...</hint>

[nerdoc]

Any progress in ModelForms? I saw that forms support has evolved somehow, but is using ModelForms possible? In a quick test I couldn't use it properly.