Add support for fields with subwidgets (BoundWidget)

[johncronan]

It's quite a simple addition.

There is one disadvantage to this approach, which is that it assumes that the subfield will only be rendered with_label=False. I did this because it's a simple matter to attach a label using the template, and I'm not sure, but I think the implementation would otherwise have to be more complex.

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 10 lines in your changes missing coverage. Please review.

Project coverage is 83.78%. Comparing base (5599143) to head (8ba9730).
Report is 4 commits behind head on master.

Files with missing lines	Patch %	Lines
widget_tweaks/templatetags/widget_tweaks.py	0.00%	9 Missing and 1 partial ⚠️

❗ There is a different number of reports uploaded between BASE (5599143) and HEAD (8ba9730). Click for more details.

HEAD has 27 uploads less than BASE

Flag	BASE (5599143)	HEAD (8ba9730)
	52	25

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #122      +/-   ##
==========================================
- Coverage   89.85%   83.78%   -6.08%     
==========================================
  Files           2        2              
  Lines         138      148      +10     
  Branches       48       49       +1     
==========================================
  Hits          124      124              
- Misses          9       18       +9     
- Partials        5        6       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[zodman]

here we are missing:

1. Documentation
2. Unittest

without that, we cannot accept or discuss your PR ..

I will put your PR in the draft ... because is incomplete

[johncronan]

I'll get to it someday!

[alfonsrv]

Would love to see this merged. Quite an incomplete library without it.

[georgek]

Any chance of tests and documentation for this?

[aleksihakli]

If someone has the opportunity to add the tests & docs for it I'd be happy to bake a new release :) Should be quite feasible to implement.

[johncronan]

I hoped to make some progress on it today, but I don't have a system that can run the tests, to begin with. It wants four different python versions installed! The linux hosts I have access to don't match up. And when running locally on MacOS, other things are messed up with tox, for me. Something about BuildEditableNotSupportedError, and also a bunch of package errors regarding the tox environment setup and Django versions not being compatible with Python versions. Ugh, I get enough of this stuff trying to deal with containerization for my app.

Long story short, somebody else is going to have to do this part.

As for documentation, can you tell us what updates to the README are necessary? Beyond removing the part where it says this isn't supported.

[georgek]

Hi @johncronan thanks for having a look at this again. I find the easiest way to have multiple versions of Python available on most systems is to use pyenv: https://github.com/pyenv/pyenv

You could also use binary repos like "deadsnakes" for Ubuntu that have all the current versions available.

After that you'll be able to install the versions required for testing and tox will take care of the rest. For tox itself I install it as a global tool using pipx but you can always install it inside a virtualenv if you want.

For the documentation I'd say add a couple of examples of the new usage that is available, specifically how/if it differs from "regular" form fields. This could also help someone else to write the tests.

[johncronan]

I got something started for the documentation part.

I don't remember what I was talking about, with the with_label=False thing. There should be some note about that.

I recall that Django fields can have automatically-rendered labels, but in this context the "label" is the choice value, usually? All I really know is that, in order to get it to work, I had to do the labels part in my template code, not in Django.

[aleksihakli]

Looks good. Could we have a unit test that demonstrates the behaviour and covers the code path for the new logic? After that I think this would be ready for upstreaming?

If you implement the unit test you don't have to run it with every Python version locally, one is enough. GitHub Actions will handle the full test matrix in CI :)

[alfonsrv]

Please merge. This functionality is long overdue.

[aleksihakli]

@alfonsrv if you fork and add unit tests for the feature then we can merge, at the current moment the feature is untested.