Re: Django default input validation accepts special caracters
> Backwards compatibility is the bigger concern here. I understand that, I believe there is always a way, because prior to 2008 when I switched to Django, I was commiter on a PHP library group that not only had the best code quality: but COMMITS to maintaining BC. Code that I have made prior to 2008 still works today with the last releases. Since then, I've been upgrading a lot of code, maintaining django packages with millions of downloads from Python 2 and Django 1 to nowadays and contribute the same to many libraries as much as I can, often proud to be the first to offer a patch, as such, I most definitely understand the cost of not maintaining BC. I love BC, I think maintaining it is a challenge that always deserves as much time and effort as possible. But, since Django broke BC for on_delete, which I accept to be "for the greater good", I just wanted to at least discuss how this could be done to improve the results of security audits for all Django users, and not just me and my 20 yrs of pro xp, I'm too 1337 to need it for myself, I thought it was worth discussing about it for others. On a more emotional note, which I hope you will understand as **I've just been fired by one of the developers that I have admired most for more than a decade now, just for following OWASP recommandations**, no matter that I'm mentionning that my competitors do at least the same: THANK YOU Rene, For not completely discarding everything I offer for debate, it's been a while since django-developers make me feel like "just a craze", despite that I do actually maintain both governmental and financial websites in production which I develop and manage tech teams of, as part of different customers, and a lot of the money I make I actually throw away to other developers on R and other cool stuff which I wish I could be working on full time. To others: keep up the great work, Django is a fantastic project and I love it, last year I took a few months to assess all other more recent languages and frameworks I could find, with the purpose of deciding what my stack would be for the next decade and guess what: it's still Django ;) <3 -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/TrcSP2vCQe456Y-cKDkXK0HQMTiB-EsVd9ctmfkG5ZPDdqznDehSt8m-wjt6mHo51mAjoAk_9Kg5RcJrKDjBAqywkOpcfPDZ5aNFgtpsnKg%3D%40protonmail.com.
Re: Django default input validation accepts special caracters
> This may be true - not all people have first_name & last_name or want to use > them online. But it's also convenient to be able to call a person by their > first name, and also allow them to use their full name on the website. I completely agree with you, for example on dating sites like speedy or things like that. But when you are making a governmental website for example: you need actual identity. Same goes when you're manipulating money: most countries require you to partake in the fight against money laundering and they will not allow you to take/pay people without a valid identity (KYC/KYB). If you want to access a governmental or banking service online with a fake identity or forged documents you might just end up in jail. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/Q-dp6hMqMJx8yM0IrpnkIvOwpEetC2GJ_gxbGPgH77e9X4-sFQSerBIucvObkh61PEah37kpqZGI0soiurj9IpLKflLdaCX_mzdxspDgmWg%3D%40protonmail.com.
Re: Django default input validation accepts special caracters
Opened an issue on the OWASP project, reporting the reasoning of the consensus made on this mailing list as best as I could: https://github.com/OWASP/CheatSheetSeries/issues/472 Please feel free to comment or request changes on the issue. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/dEwdPhKAegZD-Mp640uZ_nXcyYFvvFRyJeTs5iO1TBZaPgnvv6B24ANMYf9Z7kOTRNb69BtcbZpoJ0gNGVV6vSAHXeMGQgxCz_Hv_V6V0t4%3D%40protonmail.com.
Re: Django default input validation accepts special caracters
> Input validation is performed to ensure only properly formed data is entering > the workflow in an information system, preventing malformed data from > persisting in the database and triggering malfunction of various downstream > components. Input validation should happen as early as possible in the data > flow, preferably as soon as the data is received from the external party. > > Data from all potentially untrusted sources should be subject to input > validation, including not only Internet-facing web clients but also backend > feeds over extranets, from [suppliers, partners, vendors or > regulators](https://badcyber.com/several-polish-banks-hacked-information-stolen-by-unknown-attackers/), > each of which may be compromised on their own and start sending malformed > data. > > Input Validation should not be used as the primary method of preventing > [XSS](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html), > [SQL > Injection](https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html) > and other attacks which are covered in respective [cheat > sheets](https://cheatsheetseries.owasp.org/) but can significantly contribute > to reducing their impact if implemented properly. https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/UGSjWB0yN5mSHouGwK5tTmvXmJ0kuJmESgGaRdTh8Q4MKH4lvv6US_mn0t_rTdMV6U8ehA7yyeGDEdYieUPvnO3qCNDBY7u3JXVCOcQ3W6k%3D%40protonmail.com.
Re: Django default input validation accepts special caracters
And I'm sorry if I offended Mister alert("pwnd") :)
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/pgzhWU0l240Rjq8dO-yUh0TVOMNTGqXfoQi8-cU1XIJ6r3bhOMmnQ6SWXS6EmErgpNtQ0HIH4Q0TBF_IY-MKIohSQnyte_QiUym_m99xa_U%3D%40protonmail.com.
Re: Django default input validation accepts special caracters
Thanks for the comment Florian, it's just basic hygiene really, don't leave open ports you don't need, never trust user inputs for characters they don't need, and so on. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0neKwVz0CQQwuCPoAPpu_FszKel8xGFohA1OF1mtwxeGsxI6_aYyuZ9P7qOqFnkHSOkD3Vaf8yHdAAZQ-kRyJ8-A8jwiNyPIeb8GaCtib0g%3D%40protonmail.com.
Re: Django default input validation accepts special caracters
Well, at least in my country there's a law that tells what characters are allowed in names, anyway, a single name field would be cool but off topic here: "first name" was used here as an example to illustrate that Django projects are audited as insecure because there is no input validation at all by default. For example, django.core.validators does supply a number of useful validators, but perhaps it could provide more ie. to restrict special caracters, raise warnings for fields which haven't any validators at all and force the user to set validators=[] like ForeignKey currently does for on_delete. Not sure if anything can/should be done though, ideas welcome :) -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/axIVyVbjd0bFateqELjclTklc1vX8cAP7X3nYhjF7OgqXyraSnlBcVZQyIZ74qaTxVWfct410z2Dt8GNU50WE2gPt0f8EYUvKr4fVW_Wlzw%3D%40protonmail.com.
Django default input validation accepts special caracters
Currently, when you order a security audit on a Django project from any of the firms I've seen so far (including my own), all inputs fall short on stuff like: "First name input: allows special caracters such as <>/"' which may cause a security issue with further developments done on the same database but outside Django". As far as I can imagine, special caracters would be acceptable on inputs that should accept code or some kind of math, which is not the case for most inputs. Django should harden default input validation to make it easier for Django projects to get a good grade on security audits, without having to go over all fields to setup basic input validators. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/EiNHz_fmHLmQXZ5ChTG0qrnp8BrP0s75szk9oDolStpIyMSz71B3yesI7U6K8QZNkUmeAN6v6zMhExwhwcbtGNeaOUgubDOIDK-Q4cVFvOw%3D%40protonmail.com.
Re: Make tag name a variable in form templates
Wait a minute you, are you suggesting that we should have a Python API to generate HTML tags (like, Ryzom, Iommi, and many others) and build on that instead of templates for widgets ? I wouldn't have asked for so much, but I really love this idea, as someone who is deeply bored by templates, which are a very poor way of graphical interfaces, as demonstrated by the GoF: the Decorator pattern are best suited for that, and my theory is that this alone is the reason many people prefer component based development so much, anyway, HTML is a tag based language so it's actually Decorator/GoF compatible, which is not the case of templates. Templates were made to maintain a silo between frontend devs and backend devs, that's exactly why they offer such a poor feature set (like, not being able to make a function call ! fixed by jinja2 at least). That philosophy has been refutated not only by fullstack devs which I believe many of us are (I've been dealing websites for 20 years now), but mainly by the DEVOPS philosophy which I believe we're all aware of by now: it aims at breaking the silos open. Did I get a bit carried away, revealing my secret plans to keep Django relevant for power hackers in 2020 ? Well, sorry about that. Anyway, GO DJANGO ! Let W3C fix our JavaScript problem :) -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/MrelhORrzShBhQhmdbh5dX-M08tsm3nyF_uhk-4guec6SZHktQVS5G7D-ydbGyC7FoZ27WjQCxeEIJW6kSvPOf-zAsLxdJ3FITTXi8tbLWc%3D%40protonmail.com.
Re: Make tag name a variable in form templates
There is no consistent philosophy that lets us change tag attributes but not tag names once it's valid HTML. These templates were not made for custom elements because they didn't exist, but it turns out supporting the custom element W3C standard is super easy: just let users set the tag name like you already let them set the tag attributes. My point is that if Django used variables for tag names in its widget templates, it would suggest developers can build HTML that's consistent with W3C standards, which any web framework should support OOTB, and if that's not their philosophy then either W3C standards have to change either the web framework has to change. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/bUHwZWZ3hpfO4t7UOkIPHrzJpvyE72r63rm1ycGH9schtoIyl8lozWjHPCXt54Uz04AfccQxr2Pmjl5ZIAUR9oK-m-Z9Cci5Tdr0YFX_KEw%3D%40protonmail.com.
Re: Make tag name a variable in form templates
You're absolutely right, except that I'm not trying to contribute a datepicker in Django, i'm not trying to make a reusable datepicker, I'm just trying to change the tag name as easily as I can change the tag attributes because it's now a valid W3C standard. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/81vl2BTOsbnntPid7ZPm5OBKabIQzSx1zIPhcUdK-hNKepuSgitsatcV02e7IX9M0sAsVGaHnlpJ4vlQfeCdPXc1zVd8rD-Zb6Ti-UdU0_c%3D%40protonmail.com.
Re: Make tag name a variable in form templates
If I understand correctly: - changing attrs declaratively is "clean enough" - changing the tag input declaratively is "not clean enough, a custom widget and template must be done" This seems contradictory to me. Should I subclass every widget to add a custom template that allows changing the tag name ? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/o6-9EQfVmpMdURTlFNhKC226S7LyninHco2NWSJM0GxUjaIvD0lQtwlaSQQ8NB3Zb1pd5UXkLEHFV56R8rS2xVocyw2veXWkqe0lJnLCRXQ%3D%40protonmail.com.
Re: Auto-installation of 3rd party packges
Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ Le vendredi, juillet 24, 2020 7:01 PM, David Rashty a écrit : > Nice! And thanks for sharing! I like this idea too. Why did you include "if > settings.DEBUG" by the way? For the sake of the example > I still think injecting code explicitly has certain advantages: > * I believe AppConfig approach could be implemented in apps.py by the package > author. If they chose not to write their package's configuration this way, I > assume there is a reason. I think changing settings at runtime is not well supported by Django but I might be wrong > * The AppConfig approach is a bit of a black box to most app users. I wanted > the result of the "indject" operation to mirror the package's > installation/quickstart docs almost verbatim. Okay but that means that you're going to have to update your code for every package in the world ... Or at least you could let maintainers paste the install code into their own AppConfig and have indject read setup code from there > * My package doesn't just address settings. It also has the ability to handle > introspection at the app and model level of a given project. For example, in > the latest version of the djangorestframework installer, I inject a > HyperlinkedModelSerializer corresponding to every model of every app in a > given project. I can't imagine how that could be implemented with the > AppConfig approach. Exposing a full-featured CRUD on an unauthenticated API seems pretty insecure by default, and doesn't that take you to the point where you have to remove generated code, which is what the README complains about with cookiecutter ? > * I did not want to create another prod dependency. "indjections" is only > used during development to create boilerplate code. Boilerplate code: exactly why I keep myself away from Java ! -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/AI5NcXJRY0zjC1NZBy0ix2z2vCJbR73KJIkszOyi7YJvZnI1qY2B-0q1mt7ZMZV6hcLuE_a2Lu9EX9ShhEBNMFHKS8zOanDhEluRGsDqWX4%3D%40protonmail.com.
Re: Add verbosity option to manage.py checks that outputs which checks are ran
Absolutely agree that a verbosity or debug option should print ... debug info. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/JPt00F_iHTwCOO2lJDb6g9C8D2bGFaz3OxGYGLPFkJzbOqgxth9vC0DJvEAyM787-T9CAlY8oo_FekzM5v1RddtY_X318zCCmuCjHjYnSMw%3D%40protonmail.com.
Re: Auto-installation of 3rd party packges
About your package, I wouldn't have gone "injecting code" in settings, but
rather leverage the entry points packaging feature or at least the AppConfig
feature.
class DJDTConfig(AppConfig):
def setup(self, settings):
if settings.DEBUG:
settings.MIDDLEWARE.append('debug_toolbar.middleware ...')
That would be really nice !
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/XPd_982R5IJsyC8RcBopdXqjH8w-MQPOk5lsKSLG7abnoNDbQpZWjmuPEaPxsxHJpyKQIFUWa-oTHPDUmAsQvavugge8Caa9ioTZ18Pomr0%3D%40protonmail.com.
Re: Auto-installation of 3rd party packges
There is https://gitlab.com/nerdocs/gdaps There has been discussion about this in the past about app auto-configuration (a feature CakePHP has): https://groups.google.com/g/django-developers/c/Lr4br0OzMQE/m/41hP7kaTAQAJ -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/syARPRRxjV92Q4r5tO9AzMXm2Oh-1IHLPapYVv02ILeyp3bX1tMgG3BrFympI3zPoF7EmqTz1UW82ERQS-GsClRO9Vv8scYb4fnEJDLCVZ8%3D%40protonmail.com.
Re: Make tag name a variable in form templates
For those who haven't followed, I'll try to re-explain prior to showing example
code:
Currently, we can change the attrs declaratively without going through whatever
override/boilerplate.
In 2020, we can use custom elements, which means that we also need to change
the tag name.
We don't need special constructors because custom elements configures with
attrs, which are already available declaratively.
Now for some examples:
class YourForm(forms.ModelForm):
class Meta:
model = YourModel
widgets = dict(
birth_date=forms.TextInput(attrs={'type': 'date', 'max': max_date})
)
Victory ! We now have a native date field with a one-liner ! But what if we
want to change to a duet date picker ? You need to change the tag name from
"input" to "duet-tag-picker":
forms.TextInput(attrs={'type': 'date', 'max': max_date}, tag='duet-date-picker')
It seems the reason for being able to set attrs this way but not the tag name
too is because this was designed prior to the custom element W3C standard
that's now implemented in every browser.
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/SBGGTxW2v6wS1BtkhN2gjeXTyNTvG_MoxDwBdbDb2Cx88JApu7wOZII4_94IEa9R6NB81Ct2hVkGs9nrSOg42Vao3Hz5x__5PVi0D4TByFY%3D%40protonmail.com.
Re: Make tag name a variable in form templates
Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ Le jeudi, juillet 23, 2020 6:53 PM, Adam Johnson a écrit : >> do you think it is better to create a widget class per custom element >> instead of just switching the template_name variable or just setting the tag >> name like any attr ? > > I'd imagine so. This way you can make required attributes their own arguments > to __init__, and any other customization you might need. It will also make > the form class a little clearer So, you'd be against custom elements that just work after changing the tag ? I really thought we should strive for that, and leverage custom elements to remove boilerplate code rather than adding more. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/eWxmxo38Vf6jlKTPTeY5DIotKpeslP2lbGycb9hvbhmrI5i6iqlWTC_slmJeEvKZRhVLbJdhKQvqYRHrLv8Vpx6ROCm7V7L8EfiN_icXfX4%3D%40protonmail.com.
Re: Make tag name a variable in form templates
The type attribute might not be relevant to most custom elements, but they don't matter: if they are not supported then they will not be used. Thank you for your interesting suggestion, do you think it is better to create a widget class per custom element instead of just switching the template_name variable or just setting the tag name like any attr ? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ykJu1oX9HSuq5HaLSfRZjw0qdoL_hZQee5SJ-1kT4ZgR88IfXu_4-PVhuOCLQ014zLmeLIxF8V9BRrQy6jp7-bu_dPofgIfqIKBKgWY7d9A%3D%40protonmail.com.
Make tag name a variable in form templates
Hello Currently, we can set attributes on widgets during runtime but the input tag name is hardcoded: https://github.com/django/django/blob/master/django/forms/templates/django/forms/widgets/input.html Which means that you currently have to copy the input.html template for every web component. Is it possible to make the tag name a variable to enable using custom HTML elements without having to copy a template like we do with attrs ? Thank you in advance -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/-KA4DZPYgBR0IIfAEM7A4B22tZEgUZOhD5ihFHfxUrLd8xCl9scLrI-iOTm7CsKvvya6CrIWm2nZksqrvZDqcaZ2uMxhSeMcojzUCuOuQ0Q%3D%40protonmail.com.
Re: Admin webcomponents
Another advantage that I figured while finishing the DAL 4.0 PoC offering the
AutocompleteLight WebComponent support in addition to Select2:
- easy to template with
Example:
def render(self, name, value, attrs=None, renderer=None):
choice = self.field.queryset.filter(pk=value).first()
deck = self.field.render_choice(choice) if choice else ''
return mark_safe(f'''
{super().render(name, value, dict(slot="select"))}
{deck}
''')
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/wmQMvU7_HYzliBdAAxiENVvzAWhqSXsEge2wTHQMX1YoQwx-edppdG44ZbZOagmX5aqkVIlxMuExvRrHZc4ED7sQVYkK__8lWNesL1qJFis%3D%40protonmail.com.
Re: Good example of settings_changed signal usage
disconnect/reconnect signals maybe ? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/E4oyeqLRkl9RBI9Zjw5dgoKjS0rpQfyFIMkmqk9z5vp9373hAaJfaq0PnM91qGNyFbi5W-kU5C00eknDq36VT-Vze532AqNTzqSrXj_dfjU%3D%40protonmail.com.
Re: Admin webcomponents
Hi all, We got a working PoC here: [https://github.com/yourlabs/djwc](https://yourlabs.io/oss/djwc) Advantages: - no more nodejs - no more webpack - no more form.media - as such, much more reusable - no more manual asset management in templates - works with components of any framework that can build them as webcomponents - no more need for a script to depend on a specific HTML structure, which makes the HTML elements portables outside the admin easily (in theory!) Disadvantages: - Does some regexps response.content - Custom elements requires aria attributes to keep accessibility features - Adds a step prior to collectstatic Keep in mind it's a PoC, I want to use this to replace MaterializeCSS by Polymer in CRUDLFA+ though, so hopefully I'll take the time to thoroughly test and optimize it and confront it to a complete CRUD situation. As such, unless anybody wants to discuss it more, I will maintain it in the separate repo for a couple of years before I come back to push it forward. Have a great day -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5re_vISQNKMkWz3ZTWkjdR0cXCSd5g0o595VcwZQ-WIyENsqYVTl9gkzlBWx0Qo2r-tyDbbUmpVO60kbXC1Kavl571U5dlZM8UzVLNh_gvY%3D%40protonmail.com.
Re: collectstatic content hash
Sorry, just figured Django already has that ! https://docs.djangoproject.com/en/3.0/ref/contrib/staticfiles/#manifeststaticfilesstorage -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/OJE7hXfbGMhy5tx41Cdvm1Uui4aFLRAiNl9rdIEESTmJcCpWgKtJNUG-36lwaOJgBHUNwg1G4XbDLM_H084G61I_69X-ZLfApwQ3HncgAzQ%3D%40protonmail.com.
collectstatic content hash
Currently, if yourscript.js is served with {% static 'yourscript.js' %}, you
open the page in your browser, then change some HTML and yourscript.js and
redeploy, reload the page without refreshing browser cache manually then you
will see the new HTML with the old version of yourscript.js.
This seems to be a problem that collectstatic and {% static %} could solve:
1. collectstatic adds the script content has in the filename of the file it
copies
2. collectstatic removes the previous version from the static root, if any
3. {% static %} will find the right file name with the content hash (there
should only be one thanks to 2.)
What do you think ?
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/Mq2gOv-t_mc5rg4ESgFFp9Ox6HxKggLaOMnEH1DBbC72Na1_rdgNxMUko6Z3_K8fjIod1aaSKApVSo9cnkYuvxO5tmICSlZ-myBT7qjY7NI%3D%40protonmail.com.
Re: Admin webcomponents
I cannot state how excited I am to see such as seasoned Django hacker as Jacob being up for the task. I believe I'm not the only one who have had, for a long time now, a vision for Django where the effort in the django.contrib.admin becomes usable outside the admin and end up beating Rails on generic views and stuff. As much as I have a fantastic experience with StencilJS as an avid TDD and Unit Testing fan myself, I don't see jQuery going anywhere in any kind of future. While you don't need it so much anymore for basic things, but for some advanced usages it does provide a friendlier API than the DOM. And if you're going to pull it for a reason or another, why would you want to write document.querySelectorAll instead of $() ... Also, keeping jQuery in the first iteration will force figuring out dependency management, how Django wants to leverage the browser import calls. So, as long as we have something else to tackle this, then removing jQuery would be fine. But keep in mind a lot of stuff uses it, such as select2, however, we might also decide to use other autocomplete webcomponents. > Many years ago, I wrote a Django app to integrate client-side form validation > with Django's server side logic. Well that looks really good, we're also undergoing efforts in the ryzom library, and also had another interesting pattern proven in a library called facond, both of which might be worth to take a look at if you also get your kicks from this kind of stuff. https://facond.readthedocs.io/en/master/index.html [https://yourlabs.io/oss/ryzom](http://yourlabs.io/oss/ryzom) > I'm very much interested in this topic, because I already implemented parts > of this in AngularJS, although this now is > an obsolete technology. Well the fast deprecation of JS frameworks has been a problem for Django for years, and for a good reason. This is why I believe we can see salvation in the webcomponents standards, living since 2017 and now available in every browser engine, the time has come for Django to keep up with the W3C standards. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/co4AO24VjvnGZ9_bD9o165F2KQhfZOU-ugaeS_fX2nEiHBJzWsd25QrXdDIvZRV-RiO2-88Qmb8262lUQWjxoYnGcebhWaPSlRE-xxvlTfM%3D%40protonmail.com.
Admin webcomponents
Hello everybody, Currently, the admin site provides various form fields, and formsets, that depend on JS scripts. These are loaded by form media. Nowadays, webcomponents have made it into standard HTML, all browsers now support: - Custom Elements: https://w3c.github.io/webcomponents/spec/custom/ - Shadow DOM: https://w3c.github.io/webcomponents/spec/shadow/ - ES Modules: https://html.spec.whatwg.org/multipage/webappapis.html#integration-with-the-javascript-module-system - Template elements: https://html.spec.whatwg.org/multipage/scripting.html#the-template-element/ Proposal: upgrade the admin JS from Form.Media to webcomponents. When/If this gets done, we will have the maturity to start extracting webcomponent code from the admin site into main Django, as such, I see this proposal as the required first step before trying to deprecate form media in future releases. Needless to say, webcomponent support would be really good to have for Django 4. Thank you in advance for your feedback Have a beautiful day -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/m4h3LNOthoOnLAlJFGqMUNnaf6jOhZxK_J2egLNz9xThbMpp88bdSQS3-42Ual5rI0nUpRu2DGGtVpEHTeul7CO9vD1sCYalUPVBwbB1sik%3D%40protonmail.com.
Re: Making startproject's settings more 12-factor-y
All right, thank you for your feedback. May I throw in the idea of using DJ_ instead of DJANGO_ as prefix ? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/PBiCVsKC2UAJFHuD-tEkUh2063D7DgV1DcAxdlcFI2tSqpPxK-8XVWSPbSnyvG5spVf_1QYHZeyNN2dimPNPk7NrS0eh9zq-PhAQxSHAsMk%3D%40protonmail.com.
Re: Making startproject's settings more 12-factor-y
Do we really need DJANGO_ prefix on env vars ? In my first years of practicing 12-factor I used such prefix, but the last 5-6 years I let it go, because I just ended up with a list full of DJANGO_ variables in a containerized where only Django is running. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/3mulSta40m2DoZMPITSVrn3XE4xm_9NBbL1CMxtE8MqCnFqR-KT_RAOpxqfhH7Gn_6he9QkZ0z0HN0O2y2GAz8ifdQFghXcjfOMQF_wsUgs%3D%40protonmail.com.
Re: Management of static assets
Web components are now standard HTML without JS frameworks, so that could be supported by Django. In which case, even StencilJS tsx components would work out of the box. Prior to rendering, a middleware could scan the response and add the registered scripts/styles for the custom HTML tags it finds. This would be a lot more convenient than form media, more portable and cover the full spectrum of use cases. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ILpwAOlivF-u3TTxhq0HgKy4CLazC_L3-bGQ8DFUE4Wsg5Ai6hgArNoyfR74J5mPdTIjfJP3iyS09F55wE0UxQJqtJqPo_BXQmfBs1Y8Yb4%3D%40protonmail.com.
Re: ./manage.py settings
It wasn't discussed indeed, nice command, thank you ! -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/2LiWpUB0mNim6QOo9C4_1EUMeOFkZvE3zzZymvZt2gw2YJgW7u-s6G1VN32S5_3fqLPG2AaIdxONU3qTvAwxhVY5QH1VZ0RKKM1eBZStC48%3D%40protonmail.com.
./manage.py settings
Hi all, So, just on #django IRC channel there was a user trying to help another one, asking for some settings through ./manage.py shell etc ... A discussion that went kind of like "Print out your settings" "How would I print, I tried that, I'm in settings.py" "With ... print()" "but in the shell, __file__ is not defined" and so on, and 20 minutes later the user couldn't print his settings and left. TBH I'm pretty fine because the users I support are on projects where I added djcli to the requirements, so I can always ask the to do the djcli setting command to print out a setting. It's very useful useful to me, I think Django should a command to dump runtime settings because that should make the life easier of Django users trying to support newbies in their own projects, where they don't have installed a custom command, it's pretty cheap to make and maintain and should save quite some frustration from both sides of the story. What do you think ? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/X2HkH0yasxu2XVxBuVkbTfdSHctL7y3pW9seQ8CHFcVOpmsiyN80JlDYH2g5F6IfPvEdN4zyG6vuxj2HEMJaXUSErMUM5IT70iLvkxsrc7U%3D%40protonmail.com.
Re: Management of static assets
Le samedi, mai 9, 2020 10:39 PM, Aymeric Augustin a écrit : > Perhaps Django could standardize a way to accumulate a list of CSS and JS > assets to include in a page, which could then be rendered in HTML, perhaps > after optimizations (provided by third party apps). The Cubic web framework has something like response.scripts and response.styles where you introspect and attach or remove stuff along the way. Typically, if two different apps ship their own jquery.js then things are not going to work, one jquery will override the other and plugins will not be registered anymore. So in Cubic at least your lib can check if there's a jquery js prior to adding your own. It's no silver bullet though. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/dncgO1IUgyjWRJ9fMMbHWh5L9W5VfmgNgwyP9BNo2w11wdNAtZ8JZEH6bH61i-1o3kC_iPKx0ptXGMexpUQFC1u4oG13VEdA7xg0RX3Lw0U%3D%40protonmail.com.
Re: queryset.iterator() and prefetch_related()
Awesome, thank you so much charettes. We're implementing the "private" attribute meanwhile so there's no rush. Have a great day -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/dmzUJkHwxaO0lX-CL3B2TbDhPGhJOcG7kmB7HJ3SNF72m8FieDM1HPnb3KprQXNJyClLisOe5awCBMqlAbnkkFwfV6ML73UzHLe9zpr1P7w%3D%40protonmail.com.
Re: queryset.iterator() and prefetch_related()
Well that's good to know, thank you charettes ! Does that mean that the piece of code from forms that's using "private" API from QuerySet is going away in the next Django version ? In this case, we probably don't have to do anything on our end ? -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/VkC5P_eBfbOxnWPqdUhdiUVp02eT4qwfpQA6meIJsSASKaO1Djn3HTgAGf9XmB6E5xri7k73YYpeLooI0tveTT2YkgPwnnp69I6vpPx_WDA%3D%40protonmail.com.
Re: queryset.iterator() and prefetch_related()
We've decided to open a ticket and MR for it: https://github.com/percipient/django-querysetsequence/issues/67 (that would happen this weekend) If there's any objection please let us know. Have a great day ‐‐‐ Original Message ‐‐‐ Le mardi, avril 28, 2020 6:39 PM, 1337 Shadow Hacker <1337sha...@protonmail.com> a écrit : > Sorry I sent the mail prior to finishing, redoing fully from here: > > I notice a piece of code inside ModelChoiceIterator that seems to keep going > a bit back and forth, currently it looks like this: > > # Can't use iterator() when queryset uses prefetch_related() > if not queryset._prefetch_related_lookups: > queryset = queryset.iterator() > > But before it looked like this: > > # Can't use iterator() when queryset uses prefetch_related() > if not queryset._prefetch_related_lookups and queryset._result_cache is None: > queryset = queryset.iterator() > > Anyway, if you want to implement your own QuerySet class from scratch, which > is the case of django-querysetsequence, and that's pretty useful to feed > ModelChoiceFields, as long as you prefix object ids with content type ids > which is pretty trivial. > > Do you think it would be acceptable to start an effort with the objective of > making django.forms.models rely purely on a public API of QuerySet ? > > In this case, how would you accept to see that changed ? > > Thanks in advance > > Have a great day -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/qRlEqcCtLHKcogJ3Q8-tEeDcagPTd8XtyQqaPtBj9BM_kNTU3pIGwVnFSmlu_TbA0dQYmSjNc1_CCUjL_gYNvu-cD4lM1tkNcMxtJIKkQwM%3D%40protonmail.com.
Re: queryset.iterator() and prefetch_related()
Sorry I sent the mail prior to finishing, redoing fully from here: I notice a piece of code inside ModelChoiceIterator that seems to keep going a bit back and forth, currently it looks like this: # Can't use iterator() when queryset uses prefetch_related() if not queryset._prefetch_related_lookups: queryset = queryset.iterator() But before it looked like this: # Can't use iterator() when queryset uses prefetch_related() if not queryset._prefetch_related_lookups and queryset._result_cache is None: queryset = queryset.iterator() Anyway, if you want to implement your own QuerySet class from scratch, which is the case of django-querysetsequence, and that's pretty useful to feed ModelChoiceFields, as long as you prefix object ids with content type ids which is pretty trivial. Do you think it would be acceptable to start an effort with the objective of making django.forms.models rely purely on a public API of QuerySet ? In this case, how would you accept to see that changed ? Thanks in advance Have a great day -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/8s1A9w1r5BtgXJCoWjwInlAzC5cQeYV3LWjFnGxcz-1qcMSxGyjAz6mdpUxmnB3wveLORpXmMcPjwVk-o_SbzTjy6ZMkbkn89qCH_i2S4n8%3D%40protonmail.com.
queryset.iterator() and prefetch_related()
Hi all, I notice a piece of code inside ModelChoiceIterator that seems to keep going a bit back and forth, currently it looks like this: # Can't use iterator() when queryset uses prefetch_related() if not queryset._prefetch_related_lookups: queryset = queryset.iterator() But before it looked like this: # Can't use iterator() when queryset uses prefetch_related() if not queryset._prefetch_related_lookups and queryset._result_cache is None: queryset = queryset.iterator() Anyway, my issue is that it forces you -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/GsH5_PynvlvfvUOGXdykXjO56LubTE6KuNzKjLZpnn2SX_AqPJ5Y43DbelaKtV8AiTEJBl5OETUjhJ6etgiBQGP9-koYrM2LOlVhG4Om6Yc%3D%40protonmail.com.
Re: Discuss ticket 20264: URLValidator should allow underscores in local hostname
> when there are many sites in the wild that use underscore in their domain > name. Can you share some examples please ? In general, we should abide by standards unless we have a really good reason. In my experience I always had to replace underscores by dashes for a reason or another in hostnames that were setup by people who don't read RFCs anyway, so I'm not sure Django itself can make a big difference. Nonetheless, can't you override the validation on your side ? Best -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4P0Vp6NoChXt46knjUSR74oJYbPbNbK2mEe7Z1fRy3aFONIVQ7Icz5Nujmy_EHuwUA7PjjvnUiaqMdb1ADWmPOAf2XfonKEE51DUpt4Oqcc%3D%40protonmail.com.
Re: [Probably BUG] set_password and check_password accept values other than string as parameters
I agree with Adam, but in this case it seems to pose a security risk in case of user mistake, as such, raising a ValueError would have protect against the mistake of passing empty passwords, unless you consider empty passwords a feature of course in which case please dismiss my email. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9Xx6DvMQMWVWMRYMhbK-8nXfyPrNU_5ljWd-YuXeXRmz3_pnYXT6axEYrDBfW4K1v5OGEshIR2SDAeZxpnDBSk6SMLe4oeiwcrDMnz7xah4%3D%40protonmail.com.
Re: Forms submitted by bots
We had the same problem and didn't want to use recaptcha because it's too hard for some users (ie. senior users). So, we used django-simple-captcha, but that didn't stop some of the bots. Our SecOps produced automated captcha parsing scripts so that we could fine-grain configuration, and found out a configuration that lets them only like 20% chances of success, and we don't have any more spam at all (maybe the captcha recognition scripts hackers use are not as good as the one we made for testing purpose ?). This is our configuration : https://github.com/betagouv/mrs/blob/0f37f786c4770e0f401c071fb2fef85f18303aca/src/mrs/settings.py#L432-L448 Our special functions, which are just a copy/pasted from the original app source code, with the minimal modifications to make it stop : https://github.com/betagouv/mrs/blob/0f37f786c4770e0f401c071fb2fef85f18303aca/src/contact/captcha.py Note that audio works well but in english only, but doesn't require any external webservice, it does require Pillow though. I suppose that would be the preferable implementation detail if Django were to integrate such protection. Hope this helps -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/0uhCjKcLoDF6ZvhEwaFDhCE1NerV-GBvE-qJWa60RIA0zrNiu067z38tO-ZlvOPUp2uFf-Ri1qOqqnDksfdi1SKVqFlv5DgHteD6YGSnpXw%3D%40protonmail.com.
Re: Form customization
Try tri.forms maybe The main problem IMHO is that rendering is stuck in a template system, rather than components that could leverage the decorator pattern as it's known to be better for UI programing (cf. GoF, React & friends success) ‐‐‐ Original Message ‐‐‐ Le dimanche 6 octobre 2019 01:11, Alex Scott a écrit : > Hi all, > > Are there any current plans or developments to allow better customization of > forms? I've browsed several old Stack Overflow, django-users and Django > ticket requests and it seems common enough to want to say, add a class to > every form field or field label, or change the label suffix from ":" to "". > > The current "solutions" seem hacky and non-DRY, usually requiring custom code > for every form used in a site. > > Would it be a terrible idea to allow these to be set in settings or in a base > form that gets inherited by everything else? > > Thanks, > Alex > > -- > 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 view this discussion on the web visit > [https://groups.google.com/d/msgid/django-developers/CAMiVppbh%2BOAWa6z0k0m2uQj0ZrguCAzgz3tt3yhWa6_FjMO_ow%40mail.gmail.com](https://groups.google.com/d/msgid/django-developers/CAMiVppbh%2BOAWa6z0k0m2uQj0ZrguCAzgz3tt3yhWa6_FjMO_ow%40mail.gmail.com?utm_medium=email_source=footer). -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/qBTxFiY0cYK-jSS7a21kO2PZRvcMP1IQ1nwVLpYd5KwThgQPDuGhexO_OzV0MrTtuwd8ZnEpnp6cMnpMb4rSyMzNeHvrb3IUDAUOV7n_bz4%3D%40protonmail.com.
Re: Django LTS support time
Actually I'm pretty sure it could be done even if DSF kept a profit, to re-inject it into other developments for exemple. AFAIK the major difference between non-profit and company is that you don't own it and as such you cannot take dividends out of it personally. IMHO everybody would benefit if DSF did more commerce and was stronger by that mean. I could sing an ode to commerce but that would be much off-topic. אורי if you're looking for commercial extension you can certainly hire someone for that for the time being, Patryk's company seems to have willing developers, or hire someone to face the debt in your codebase, which Patryk's company will probably recommend for the same budget. Sorry for being so binary but unless another idea emerges from this topic... it seems pretty cornered at this point, sorry for not being more helpful. Best of luck -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/4cFecMrTqfdUSknAd8EcJNaIxFI7xyNDYd3mI9wwf8en2GgnoHppWAJm7AYAxqLgexH2g6iSKNNC6CwN50iXkFiWP49UAcoqQs_U9N0K8RU%3D%40protonmail.com.
Re: Django LTS support time
This reminds me when m$ agreed to sponsor an open source rewrite of one of their languages, and asked the devs to reproduce the same bugs that were in the closed source version, and then went on and sold that as a feature. If there are people who are willing to maintain old versions for money that's fine, and could certainly be done under a non-profit / charity it's just about not keeping any benefit for the organization. But it certainly goes against everything I would know about CI/CD (I mean as practice, not as tools). -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9SBF1_T9X-zWOFJ0I_cHzJLYuExGvBvsNK5KqU6004_Mvrc8073Z9Pw0NZbnatZeAwm8SWR76s_l52rT__1VGC9GfCVmeE6NAKmZdqZodrk%3D%40protonmail.com.
Re: Make Development More Accessible
Given the number of Open Pull request, does Django craves more contribution quantity, or quality ? Not the same focus -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/vI1vAFeQXgyEe2xaMo2ViWOK5skS48prQHEtGchZB9AkdO3Y5ELDstLC52P0h477W79O8PsjoCfTZpyJvX2s1V6PkFm78vtrYT1URJ5kA68%3D%40protonmail.com.
Re: Display labels for autocomplete fields
>> Would it be possible to add a `search_display_fields` on the relevant >> ModelAdmin, alongside `search_fields` to customise the display in the form >> select box? This could be either a model field or a callable on the model or >> modeladmin. Another suggestion is to add get_FIELD_autocomplete_display(), to the model or teh ModelAdmin -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/lRaN6wQSqzdeDboF0UO79hAP6jbDoqEXN-xbz32hgU8HRkO4Pvj_bySMpQ7OTO2rB0aNcACTpMF040vUnGEkH74oBgaQDMIyjTG_wDzqeHw%3D%40protonmail.com.
Re: Django Websocket Implementation Request
> They're not that popular actually, it seems... They might become more popular, when they work behind proxies ... a limitation which you usually figure out after your first important client tries to connect from behind their corporate proxy, then you can implement polling again - a fallback that socket.io provides. However, websockets are nice to have if you're using a Django library that supports data binding such as ryzom, maybe there are others but I'm not aware about them, and it doesn't implement the polling fallback so far afaik. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/STfktCMulCv9lYeEfdC96aFUmH4Y2_wz90LV9_15nmhqr0YCuThgrCJcZ32N3odKDtR0TThEBgxdxV_j-yjuZZNVHGwRE7bQ77mmiv0TVw8%3D%40protonmail.com.
Re: Django LTS support time
Hi, Lean Sensei practicing Django since 2008 here. Have tried all sorts of strategies, the one that offers the best effort/ROI ratio is to upgrade as soon as a new version comes out, even if that means contributing patches to dependencies and deploying forks until patches are released. Best of luck -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/GrEY9QLXy903LnYwLvv54Irn2hUfGJlearm6hNR6KgRJV0awYTwQxgyLpUbN-BRrZJJQD5HzC7okEKiX-OVH8tlTQXjPqaFJVuka62cTaqk%3D%40protonmail.com.
Re: Translation templatetag aliases
If you use autocomplete then typing "{% tr" should propose both translate and
translateblock which reduces the chances to pick the wrong one because the
other choice did not show up
--
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 view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/urSZ5VzF46WTsWkxJvj_F7oICyHiV7MWBiCs-amohot3xkiC_abHg0EbbGxrjVkSErJgy73c9TOQa4a7zmQyXEFnEkgqYYqEwZO456k9psU%3D%40protonmail.com.
