Here is a super quick proof of concept that I put together. I just branched my fork of django and added a little to it. Here is the comparing changes page[1].
Quick summary of changes: I created a dictionary that would contain the (id: message) pairs. I also modified the CheckMessage.__init__ method so that it will attempt to find a hint message for the id that was passed to it. If no key was found then it continues as normal. This allows me to comment out the hint parameter when it is created but still be able to pass when it is run through its normal tests. [1] https://github.com/django/django/compare/master...inondle:hints On Thursday, May 19, 2016 at 10:55:15 AM UTC-7, Tim Graham wrote: > > The security checks errors are defined as module level constants to avoid > some redundancy since these can be imported in tests: > https://github.com/django/django/blob/0eac5535f7afd2295b1db978dffb97d79030807e/django/core/checks/security/base.py > . > > If you feel your approach would be an improvement, maybe you could put > together a quick proof of concept so it's a bit easier to understand? > > On Wednesday, May 18, 2016 at 11:50:47 PM UTC-4, Quentin Fulsher wrote: >> >> Hi all, >> >> Recently I was trying to fix a bug that required me to alter the hint >> message of the `fields.E306`[1] system check error[2]. The bug in question >> added a condition to a check which if failed caused the instantiation of a >> `django.core.checks.Error` object. In order to change the `Error`'s hint >> properly I would have to change the hint in 3 different places. Once where >> the `Error` was instantiated, in the documentation, and in it's tester. >> This was a rather tedious task and if done improperly can lead to differing >> error messages. Rather than just passing the hint in as an argument to the >> constructor I think it would be better if the Error object had the option >> to lookup it's error messages rather than just having them given. >> >> It wouldn't take much effort to create a dictionary of `id: message` >> pairs which `Error` objects could use to lookup their messages/hints. In >> the event that an `Error` is instantiated with no hint/message given it >> could perform a quick check to see if it is logged in the dictionary. This >> would not add any significant overhead to the process and eliminate some >> possibility of human error. >> >> This situation becomes even more tedious if you have more than one place >> where the error is instantiated or tested. This could also help with >> documentation because all of the builtin error messages would be stored in >> a central location. >> >> In any case, let me know what you guys think. I know its kind of a >> non-issue as the current system works fine. I just thought there was some >> room for improvement. Thanks! >> >> [1] https://docs.djangoproject.com/en/1.9/ref/checks/#fields >> [2] https://docs.djangoproject.com/en/1.9/topics/checks/ >> > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/307a5a2f-5494-4a4f-8b55-d1ddbec3d94f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
