Opened 12 years ago
Closed 7 years ago
#18394 closed Cleanup/optimization (fixed)
Add warning for invalid JavaScriptCatalog 'packages'
Reported by: | James Bennett | Owned by: | nobody |
---|---|---|---|
Component: | Internationalization | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Ready for checkin | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
The javascript_catalog
i18n view's packages
argument only accepts modules which are either django.conf
or which are also in INSTALLED_APPS
. But there are two issues with this:
- The documentation for the view hides this a bit, and can create the impression that the restriction only applies to a
packages
argument passed through the URL.
- The view itself does not give you any warning if you're violating this restriction; it just silently discards anything in
packages
that doesn't meet the requirements.
At the very least, the documentation should be more up-front that this requirement always applies no matter how you're passing packages
to the view. Possibly as a bonus, the view should warn that it's discarding any packages that don't conform to the requirements, to aid in debugging.
Change History (12)
comment:1 by , 12 years ago
Component: | Documentation → Internationalization |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 9 years ago
Cc: | added |
---|---|
Description: | modified (diff) |
Claude, I know made some improvements when you created the new JavaScriptCatalog
class-based view in 1.10. Is this ticket still relevant for that view?
comment:4 by , 8 years ago
Cc: | removed |
---|---|
Summary: | Better docs, and possibly better handling, for 'packages' argument to javascript_catalog → Add warning for invalid JavaScriptCatalog 'packages' |
Type: | Bug → Cleanup/optimization |
comment:6 by , 8 years ago
Instead of a RuntimeWarning
as proposed in the PR, would it make more sense to raise a deprecation warning and eventually error out (or even error out now)? I usually favor raising an error straight away, rather than delaying that notice with a deprecation path, if it reveals a mistake a developer made (a past case was QuerySet.select_related()
validating the values it receives) but I'll defer a decision here since I'm not a JavaScriptCatalog
user.
comment:7 by , 8 years ago
Aymeric, would you like to develop about your backwards compatibility concerns?
Would erroring out be acceptable (considering a release note about that new behavior)?
comment:8 by , 7 years ago
When I made this comment five years ago, I was learning to triage tickets and clearly I didn't know James... Don't take what I wrote too seriously!
I think raising an error and documenting the change is fine, since the code isn't working as intended anyway in that case.
comment:10 by , 7 years ago
Patch needs improvement: | unset |
---|---|
Version: | 1.4 → master |
comment:11 by , 7 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
Two problems are reported in this ticket:
(a) the documentation of javascript_catalog is confusing
(b) invalid package names are silently dropped: yes, silent failure is bad and we should do something. Raising an exception would be backwards incompatible. Raising a warning could be a good compromise.
I've created #18596 to track (a). Let's focus this ticket on (b).