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

Improve phone handling #1433

Merged
merged 22 commits into from Dec 13, 2017
Merged

Improve phone handling #1433

merged 22 commits into from Dec 13, 2017

Conversation

akjanik
Copy link
Contributor

@akjanik akjanik commented Dec 6, 2017

I want to merge this change because...

Fixes #1375

Pull Request Checklist

  1. Privileged views and APIs are guarded by proper permission checks.
  2. All visible strings are translated with proper context.
  3. All data-formatting is locale-aware (dates, numbers, and so on).
  4. Database queries are optimized and the number of queries is constant.
  5. The changes are tested.
  6. The code is documented (docstrings, project documentation).
  7. Python code quality checks pass: pycodestyle, pydocstyle, pylint.
  8. JavaScript code quality checks pass: eslint.

@akjanik akjanik self-assigned this Dec 6, 2017
@@ -15,13 +16,18 @@ def get_address_form(data, country_code, initial=None, instance=None, **kwargs):
country_code = country_form.cleaned_data['country']
preview = country_form.cleaned_data['preview']

if data:
Copy link
Contributor Author

Choose a reason for hiding this comment

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

What I am struggling right now is to transfer user input to the form, so it's handled properly (by 'properly' I mean to glue phoneprefix and phonenumber and doing a reverse - after providing address data, user can go back and select another address - proper fields should be repopulated. It could be done with a lot of ifs (checking if instance exists, if it has phone attribute, etc), but it seems to be very non-elegant and messy solution.

Copy link
Member

Choose a reason for hiding this comment

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

You'll find it rather challenging to handle this as two separate fields. I think it would be much easier if it was a single field (as it's going to be stored as such) with a MultiWidget.

In fact there is already one provided by the library you're using.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Such a great tip, thank you, solved many issues I had!

exclude = ['phone']

phoneprefix = ChoiceField(choices=phone_prefixes)
phone = forms.CharField()
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have tried use this one:
https://github.com/stefanfoulis/django-phonenumber-field/blob/master/phonenumber_field/formfields.py
but with not much success, as it wants "correct" number (with phone country code included), while here we want to separate things.

Copy link
Member

Choose a reason for hiding this comment

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

No, we don't necessarily want to separate them as fields, we want separate widgets.

super(AddressForm, self).__init__(*args, **kwargs)
if self.instance.phone:
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Not sure why, but form does not see phone and phoneprefix provided in the way form(instance=instance, dtaa, phone=phone...), without those lines.

Copy link
Member

Choose a reason for hiding this comment

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

This looks like a workaround and not a solution.

@@ -37,6 +48,12 @@
'zip': pgettext_lazy('Address field', 'ZIP code')}


class PhonePrefixWidget(PhoneNumberPrefixWidget):
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I decided to overwrite this one as there are issues with default widget value:
stefanfoulis/django-phonenumber-field#82
Quick example: choosing "United Kingdom +44 -> continue -> select new address makes field being populated by Guernsey as it has the same phone code, but it's alphabetically before UK.

@codecov-io
Copy link

codecov-io commented Dec 11, 2017

Codecov Report

❗ No coverage uploaded for pull request base (master@acdd238). Click here to learn what that means.
The diff coverage is 97.22%.

Impacted file tree graph

@@            Coverage Diff            @@
##             master    #1433   +/-   ##
=========================================
  Coverage          ?   83.27%           
=========================================
  Files             ?      130           
  Lines             ?     5882           
  Branches          ?      678           
=========================================
  Hits              ?     4898           
  Misses            ?      821           
  Partials          ?      163
Impacted Files Coverage Δ
saleor/userprofile/i18n.py 96.74% <100%> (ø)
saleor/userprofile/validators.py 100% <100%> (ø)
saleor/userprofile/widgets.py 100% <100%> (ø)
saleor/userprofile/models.py 88.31% <100%> (ø)
saleor/userprofile/forms.py 65.62% <80%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update acdd238...caba37c. Read the comment docs.

@maarcingebala
Copy link
Member

@dominik-zeglen Address form requires a few UI improvements:

  • prefix and phone number should be placed next to each other
  • prefix and country selection have rounded corners - maybe it's a general problem with select boxes
  • prefix and phone number fields should be rendered as the last fields in the form

@dominik-zeglen dominik-zeglen self-assigned this Dec 12, 2017


PhoneNumberField.default_validators = [validate_possible_number]
PhoneNumberField.to_python = lambda self, value: value
Copy link
Member

Choose a reason for hiding this comment

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

Instead of this kind of patching, we should rather extend the original class and override the methods or fields that we want to customize. This would be also a good place to include relevant docstrings, explaining how the customization is different from the original implementation.

@@ -37,6 +50,22 @@
'zip': pgettext_lazy('Address field', 'ZIP code')}


class CustomPhonePrefix(PhonePrefixSelect):
Copy link
Member

Choose a reason for hiding this comment

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

It's a good practice to include the widget type in the class name so in this case, CustomPhonePrefixSelect would be a better name. Also, the word "custom" doesn't say much. What makes this widget custom? It would be great if we could reflect the purpose of this class in the name.

class CustomPhonePrefix(PhonePrefixSelect):

def __init__(self, initial=None):
choices = phone_prefixes
Copy link
Member

Choose a reason for hiding this comment

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

I think there's no need to assign phone_prefixes to a new variable here.

choices = phone_prefixes
if initial:
self.initial = phone_prefixes[initial]

Copy link
Member

Choose a reason for hiding this comment

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

Empty blank lines in simple functions aren't necessary, it doesn't add much to readability.

super(PhonePrefixSelect, self).__init__(choices=choices)


class PhonePrefixWidget(PhoneNumberPrefixWidget):
Copy link
Member

Choose a reason for hiding this comment

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

Missing docstring.

@maarcingebala maarcingebala merged commit d678d39 into master Dec 13, 2017
@maarcingebala maarcingebala deleted the improve_phone_handling branch December 13, 2017 13:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants