Unit conversions between model field value and form field value
Hi, I have a model with an integer field storing a duration in hours, while I want to present that to users in a form in days. (The choice of these different units is imposed by other factors not under my control.) So, when saving a form, I need to convert a value in days to hours by multiplying by 24. I've done that with a clean_() method on the form, as described at https://docs.djangoproject.com/en/2.2/ref/forms/validation/. That works fine for when saving a new model. When editing an existing model however, I need to take the value from the model stored in hours, and convert that to days for display in the edit form. I've considered various places where I could do that conversion, for instance in the edit view, or the form __init__() method, or the model field's value_from_object() method, but none of those choices seem like the obvious choice, and I can't find a recommendation for how to do this either. What would you suggest? And is the recommended approach actually documented somewhere that I've missed? Thanks, Tim -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/0d786f87-8c6e-4e0d-abc5-aaa66ab4da2a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Invalid URLs passing validation by URLValidator
On Friday, 22 June 2018 20:53:54 UTC+10, Jason wrote: > > Interesting find.. the only time I've used that kind of URL convention is > by connecting to redis with the python redis library. It also fits db url > connection strings too. > > What's the actual use case for the URL schema? > The use case is that I've extracted URLs like that from spam emails. (I work for an agency that regulates spam.) Clearly the software creating the emails had a bug that resulted in the invalid URLs, but nevertheless, I don't want the invalid URLs to break my system, so I check they're valid before further processing. > > You could also report this to the > https://groups.google.com/forum/#!forum/django-developers > <https://groups.google.com/forum/#!forum/django-developers%5C> group > which is the core framework dev group, or report it as a bug on the django > bug tracker. > Reported as a bug (with a fix): https://code.djangoproject.com/ticket/29528 Cheers, Tim Bell -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/3da47adf-e80f-4ddf-9335-c275b0724ed2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Invalid URLs passing validation by URLValidator
Just picking up on a few points... On Friday, 22 June 2018 21:51:01 UTC+10, Melvyn Sopacua wrote: > > > However, officially, HTTP urls do not allow for username and password as > outlined in section 3.3: > > > > An HTTP URL takes the form: > > > http://:/? > > > where and are as described in Section 3.1. If : > > is omitted, the port defaults to 80. No user name or password is > > allowed. > > Except Django already decided they would accept them: https://code.djangoproject.com/ticket/20003 > So then, the parsing becomes: > > scheme = http > > host = foo > > path = /b...@example.com/ > But "foo" is not a valid host, as it's not fully-qualified. (That's how the validator treats it, anyway.) That said - Django still validates the ftp variant as being correct, so the > bug is still there and nice catch! > > I've filed a bug (and created a pull request): https://code.djangoproject.com/ticket/29528 Cheers, Tim Bell -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/ab468d8b-e389-42d6-a5fb-b72e6400c200%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Invalid URLs passing validation by URLValidator
Hi, I've come across some strings which I think aren't valid URLs that nevertheless pass validation by django.core.validators.URLValidator in Django 2.0.6 and 1.11.13. I know URL validation is very tricky, but these seemed to me that they should obviously fail. http://#FOO#/b...@example.com I believe that this is passing validation because "#FOO#/bar" is being treated as a username, with "example.com" as the hostname. However, "#FOO#/bar" shouldn't be valid as a username because the "#" and "/" characters aren't percent-encoded. http://FOO/b...@example.com Similarly, I think this passes validation not because "FOO" is being treated as a valid hostname, but because "FOO/bar" is considered a username, even though "/" isn't percent-encoded. Should this be considered a bug? (Sure, it's pretty obscure, but this has actually come up in my particular use case.) Thanks, Tim Bell -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/1166dac3-8c2b-4191-8130-5d9c146e4390%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.