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

refactor: display values of fields in display view #507

Closed
wants to merge 1 commit into from

Conversation

koeaw
Copy link
Contributor

@koeaw koeaw commented Dec 15, 2023

  • use _get_FIELD_display() to set field values to fix display values of choices using enumeration types (uses choices labels over values)
  • simplify check for exclude_fields by incorporating it into existing function call

Closes: #506

- use _get_FIELD_display() to set field values to fix display values
  of choices using enumeration types (uses choices labels over values)
- simplify check for exclude_fields by moving it into existing function call

Closes: #506
@koeaw koeaw force-pushed the kk/fix/choices_labels branch from edc6258 to 70fe9fe Compare December 15, 2023 16:49
@koeaw koeaw requested a review from b1rger December 15, 2023 17:05
@koeaw
Copy link
Contributor Author

koeaw commented Dec 15, 2023

This basically only minimally changes what's already there, not sure if it'd be preferable to get rid of the current solution altogether.

This could also possibly be refactored further to simplify that earlier exclude_fields calculation.

@koeaw koeaw marked this pull request as ready for review December 15, 2023 17:13
Copy link
Contributor

@b1rger b1rger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! I did not know about _get_FIELD_display, that makes more sense than using the form field value, which model_to_dict provides. I'm a little hesitant, because its a private method, but I'm ok with that for now. That refactoring makes using model_to_dict in fact a bit useless and it might make sense to move that whole block to a templatetag, but lets just merge it for now to fix that bug and revisit the rest later

@koeaw
Copy link
Contributor Author

koeaw commented Dec 18, 2023

It took me a while to find out about _get_FIELD_display() myself while frustratingly looking for a more generic solution to get_FOO_display().

I share your reservation about it being a private method, but old Django tickets I've dug up suggest there are no plans from the Django team to make functionality like this available in other ways, so... yah.


Rest of the comment moved to #506 (comment)

@koeaw
Copy link
Contributor Author

koeaw commented Dec 18, 2023

(comment moved to #506 (comment))

@koeaw
Copy link
Contributor Author

koeaw commented Dec 18, 2023

Maybe I should move my comments out of this PR and into the linked issue.

@koeaw
Copy link
Contributor Author

koeaw commented Feb 8, 2024

Oups, just found this still-open PR...

@koeaw koeaw self-assigned this Feb 8, 2024
@b1rger
Copy link
Contributor

b1rger commented Feb 8, 2024

I'm not sure it makes sens to invest time in this - there is a WIP branch to refactor apis_entities to use the new generic app - if everything goes to plan, the whole detail_generic.py will be replaced

@koeaw
Copy link
Contributor Author

koeaw commented Mar 12, 2024

I'm not sure it makes sens to invest time in this - there is a WIP branch to refactor apis_entities to use the new generic app - if everything goes to plan, the whole detail_generic.py will be replaced

True, true, it doesn't make sense to pursue this particular PR further -> closing.

@koeaw koeaw closed this Mar 12, 2024
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

Successfully merging this pull request may close these issues.

Choices with enum types don't use labels but values in (some) templates
2 participants