Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

success_css_class on bootstrap_field takes no effect #302

Open
Real-Gecko opened this issue Apr 19, 2022 · 9 comments
Open

success_css_class on bootstrap_field takes no effect #302

Real-Gecko opened this issue Apr 19, 2022 · 9 comments

Comments

@Real-Gecko
Copy link

Code
image

Result
image

@vsalvino
Copy link

vsalvino commented Aug 4, 2022

I'm experiencing the same problem.

From reading the docs, it seems that success_css_class has been changed between v4 and v5. Previously, if it was empty, no class was applied. However, now it functions as "extra" CSS classes to be added on top of is-valid (which is globally enabled via server_side_validation=True)

The old behavior was much more flexible, as we usually only want the error class applied and not a success class. The success class is effectively always applied, even on empty forms when they are rendered for the first time, which looks quite odd.

@LauriKorpela
Copy link

Having the same issue.

Any workarounds known yet?

@tom-price
Copy link
Contributor

I've had a look into this and it appears the defaults for success_css_class and error_css_class are linked back to how form validation was handled in Bootstrap 3. In that case they were applied to the wrapper around the label and input and not a class on the input tag.

I've not tested this, but you should be able to override the get_server_side_validation_classes method in this way to change the classes from is-valid and is-invalid.

from django_bootstrap5.renderers import FieldRenderer


class CustomFieldRenderer(FieldRenderer):
    def get_server_side_validation_classes(self):
        """Return CSS classes for server-side validation."""
        if self.field_errors:
            return self.error_css_class
        elif self.field.form.is_bound:
            return self.success_css_class
        return ""

Also add to your settings roughly this

BOOTSTRAP5 = {
    'field_renderers': {
        'default': 'SOME_PATH.CustomFieldRenderer',
    },
}

I'm doing something similar to prevent the setting of is-valid in the first place to prevent validation successes on empty fields (and as a side affect all other fields).

@LauriKorpela
Copy link

@tom-price, Thanks! This worked out-of-the-box and I'll use it until proper fix is available.

@paduszyk
Copy link

paduszyk commented Dec 3, 2022

@tom-price Thanks a lot for a great solution!

@Real-Gecko
Copy link
Author

I've noticed that overriding success_css_class inside BOOTSTRAP5 settings dict does not work either.

@RmaxTwice
Copy link

I've had a look into this and it appears the defaults for success_css_class and error_css_class are linked back to how form validation was handled in Bootstrap 3. In that case they were applied to the wrapper around the label and input and not a class on the input tag.

I've not tested this, but you should be able to override the get_server_side_validation_classes method in this way to change the classes from is-valid and is-invalid.

from django_bootstrap5.renderers import FieldRenderer


class CustomFieldRenderer(FieldRenderer):
    def get_server_side_validation_classes(self):
        """Return CSS classes for server-side validation."""
        if self.field_errors:
            return self.error_css_class
        elif self.field.form.is_bound:
            return self.success_css_class
        return ""

Also add to your settings roughly this

BOOTSTRAP5 = {
    'field_renderers': {
        'default': 'SOME_PATH.CustomFieldRenderer',
    },
}

I'm doing something similar to prevent the setting of is-valid in the first place to prevent validation successes on empty fields (and as a side affect all other fields).

You are a savior! great workaround!

@blag
Copy link

blag commented Oct 12, 2023

@tom-price Do you mind crafting a PR for this?

@dwgreen1
Copy link

@tom-price is there any update on this issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants