Add an optional context processor that injects an 'enums' dict with all our enums

[lamby]

Saves manually/tediously adding enum classes to view template context to check them. Invalid lookup values raise an error.

Signed-off-by: Chris Lamb chris@chris-lamb.co.uk

[lamby]

Big user of this. Any chance of it being merged? Open since 2016 (!)

[Swamii]

@lamby Sorry for the (very) late answer. This looks like an easy merge. If you could add tests and document it somehow (basic note in README is fine), then it's good to go.

[lamby]

I'm afraid I won't be able to find the bandwidth to add tests and docs soon; could it not be merged in the meantime? It does not affect the other code, after all.

[Swamii]

It's just that if we merge it and people start using it and after a while it breaks, then we wouldn't know.

Also, this project is barely maintained. The less code, the better in that regard 😄

[lamby]

Aw. :(

[antonagestam]

This looks like a cool feature, however I don't think it belongs in django-enumfield especially since django-enumfield now uses standard library Enums. This PR relies on users putting enum definitions in a submodule named "enums" which limits its usefulness. The fact that this feature doesn't need to rely on other features of django-enumfield or vice versa and its narrow scope makes it a better fit for being its own library in my opinion.

[lamby]

Hi Anton,

This looks like a cool feature, however I don't think it belongs in django-enumfield especially since django-enumfield now uses standard library Enums. This PR relies on users putting enum definitions in a submodule named "enums" which limits its usefulness. The fact that this feature doesn't need to rely on other features of django-enumfield or vice versa and its narrow scope makes it a better fit for being its own library in my opinion.

I get what you mean but given that a) is quite a small amount of code and thus a separate project seems a bit overkill, b) such a sub-project would require to be kept very much in-sync with this one unless I'm misunderstanding some recent code changes, and c) the whole premise is entirely optional (!), I'm not sure what you suggest is ideal. :) Best wishes,

…

-- Chris Lamb chris-lamb.co.uk

[antonagestam]

@lamby The enum classes that django-enumfield provides inherit from standard library enum, so you wouldn't at all need to stay in-sync with django-enumfield. In fact, just replacing the import with import enum should be enough to make your code independent of this library.

is quite a small amount of code and thus a separate project seems a bit overkill

I don't agree with this sentiment, I find it much healthier for projects to do one thing and to do it well. You're asking us to support your use-case which is very specific to how you are working and not necessarily related to this project. The purpose of this library is not to implement every possible use-case of enums that relates to Django. If someone puts their enums in the same module as their models, or in a module called "enumerations" this solution doesn't work, should we support those use-cases as well then?

I think this is clearly a use-case that can stand on its own legs and shouldn't be included in this project.

[jocke-l]

Actually, this kind of feature would (if slightly more generalized) fit in libraries like https://github.com/5monkeys/django-bananas if you want to avoid micro libraries. It does not need to be tightly coupled to django-enumfield.