Re: Make tag name a variable in form templates

['1337 Shadow Hacker' via Django developers (Contributions to Django itself)]

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

[Carlton Gibson]

> 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(attrs={'type': 'date', 'max': 
> max_date})
> )

Right, but you can provide a different template here, components.html say, that 
took the `element` name. 

> 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.

Maybe. Maybe just that `input` is pretty generic in form land — it’s not 100% 
clear we need increase manageability by adding a template that allows 
constructing arbitrary HTML elements. (Note the __maybe__…) 

I’d use a custom template to begin. Then when you’re at the point of preparing 
a PR we can look at whether adjusting the templates makes sense. (Hopefully 
that seems reasonable to you.) 

Kind Regards,

Carlton

-- 
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/EEED97FE-6E11-45AC-B1EC-B6A12D437DB4%40gmail.com.

Re: Auto-installation of 3rd party packges

['1337 Shadow Hacker' via Django developers (Contributions to Django itself)]

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: Auto-installation of 3rd party packges

['1337 Shadow Hacker' via Django developers (Contributions to Django itself)]

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: Add verbosity option to manage.py checks that outputs which checks are ran

['1337 Shadow Hacker' via Django developers (Contributions to Django itself)]

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: Make tag name a variable in form templates

[Tim Graham]

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 name a variable. I wouldn't advocate for that change in Django's 
input.html template.
On Friday, July 24, 2020 at 8:07:10 AM UTC-4 1337 Shadow Hacker wrote:

> 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/06c4b43d-2f30-47db-93ae-5c12b75457f3n%40googlegroups.com.

Re: Auto-installation of 3rd party packges

[David Rashty]

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's configuration
this way, I assume there is a reason.
* 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.
* The injected code is just a starting point.  I expect the developer will
want to lock the injected code and make modifications that suit their needs.
* 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.
* I did not want to create another prod dependency.  "indjections" is only
used during development to create boilerplate code.

If I didn't understand something about your suggestion, please do let me
know.

Thanks!



On Fri, Jul 24, 2020 at 8:38 AM '1337 Shadow Hacker' via Django developers
(Contributions to Django itself)  wrote:

> 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 a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/5jO0367eiVg/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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
> 
> .
>

-- 
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/CALGYj_0377uJPedHpVy9CuKqF6q2WEXkLCmtSF-PWBrvhpapTw%40mail.gmail.com.

Re: Auto-installation of 3rd party packges

['1337 Shadow Hacker' via Django developers (Contributions to Django itself)]

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: Make tag name a variable in form templates

['1337 Shadow Hacker' via Django developers (Contributions to Django itself)]

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

[David Rashty]

* 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 AppConfig in the
way you suggest.  "indjections" goal is to bridge the gap between the
package's actual implementation and just getting to work out of the box in
a given project (with reasonable defaults).

* 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 ?

Yes, it does.  That's why I have the "INCLUDE_APPS" settings variable.  But
nonetheless, there is going to be stuff to delete/modify just like
Cookiecutter.  The difference is that with Cookiecutter, you "inject" like
12 things in one shot and have to delete 6 things and hope you don't break
something critical in the process.  With indjections, you inject one small
thing at a time, make modifications, write tests and then move on to
the next package.  It's kind of like the difference between unit tests and
integration tests: 2 different flavors that serve the same goal.  As far as
being "insecure"; that's true in general, but the djangorestframework
installer also injects permissions.IsAuthenticated in settings.py.



On Fri, Jul 24, 2020 at 1:11 PM '1337 Shadow Hacker' via Django developers
(Contributions to Django itself)  wrote:

>
>
>
> Sent with ProtonMail  Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> Le vendredi, juillet 24, 2020 7:01 PM, David Rashty <
> david.ras...@pandibay.com> 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 a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/5jO0367eiVg/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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
> 
> .
>

-- 
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/CALGYj_3ExyrbZC_Jfza47T7of3TGj1_JDR%3D3o6NqrmHqC3XHFw%40mail.gmail.com.

Re: Make tag name a variable in form templates

[Tim Graham]

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='duet-date-picker'). Consider widgets 
like NumberInput,  EmailInput, URLInput. We use separate widgets rather 
than something like forms.TextInput(input_type='number').
On Friday, July 24, 2020 at 1:18:27 PM UTC-4 1337 Shadow Hacker wrote:

> 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/c1d3eb5d-b5aa-4b12-a585-2e1b74d0c68cn%40googlegroups.com.

Re: Make tag name a variable in form templates

['1337 Shadow Hacker' via Django developers (Contributions to Django itself)]

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: Django Query optimizing performance (HUGE DATA)

[Sci Mithilesh]

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 Jul 2020, 9:11 am karthik challa, 
>> wrote:
>>
>>> Hi Experts,
>>>
>>> I am trying to execute the below query and the query is taking more than
>>> 5 minutes.
>>>
>>> Here are the details
>>>
>>> Model.py
>>>
>>> class Url(models.Model):
>>>  subdomain = models.ForeignKey(Subdomain, null=True, blank=True,
>>> related_name='url_subdomain', on_delete=models.SET_NULL,db_index=True)
>>>  full_url = models.CharField(max_length=1000, unique=True, db_index=True
>>> )
>>>  class Meta:
>>>  ordering = ['full_url']
>>>
>>>  def __str__(self):
>>>  return self.full_url
>>>
>>> 1>Django query ORM
>>>
>>> subdomains = Subdomain.objects.all().annotate(numItems=Count(
>>> 'url_subdomain')).order_by('name')
>>>
>>> 2>SQL Query
>>>
>>> SELECT "urls_subdomain"."id", "urls_subdomain"."created_at",
>>> "urls_subdomain"."name", COUNT("urls_url"."id") AS "numItems"
>>>  FROM "urls_subdomain" LEFT OUTER
>>> JOIN "urls_url" ON ("urls_subdomain"."id" = "urls_url"."subdomain_id")
>>> GROUP BY "urls_subdomain"."id" ORDER BY "urls_subdomain"."name" ASC
>>>
>>> 3>Templates
>>>
>>> {% if subdomains %}
>>>  
>>>  Subdomain
>>>  
>>>  {% for item in subdomains %}
>>>  item
>>>  {% endfor %}
>>>  
>>>  
>>>
>>>  {% endif %}
>>>
>>> Please let me know how can i optimize the preformance Thanks & Regards,
>>> Karthik
>>>
>>> --
>>> 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/996db826-fe18-4557-977b-58493c1f9481o%40googlegroups.com
>>> 
>>> .
>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/django-developers/tEIXmhCXXO4/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, 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/CACggCHuGf%2BwUA4pYcB9%2BfDt3XLpVsjqQaw%3DyoL6WrfcwKp%2B5bA%40mail.gmail.com
>> 
>> .
>>
> --
> 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/CAH6_U_ainAUaw2AXWmzA%2BEdDEY%2B-AHOPbO1LXnHOX168DnUrdQ%40mail.gmail.com
> 
> .
>

-- 
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/CAJP%3DbzAPwmoK04GC0kypGO9yis7j5ZWAGLePzBMZ2SZpe9GWPg%40mail.gmail.com.

Re: Make tag name a variable in form templates

[Tim Graham]

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 
components.
On Friday, July 24, 2020 at 2:47:37 PM UTC-4 1337 Shadow Hacker wrote:

> 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/e9ed300b-a845-49db-83a3-011460577550n%40googlegroups.com.

Re: Make tag name a variable in form templates

['1337 Shadow Hacker' via Django developers (Contributions to Django itself)]

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

['1337 Shadow Hacker' via Django developers (Contributions to Django itself)]

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: Welcome email

[Kye Russell]

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 Inglesby wrote:
>> Hi folks,
>> 
>> Is there any moderation for posts from new users?  It can be enabled, and 
>> I'd be willing to be part of a team that filters posts from new users.
>> 
>> All the best,
>> 
>> Peter.
>> 
>> On Thu, 9 Jul 2020 at 13:59, Adam Johnson  wrote:
>>> I think that's a good improvement, not bikeshedding :)
>>> 
>>> On Thu, 9 Jul 2020 at 13:17, Shai Berger  wrote:
 Sorry for the bike-shedding, but I think the text should drop the
 "using Django" language. The people who come here with these questions
 clearly think of themselves as developers, not users.
 
 IMO It should go something like,
 
 Welcome to django-developers, the mailing list for discussion
 of the development of Django itself.
 
 This mailing list is not for support developing apps and
 websites with Django. For support, please follow the "Getting
 Help" page: https://docs.djangoproject.com/en/3.0/faq/help/ .
 This page will direct you to the django-users mailing list or
 other resources, so you can find people who are willing to
 support you, and to ask your question in a way that makes it
 easy for them to answer.
 
 Thanks,
 
 The Django Community
 
 
 
 On Wed, 8 Jul 2020 11:50:16 +0100
 Adam Johnson  wrote:
 
 > Okay I'm in favour. That said, there's already a banner on the groups
 > page:
 > 
 > This group is for the discussion of the development of Django itself.
 > If
 > > you want to ask questions about using Django, please post on
 > > django-users.
 > >
 > 
 > Suggested wording, adapted from my templated reply:
 > 
 > Welcome to django-developers, the mailing list for discussion of the
 > > development of Django itself.
 > >
 > > This mailing list is not for support using Django. For support,
 > > please follow the "Getting Help" page:
 > > https://docs.djangoproject.com/en/3.0/faq/help/ . This page will
 > > direct you to the django-users mailing list or other resources, so
 > > you can find people who are willing to support you, and to ask your
 > > question in a way that makes it easy for them to answer.
 > >
 > > Thanks,
 > >
 > > The Django Community
 > >
 > 
 > Who has access to add this? Someone from the DSF board, the ops team,
 > or the fellows?
 > 
 > On Mon, 6 Jul 2020 at 00:02, Ahmad A. Hussein
 >  wrote:
 > 
 > > +1 on this. Here's the relevant feature
 > >  I found.
 > >
 > >
 > > Ahmad
 > >
 > > On Sun, Jul 5, 2020 at 7:58 PM Adam Johnson  wrote:
 > >
 > >> I can't find a google groups feature that would allow this. Do you
 > >> know of one? It might otherwise require a custom bot.
 > >>
 > >> On Sun, 5 Jul 2020 at 16:14, Arvind Nedumaran
 > >>  wrote:
 > >>
 > >>> Oh I understand. I meant we could include the distinction in the
 > >>> welcome email and possibly a link to the other list.
 > >>>
 > >>> That may reduce the number of people who may be looking for help
 > >>> but end up here mistakenly?
 > >>>
 > >>> Get Outlook for Android 
 > >>>
 > >>> --
 > >>> *From:* django-developers@googlegroups.com <
 > >>> django-developers@googlegroups.com> on behalf of אורי
 > >>>  *Sent:* Sunday, July 5, 2020 8:39:22 PM
 > >>> *To:* Django developers (Contributions to Django itself) <
 > >>> django-developers@googlegroups.com>
 > >>> *Subject:* Re: Welcome email
 > >>>
 > >>> I think because this list is called Django developers and what we
 > >>> call "Django users" are also developers who use Django. But they
 > >>> are developers.
 > >>>
 > >>> אורי
 > >>> u...@speedy.net
 > >>>
 > >>>
 > >>> On Sun, Jul 5, 2020 at 5:59 PM Arvind Nedumaran
 > >>>  wrote:
 > >>>
 > >>> Hey everyone,
 > >>>
 > >>> I notice that people who try to find support on using Django
 > >>> mistakenly post in this list and sometime usually has to write an
 > >>> explanation about how this is the wrong place.
 > >>>
 > >>> Could we possibly as a welcome email whenever someone joins the
 > >>> group?
 > >>>
 > >>> Just a suggestion.
 > >>>
 > >>> Best,
 > >>> Arvind
 > >>>
 > >>> --
 > >>> You received this message because you are subscribed to the Google
 > >>> Groups "Django developers (Contributions