Re: Making Django more PaaS-friendly
Whee, this thread got big! The takeaway I'm getting here is that we should be careful about what we adopt into core and when; I'm going to take a couple days and write up some notes on what I think a good conservative approach would look like, and ask for feedback on that. (spoiler: probably the majority of it is going to be adding support for parsing database URLs in the DATABASES setting) -- 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/CAL13Cg8yQkkWQFG0zVLi%3DKwOzhEyvp%3DMc63L8jTU4cYxaOURWw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Admin Themes in 1.10
Ever since PR #5567 [1] (which is great, yay CSP) I've been concerned about the impact it will invariably have on admin themes going forward. By removing any inline JS, the various admin JS functionality is now initialized in the JS files where it is much harder to extend or change for an admin theme. None of the niceties of template blocks and extending templates exist with the JS files, the only way to extend those would be to duplicate the entire file, which is a non-starter from a maintenance perspective. This cuts off the nice options added to these JS files since themes can no longer effect these options. Possible ways to resolve this include: * Move all JS initialization code to a single file which can be overridden by an admin theme (still requires duplicating all of the initialization code) * Add an optional attribute to the relevant HTML which prevents the initialization code from running, allowing themes to manually run initialization code with custom options I'm a fan of the second option because it allows the most flexibility. An admin theme can use custom options without duplicating much code, and a custom TabularInline subclass can be created and use a custom template and JS to provide custom options specific to that inline class. I've added a patch [2] which adds this functionality to the two admin jQuery plugins which are most likely to be initialized with alternate options: actions.js and inlines.js. For the former the attribute goes on the div.actions and for the latter it goes on the div.js-inline-admin-formset. I used the attribute 'data-disable-document-ready', but the name could just as easily be 'data-disable-auto-initialize' or something shorter if there's distaste for the long names. Thoughts? I'd like to restore this ability to easily provide different options to these admin jQuery plugins before 1.10 is finalized as it will be harder to put the cat back in the bag if it ships without the ability. - David [1] https://github.com/django/django/pull/5567 [2] http://pastebin.com/wcCk8T3n -- 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/CAEXbqgwUdzG_WuTC-2h7cCuGReFY-j3GsQN%2B-RxuKBZ_pTWLWQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Help Text Per Model Field Choice
Hey all,
I think it would be a greatly useful feature to be able to set help text
for choices on a model field.
For the default Select widget this would be rendered as the title attribute
for each choice, which browsers show when you hover over a choice. This
also makes it simple to render the help text nicely using Select2, here's a
quick example JSFiddle: https://jsfiddle.net/tt1a9zk6/
Beyond Select, for rendering radio buttons it looks like title is also
shown on hover by browsers, but it's a little less intuitive because you
need to hover over the radio button, or put the title on the label instead.
In admin, adding a little '?' icon like the one for the field help text on
tabular inlines would would be a slick way to do it for radio buttons.
Since the pattern for model field choices being a tuple is pretty ingrained
and changing the plumbing to allow for an optional third value (the help
text) would require a lot of change, I opted for using a tuple subclass to
tack on the extra help text information. From the user perspective they'd
still be providing tuples for the choices, with an optional third value.
class FooBar(models.Model):
STATUS_UNKNOWN = 0
STATUS_SNAFU = 1
STATUS_FUBAR = 2
STATUSES = (
(STATUS_UNKNOWN, _("Unknown")),
(STATUS_SNAFU, _("SNAFU"), _("Situation Normal: All Fouled Up")),
(STATUS_FUBAR, _("FUBAR"), _("Fouled Up Beyond All Recognition"))
)
status = models.IntegerField(choices=STATUSES, help_text=_("What's the
current status?"))
Under the covers the tuple gets converted to an instance of the class,
which I called ChoiceTuple in my proof of concept patch (found at the end
of this message). The help text gets set as an attribute on the instance so
that it can be retrieved by aware widgets. If a widget isn't aware of the
ChoiceTuple class, the choice acts like a two value tuple like it currently
is. The only tricky bit is unwinding the choices value when it's broken
into named groups, or is a callable, the code there is iffy, but it was
just to get the proof of concept working.
The nice thing about this approach is it also works nicely with
ModelChoiceIterator, making it quick and easy to grab help text for choices
populated from models in the DB off of one of the fields. This is useful
for situations where the choices are a curated list in the database. The
proof of concept patch tries to get the help text from a field on the model
named help_text if present. That code wouldn't be included in the final
patch, it's just an example.
Thoughts? The addition of the class ChoiceTuple nicely minimizes the amount
of changes needed to plumb the change all the way from the model field to
the widget. I'm not married to the approach, I'm just looking for a clean
way to allow help texts per choice.
Proof of concept patch (based on current master):
http://pastebin.com/90g6mUQ8
- David
--
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/CAEXbqgzhMj8kASksnO9nwFqJoNeMChV0X6ACuX8_OpOoX%3D0atg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: deprecating the "escape" half of django.utils.safestring (#24046)
On 05 Mar 2016, at 17:16, Tim Graham wrote: > The behavior of escape running last no matter its position doesn't seem so > intuitive That’s putting it mildly, considering that Django explicitly makes the parallel between template filters and Unix pipes. > but it could be problematic to simply change it. A way forward could be to > deprecate the escape filter in favor of a new filter called > conditional_escape which would simply call the function of the same name. > With the new filter, template authors will get equivalent behavior to escape > as long as they put this filter last. This is a bit annoying because we won’t end up with the best name: |conditional_escape instead of just |escape. > Alternatively, we could raise a deprecation warning if the escape filter > isn't last in the list of filters and then change the behavior to use > conditional_escape() at the end of the deprecation period. This would be my inclination. > This has the potential to be less safe for users, however, as a project might > skip over the Django versions with the warnings and not realize the behavior > has changed. On the other hand, I hope few users are running with autoscape > off and writing code like the test. > Considering that: - we recommend upgrading version by version, - hitting this edge case requires some seriously contrived code, - with the new LTS scheme we designed recently, the warning will remain longer, (until the next LTS inclusive, I think?), reducing the risk to miss it, I don’t think we should let this concern stop us. -- Aymeric. -- 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/FDF1E966-1288-4B0C-83E1-859168747465%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
