I wouldn't say nobody understands it, Elky in particular will have a good
working knowledge given he wrote the 1.9 skin. That doesn't mean there's a
set of rules it follows. We certainly don't follow any particular front end
standard such as BEM for class names. I'm pretty sure it's only a year
On 08/03/16 20:47, Marc Tamlyn wrote:
Doing something better with the admin hstore is definitely something I'd
like to see land.
1. I'd like more input on the features people feel are essential.
Something that allows you to add/change/delete keys is all you need to
start with. Features like
Doing something better with the admin hstore is definitely something I'd
like to see land.
1. I'd like more input on the features people feel are essential.
Something that allows you to add/change/delete keys is all you need to
start with. Features like soft delete can be added later.
2. Is
I wouldn't drop it if I were you. I (think) I watched you demo the hstore
admin field at melbdjango and it looked cool to me. If I used hstorefield
I'd be interested in the implementation. The dev ML isn't really indicative
of the broader django community I feel, because only a small portion of
On 08/03/16 02:43, Tim Graham wrote:
1. Merging something minimal always help to get feature requests. :-)
2. Could you be more specific about what you're looking for? All the
existing documentation for style related stuff is at
1. Merging something minimal always help to get feature requests. :-)
2. Could you be more specific about what you're looking for? All the
existing documentation for style related stuff is at
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/coding-style/.
I also
So, I've been working on https://code.djangoproject.com/ticket/25197
I have it as part of my own project, with a view to contributing to core
once it's polished.
Currently it has basic functionality - a JS widget that fires on load,
hides the textarea, and produces a table of (name, value,
