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
> On 24 Jul 2020, at 14:06, '1337 Shadow Hacker' via Django developers
> (Contributions to Django itself) wrote:
>
> Now for some examples:
>
> class YourForm(forms.ModelForm):
> class Meta:
> model = YourModel
> widgets = dict(
> birth_date=forms.TextInput(a
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 Grou
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 ...')
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
For me, a custom widget (that could use its own template) looks cleaner.
Something like birth_date=DatePicker() seems more readable and doesn't
require repeating "tag='duet-date-picker'"" each time. If you prefer your
one-line version, you could override the input.html template and make the
tag
Nice! And thanks for sharing! I like this idea too. Why did you include
"if settings.DEBUG" by the way?
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
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
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 t
* 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
Correct. It would be *ideal *if the package's author used AppCon
A datepicker is rather different from a plain TextInput widget so I think
it's good design to use a separate widget. If Django provided datepicker
functionality, I'm fairly sure it would be provided as a separate widget
rather than instructing users to use something like
forms.TextInput(tag='du
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 becaus
WhatsApp number +918709440658
On Sun, 19 Jul 2020, 11:33 pm chinna, wrote:
> Thank you Vishnu
>
>
> On Sun, Jul 19, 2020 at 7:16 AM Vishnu Thuletiya <
> vishnuthulet...@gmail.com> wrote:
>
>> I think you can use 'select_related(name of foreign key class) ' insted
>> of all().
>>
>> On Sun, 19 Ju
My point is that if Django used variables for tag names in its widget
templates, it would suggest developers write code that's inconsistent with
Django's design philosophy. As was pointed out with things like the 'type'
attribute, these templates aren't meant to be generic templates for web
com
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 li
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, wh
This issue is exacerbated by similarly unaware / uncaring mailing list users
responding to support requests.
What is the best path forward here?
> On 10 Jul 2020, at 3:09 pm, Jure Erznožnik wrote:
>
>
> I too volunteer for the screening job.
>
> LP,
> Jure
>
> On 09/07/2020 16:10, Peter I
17 matches
Mail list logo
