date:20190117

Re: What do you think about unify templates feature?

2019-01-17 Thread shiva kumar

Could you please explain about it. I hadn't understood ur idea.

On Thu 17 Jan, 2019 2:32 pm J. Pablo Martín Cobos  Hi,
>
> From one year ago, I am using an own command for Django templates that
> unify them. With an example it is easy to see. If I am to render for
> example a template call news.html like it:
>
> 1. news.html
>
> {% extends "base.html" %}
>
> {% block title %}
> {% include "inc.news.title.html" %}
> {% endblock %}
>
> {% block content %}
> {% for news_item in news %}
> {{ news_item.title }}
> {{ news_item.subtitle }}
> {% endfor %}
> {% endblock %}
>
> 2. base.html
>
>  http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
> http://www.w3.org/1999/xhtml; lang="{{
> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
> %}>
> 
> {% block title %}{% endblock %}
> 
> 
> {% block content %}{% endblock %}
> 
> 
>
> 3. inc.news.title.html
> News
>
> With this command I preproces every template of a settings variable and I
> get something like this:
>
> news.unify.html
>
>  http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
> http://www.w3.org/1999/xhtml; lang="{{
> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
> %}>
> 
> News
> 
> 
> {% for news_item in news %}
> {{ news_item.title }}
> {{ news_item.subtitle }}
> {% endfor %}
> 
> 
>
> So I have a two improves:
>
>1. It is more fast. And in a real project a view can render easyly 50
>templates
>2. I use news.html to develop and news.unify.html to production. So I
>don't lose legilibility.
>
>
> What do you think about "unify templates feature"? Do you know if exists a
> similar public project in github/gitlab/bitbucket etc?
>
>
> Best,
>
> --
> Pablo Martín Cobos
> Computer engineer
> Python/Django developer
> 652 53 37 36
> goi...@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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CALNyWLGNcuK8DTnU9w9fyGFhFfT3dAz7vfj3B%2BnDHWTfneLNFw%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMsYeuFV3EV_3H%2BR0q9xi5Q6EQq6L2cLkatcvrTtSYW%3D2zRk7A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Potential suspension of Channels development

2019-01-17 Thread Michael Martinez

Hi Andrew, 

We have a pretty active Django channel in our Slack group if you would like 
to direct all support requests there in the meantime. Many of us including 
myself are using Django Channels in production can help with basic support 
questions.

Take care of yourself and thanks for everything you've already done!

https://pyslackers.com/


On Thursday, January 17, 2019 at 12:07:06 PM UTC-6, Andrew Godwin wrote:
>
> Hi all,
>
> I'm writing to you all to update you on the current situation of Channels 
> and related libraries (channels-redis and Daphne) and potentially ask for 
> help.
>
> I've been the sole maintainer of these projects for quite a while and it 
> has become unsustainable - all of my energy is taken up fielding issues and 
> support requests and I haven't been able to even get myself to start 
> looking at Django async stuff because of it.
>
> Given that, if nobody else can step forward to take over, I'll have to put 
> those three projects (Channels, channels-redis, and Daphne) into an 
> explicit maintenance mode where they only accept security requests via the 
> normal security@ route, and start the process of retiring them as active 
> Django projects, as I don't want to give the impression they're still 
> maintained if they're not.
>
> (note: the asgiref project is still fine and should probably move out of 
> Django to its own effort at some point giving the growing set of ASGI tools)
>
> If people are willing to take over maintenance, I'm happy to help explain 
> some things but I don't have the bandwidth to bring someone completely up 
> from scratch, so I can't help mentor someone who is totally new to 
> maintaining open-source Python (sorry!).
>
> Once I recover a bit from the burnout I'll be able to come back and help 
> with the really complex bugs; the main thing I need out of is the seemingly 
> endless support requests and weird WebSocket client bugs.
>
> My personal deadline for this is two weeks, on February 1st. If you want 
> to help out, please feel free to reply either here or get in touch with me 
> personally to chat about what's involved.
>
> Andrew
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c14ad575-d72f-4e0e-910c-60afea1b7d4c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Potential suspension of Channels development

2019-01-17 Thread sibasish mohanty

Hi ,
I also can help in maintaining the projects.

On Thu, 17 Jan 2019, 11:40 p.m. Nasir Hussain  Hi andrew, I can help in maintaining the projects. Kindly let me know what
> are the next steps.
>
> Thanks
>
> On Thu, Jan 17, 2019, 11:07 PM Andrew Godwin 
>> Hi all,
>>
>> I'm writing to you all to update you on the current situation of Channels
>> and related libraries (channels-redis and Daphne) and potentially ask for
>> help.
>>
>> I've been the sole maintainer of these projects for quite a while and it
>> has become unsustainable - all of my energy is taken up fielding issues and
>> support requests and I haven't been able to even get myself to start
>> looking at Django async stuff because of it.
>>
>> Given that, if nobody else can step forward to take over, I'll have to
>> put those three projects (Channels, channels-redis, and Daphne) into an
>> explicit maintenance mode where they only accept security requests via the
>> normal security@ route, and start the process of retiring them as active
>> Django projects, as I don't want to give the impression they're still
>> maintained if they're not.
>>
>> (note: the asgiref project is still fine and should probably move out of
>> Django to its own effort at some point giving the growing set of ASGI tools)
>>
>> If people are willing to take over maintenance, I'm happy to help explain
>> some things but I don't have the bandwidth to bring someone completely up
>> from scratch, so I can't help mentor someone who is totally new to
>> maintaining open-source Python (sorry!).
>>
>> Once I recover a bit from the burnout I'll be able to come back and help
>> with the really complex bugs; the main thing I need out of is the seemingly
>> endless support requests and weird WebSocket client bugs.
>>
>> My personal deadline for this is two weeks, on February 1st. If you want
>> to help out, please feel free to reply either here or get in touch with me
>> personally to chat about what's involved.
>>
>> Andrew
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CAFwN1uonedcUeLz8zD%2BK5Ma82gLyAX8g0s58HeT%3Dq-dMgcLxfw%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAB5Hk3yC0MnbJwh%2BMQ63%2BdXha9pnBo6zL_kp2n5wNd8oqkT1UQ%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAPtOTErnQtCZ7s2qm--ZewNzgPvgCkg5i%3DdmGAdLCJKvHFFj7Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Potential suspension of Channels development

2019-01-17 Thread Andrew Godwin

Hi Nasir,

I'm looking for help from people with a strong history of open source
maintenance and Django/Python/async contributions, since I can't really
guide people through it and I need to be able to trust those who I give
access to. If you think you meet that, email me personally and I'll outline
what's needed.

Andrew

On Thu, Jan 17, 2019 at 10:10 AM Nasir Hussain 
wrote:

> Hi andrew, I can help in maintaining the projects. Kindly let me know what
> are the next steps.
>
> Thanks
>
> On Thu, Jan 17, 2019, 11:07 PM Andrew Godwin 
>> Hi all,
>>
>> I'm writing to you all to update you on the current situation of Channels
>> and related libraries (channels-redis and Daphne) and potentially ask for
>> help.
>>
>> I've been the sole maintainer of these projects for quite a while and it
>> has become unsustainable - all of my energy is taken up fielding issues and
>> support requests and I haven't been able to even get myself to start
>> looking at Django async stuff because of it.
>>
>> Given that, if nobody else can step forward to take over, I'll have to
>> put those three projects (Channels, channels-redis, and Daphne) into an
>> explicit maintenance mode where they only accept security requests via the
>> normal security@ route, and start the process of retiring them as active
>> Django projects, as I don't want to give the impression they're still
>> maintained if they're not.
>>
>> (note: the asgiref project is still fine and should probably move out of
>> Django to its own effort at some point giving the growing set of ASGI tools)
>>
>> If people are willing to take over maintenance, I'm happy to help explain
>> some things but I don't have the bandwidth to bring someone completely up
>> from scratch, so I can't help mentor someone who is totally new to
>> maintaining open-source Python (sorry!).
>>
>> Once I recover a bit from the burnout I'll be able to come back and help
>> with the really complex bugs; the main thing I need out of is the seemingly
>> endless support requests and weird WebSocket client bugs.
>>
>> My personal deadline for this is two weeks, on February 1st. If you want
>> to help out, please feel free to reply either here or get in touch with me
>> personally to chat about what's involved.
>>
>> Andrew
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/CAFwN1uonedcUeLz8zD%2BK5Ma82gLyAX8g0s58HeT%3Dq-dMgcLxfw%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAB5Hk3yC0MnbJwh%2BMQ63%2BdXha9pnBo6zL_kp2n5wNd8oqkT1UQ%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFwN1uoSvEVhffSH2sznNSpXfaraeq8eW9aPDjJkA%3D6rP-5JwQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Potential suspension of Channels development

2019-01-17 Thread Nasir Hussain

Hi andrew, I can help in maintaining the projects. Kindly let me know what
are the next steps.

Thanks

On Thu, Jan 17, 2019, 11:07 PM Andrew Godwin  Hi all,
>
> I'm writing to you all to update you on the current situation of Channels
> and related libraries (channels-redis and Daphne) and potentially ask for
> help.
>
> I've been the sole maintainer of these projects for quite a while and it
> has become unsustainable - all of my energy is taken up fielding issues and
> support requests and I haven't been able to even get myself to start
> looking at Django async stuff because of it.
>
> Given that, if nobody else can step forward to take over, I'll have to put
> those three projects (Channels, channels-redis, and Daphne) into an
> explicit maintenance mode where they only accept security requests via the
> normal security@ route, and start the process of retiring them as active
> Django projects, as I don't want to give the impression they're still
> maintained if they're not.
>
> (note: the asgiref project is still fine and should probably move out of
> Django to its own effort at some point giving the growing set of ASGI tools)
>
> If people are willing to take over maintenance, I'm happy to help explain
> some things but I don't have the bandwidth to bring someone completely up
> from scratch, so I can't help mentor someone who is totally new to
> maintaining open-source Python (sorry!).
>
> Once I recover a bit from the burnout I'll be able to come back and help
> with the really complex bugs; the main thing I need out of is the seemingly
> endless support requests and weird WebSocket client bugs.
>
> My personal deadline for this is two weeks, on February 1st. If you want
> to help out, please feel free to reply either here or get in touch with me
> personally to chat about what's involved.
>
> Andrew
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAFwN1uonedcUeLz8zD%2BK5Ma82gLyAX8g0s58HeT%3Dq-dMgcLxfw%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAB5Hk3yC0MnbJwh%2BMQ63%2BdXha9pnBo6zL_kp2n5wNd8oqkT1UQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Potential suspension of Channels development

2019-01-17 Thread Andrew Godwin

Hi all,

I'm writing to you all to update you on the current situation of Channels
and related libraries (channels-redis and Daphne) and potentially ask for
help.

I've been the sole maintainer of these projects for quite a while and it
has become unsustainable - all of my energy is taken up fielding issues and
support requests and I haven't been able to even get myself to start
looking at Django async stuff because of it.

Given that, if nobody else can step forward to take over, I'll have to put
those three projects (Channels, channels-redis, and Daphne) into an
explicit maintenance mode where they only accept security requests via the
normal security@ route, and start the process of retiring them as active
Django projects, as I don't want to give the impression they're still
maintained if they're not.

(note: the asgiref project is still fine and should probably move out of
Django to its own effort at some point giving the growing set of ASGI tools)

If people are willing to take over maintenance, I'm happy to help explain
some things but I don't have the bandwidth to bring someone completely up
from scratch, so I can't help mentor someone who is totally new to
maintaining open-source Python (sorry!).

Once I recover a bit from the burnout I'll be able to come back and help
with the really complex bugs; the main thing I need out of is the seemingly
endless support requests and weird WebSocket client bugs.

My personal deadline for this is two weeks, on February 1st. If you want to
help out, please feel free to reply either here or get in touch with me
personally to chat about what's involved.

Andrew

--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAFwN1uonedcUeLz8zD%2BK5Ma82gLyAX8g0s58HeT%3Dq-dMgcLxfw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: What do you think about unify templates feature?

2019-01-17 Thread Maciek Olko

Did you try to measure the difference in time of rendering standard and
your way?

Regards,
Maciej

czw., 17.01.2019, 10:02 użytkownik J. Pablo Martín Cobos 
napisał:

> Hi,
>
> From one year ago, I am using an own command for Django templates that
> unify them. With an example it is easy to see. If I am to render for
> example a template call news.html like it:
>
> 1. news.html
>
> {% extends "base.html" %}
>
> {% block title %}
> {% include "inc.news.title.html" %}
> {% endblock %}
>
> {% block content %}
> {% for news_item in news %}
> {{ news_item.title }}
> {{ news_item.subtitle }}
> {% endfor %}
> {% endblock %}
>
> 2. base.html
>
>  http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
> http://www.w3.org/1999/xhtml; lang="{{
> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
> %}>
> 
> {% block title %}{% endblock %}
> 
> 
> {% block content %}{% endblock %}
> 
> 
>
> 3. inc.news.title.html
> News
>
> With this command I preproces every template of a settings variable and I
> get something like this:
>
> news.unify.html
>
>  http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
> http://www.w3.org/1999/xhtml; lang="{{
> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
> %}>
> 
> News
> 
> 
> {% for news_item in news %}
> {{ news_item.title }}
> {{ news_item.subtitle }}
> {% endfor %}
> 
> 
>
> So I have a two improves:
>
>1. It is more fast. And in a real project a view can render easyly 50
>templates
>2. I use news.html to develop and news.unify.html to production. So I
>don't lose legilibility.
>
>
> What do you think about "unify templates feature"? Do you know if exists a
> similar public project in github/gitlab/bitbucket etc?
>
>
> Best,
>
> --
> Pablo Martín Cobos
> Computer engineer
> Python/Django developer
> 652 53 37 36
> goi...@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 post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CALNyWLGNcuK8DTnU9w9fyGFhFfT3dAz7vfj3B%2BnDHWTfneLNFw%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALYYG805GZFJL5b_9nortw8Sj%2Bkrx1p4xqki7C96Zd8vHeYsmw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

2019-01-17 Thread Santiago Basulto

Ok, sorry for the Fake News, seems like it's not so complicated to make one 
ModelAdmin parent class that provides this behavior. Here's a working 
example:


from django.contrib import admin

from django.contrib.admin import widgets


class RawFieldModelAdmin(admin.ModelAdmin):
def formfield_for_foreignkey(self, db_field, request, **kwargs):
db = kwargs.get('using')
if 'widget' not in kwargs:
if db_field.name not in (self.get_autocomplete_fields(request), 
self.radio_fields):
kwargs['widget'] = widgets.ForeignKeyRawIdWidget(db_field.
remote_field, self.admin_site, using=db)


return super().formfield_for_foreignkey(db_field, request, **kwargs)

Do you folks think we should add this to the docs? I still think that 
having a one-off setting for the "default foreign key" widget would be 
valuable, at least for me as a user.

What do you think?

On Thursday, January 17, 2019 at 11:27:12 AM UTC-5, Santiago Basulto wrote:
>
> I think the proposed solution of "you can just extend/subclass ModelAdmin" 
> doesn't work, because the fields on different models can have different 
> names. I can't just write one global ModelAdmin and then use it for all my 
> models, because they'll have different names for their fields. Or if it 
> works, it'll need A LOT of introspection (to dynamically check which fields 
> are FKs and making them part of raw_id_fields).
>
> Maybe I'm wrong and I'm missing the point, do you folks have an 
> implementation of that ModelAdmin superclass to show?
>
> On Thursday, January 17, 2019 at 11:00:42 AM UTC-5, Carlton Gibson wrote:
>>
>>
>>
>> On Thursday, 17 January 2019 16:14:31 UTC+1, Collin Anderson wrote:
>>>
>>> One problem with any of the alternatives (besides making it readonly by 
>>> default) is that it requires the other model to be registered in the admin
>>>
>>
>> Off-hand I don't follow you here. Can you explain. 
>>
>>  
>>
>>> I hope there's _something_ we can do to somehow improve the situation. 
>>> Maybe we could at least improve the examples in the documentation? Maybe 
>>> give an example in the docs of a ModelAdmin subclass that defaults to using 
>>> raw_id?
>>>
>>
>> An example definitely.
>>
>> Maybe we could add an attribute to ModelAdmin with a number: More than 
>> this use raw_id — but what would that look like? 
>> (Easy subclass rather than a setting...)
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4144aaca-34b8-4960-8f70-7a37f745c970%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

2019-01-17 Thread Santiago Basulto

I think the proposed solution of "you can just extend/subclass ModelAdmin" 
doesn't work, because the fields on different models can have different 
names. I can't just write one global ModelAdmin and then use it for all my 
models, because they'll have different names for their fields. Or if it 
works, it'll need A LOT of introspection (to dynamically check which fields 
are FKs and making them part of raw_id_fields).

Maybe I'm wrong and I'm missing the point, do you folks have an 
implementation of that ModelAdmin superclass to show?

On Thursday, January 17, 2019 at 11:00:42 AM UTC-5, Carlton Gibson wrote:
>
>
>
> On Thursday, 17 January 2019 16:14:31 UTC+1, Collin Anderson wrote:
>>
>> One problem with any of the alternatives (besides making it readonly by 
>> default) is that it requires the other model to be registered in the admin
>>
>
> Off-hand I don't follow you here. Can you explain. 
>
>  
>
>> I hope there's _something_ we can do to somehow improve the situation. 
>> Maybe we could at least improve the examples in the documentation? Maybe 
>> give an example in the docs of a ModelAdmin subclass that defaults to using 
>> raw_id?
>>
>
> An example definitely.
>
> Maybe we could add an attribute to ModelAdmin with a number: More than 
> this use raw_id — but what would that look like? 
> (Easy subclass rather than a setting...)
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c6df6501-dd30-4087-b344-129582bff824%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

2019-01-17 Thread Carlton Gibson



On Thursday, 17 January 2019 16:14:31 UTC+1, Collin Anderson wrote:
>
> One problem with any of the alternatives (besides making it readonly by 
> default) is that it requires the other model to be registered in the admin
>

Off-hand I don't follow you here. Can you explain. 

 

> I hope there's _something_ we can do to somehow improve the situation. 
> Maybe we could at least improve the examples in the documentation? Maybe 
> give an example in the docs of a ModelAdmin subclass that defaults to using 
> raw_id?
>

An example definitely.

Maybe we could add an attribute to ModelAdmin with a number: More than this 
use raw_id — but what would that look like? 
(Easy subclass rather than a setting...)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/59493dc3-881e-4728-9f9d-d816195ac803%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Django 2.2 alpha 1 released

2019-01-17 Thread Carlton Gibson

We've made the first release on the way to Django's next major 
release, Django 2.2! 

With about two and a half months until the 
final release (scheduled for April 1), we'll need timely testing 
from the community to ensure an on time, stable release. 

Check out the blog post: 

https://www.djangoproject.com/weblog/2019/jan/17/django-22-alpha-1/ 



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5C485FB6-0204-4A29-B733-A8ED3C3D5A4B%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

2019-01-17 Thread Collin Anderson

I agree that default load-all-options is an annoying default. I just ran
into this problem again myself in the last few weeks. One problem with any
of the alternatives (besides making it readonly by default) is that it
requires the other model to be registered in the admin, which could be also
be annoying for some people.

I hope there's _something_ we can do to somehow improve the situation.
Maybe we could at least improve the examples in the documentation? Maybe
give an example in the docs of a ModelAdmin subclass that defaults to using
raw_id?

On Thu, Jan 17, 2019 at 7:55 AM Carlton Gibson 
wrote:

> This topic has come up before.
>
> e.g.
> https://groups.google.com/d/topic/django-developers/md39xtT_JEM/discussion
>
>
> (In which Aymeric suggests something similar to Harro's suggestion here.)
>
> On Thursday, 17 January 2019 06:32:15 UTC+1, Harro wrote:
>
>> If you want it in your whole project you could just extend the ModelAdmin
>> and make the raw_id_fields a property that returns all the fields then use
>> that as a base class for all your ModelAdmins,
>> looking at the code the check if it is a foreignkey happens before that
>> in all cases, so having non foreignkey fields in the list shouldn't matter.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/2ba44b9f-6526-4a6a-8311-632e83aeb4ba%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFO84S7zSQUCTgzQn_J2fuJwN54LdMqDhirCU7tp%2BL2odHAoPg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

2019-01-17 Thread ludovic coues

Django's admin default widget for foreign keys is a select. If you try to
populate a select elements with 20,000 options, your page take at least a
few seconds to load. Probably a minute or two, if it load at all.

By configuring your model admin to display the foreign key as a
raw_id_fields, you get an simple input instead of a select. It's less nice
to use but it's much faster.

On Thu, Jan 17, 2019, 13:48 shiva kumar  actually i am new to django i am not able to understand the problem which
> ur dealing with?
>
> On Thu, Jan 17, 2019 at 3:33 AM Santiago Basulto <
> santiago.basu...@gmail.com> wrote:
>
>> Hey folks, I was about to submit a ticket but i thought it might be
>> better to ask everybody for opinions on the matter first. I am running a
>> couple of medium (not even large) Django websites (around +20K users) and
>> we rely on the admin heavily. We have multiple models pointing to Users (or
>> other derived models) and every time we create a new model, we MUST
>> remember to include User in `raw_id_fields` for that model. If we forget to
>> do so, the whole testing site crashes when the whole `SELECT * FROM User`
>> query is run.
>>
>> To add to the problem, some derived models (for example Customer) include
>> in their `__str__` both the User + something else. Think about the model
>> Customer in this way:
>>
>> class Customer(models.Model):
>> user = models.ForeignKey(User)
>> plan = models.ForeignKey(Plan)
>>
>>
>> def __str__(self):
>> return f"{self.user} - {self.plan}"
>>
>>
>> (Not a real example, but to make the point)
>>
>> Imagine any other model with an FK to Customer, an `Inquiry`, for
>> example. If you open the `Inquiry` add/change page on the admin, the whole
>> thing will blow up.
>>
>> I know the related select field is an amazing feature, and looks slick on
>> the admin when starting a new Django projects (specially for beginners),
>> but it just doesn't scale for large websites.
>>
>> *My proposal*
>>
>> I think just a project-wide setting `settings.ADMIN_DEFAULT_FK_WIDGET =
>> [raw|select]` would work and help us (running a medium/large site) a lot.
>>
>> What do you think?
>>
>> Thanks for all the support, this community rocks 落!
>>
>> PS: I can create a ticket if that's a better medium of discussion, just
>> let me know?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-developers+unsubscr...@googlegroups.com.
>> To post to this group, send email to django-developers@googlegroups.com.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/5dae8b31-356c-45f3-b707-83b5ef33f396%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMsYeuFUNE3W8Cc2RGwn7L-LZ%2BhrNy9NPxiYVx_ZH7H4kUzR0Q%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAEuG%2BTaajgmBC37fjiHfSXJNOFvTmU%2B29Cz-G-zbLMsiuN3yyQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

2019-01-17 Thread Carlton Gibson

This topic has come up before. 

e.g. https://groups.google.com/d/topic/django-developers/md39xtT_JEM/discussion 

(In which Aymeric suggests something similar to Harro's suggestion here.) 

On Thursday, 17 January 2019 06:32:15 UTC+1, Harro wrote:

> If you want it in your whole project you could just extend the ModelAdmin 
> and make the raw_id_fields a property that returns all the fields then use 
> that as a base class for all your ModelAdmins, 
> looking at the code the check if it is a foreignkey happens before that in 
> all cases, so having non foreignkey fields in the list shouldn't matter.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2ba44b9f-6526-4a6a-8311-632e83aeb4ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

2019-01-17 Thread shiva kumar

actually i am new to django i am not able to understand the problem which
ur dealing with?

On Thu, Jan 17, 2019 at 3:33 AM Santiago Basulto 
wrote:

> Hey folks, I was about to submit a ticket but i thought it might be better
> to ask everybody for opinions on the matter first. I am running a couple of
> medium (not even large) Django websites (around +20K users) and we rely on
> the admin heavily. We have multiple models pointing to Users (or other
> derived models) and every time we create a new model, we MUST remember to
> include User in `raw_id_fields` for that model. If we forget to do so, the
> whole testing site crashes when the whole `SELECT * FROM User` query is run.
>
> To add to the problem, some derived models (for example Customer) include
> in their `__str__` both the User + something else. Think about the model
> Customer in this way:
>
> class Customer(models.Model):
> user = models.ForeignKey(User)
> plan = models.ForeignKey(Plan)
>
>
> def __str__(self):
> return f"{self.user} - {self.plan}"
>
>
> (Not a real example, but to make the point)
>
> Imagine any other model with an FK to Customer, an `Inquiry`, for example.
> If you open the `Inquiry` add/change page on the admin, the whole thing
> will blow up.
>
> I know the related select field is an amazing feature, and looks slick on
> the admin when starting a new Django projects (specially for beginners),
> but it just doesn't scale for large websites.
>
> *My proposal*
>
> I think just a project-wide setting `settings.ADMIN_DEFAULT_FK_WIDGET =
> [raw|select]` would work and help us (running a medium/large site) a lot.
>
> What do you think?
>
> Thanks for all the support, this community rocks 落!
>
> PS: I can create a ticket if that's a better medium of discussion, just
> let me know?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/5dae8b31-356c-45f3-b707-83b5ef33f396%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMsYeuFUNE3W8Cc2RGwn7L-LZ%2BhrNy9NPxiYVx_ZH7H4kUzR0Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

What do you think about unify templates feature?

2019-01-17 Thread J . Pablo Martín Cobos

Hi,

>From one year ago, I am using an own command for Django templates that
unify them. With an example it is easy to see. If I am to render for
example a template call news.html like it:

1. news.html

{% extends "base.html" %}

{% block title %}
{% include "inc.news.title.html" %}
{% endblock %}

{% block content %}
{% for news_item in news %}
{{ news_item.title }}
{{ news_item.subtitle }}
{% endfor %}
{% endblock %}

2. base.html

http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
http://www.w3.org/1999/xhtml; lang="{{
LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
%}>

{% block title %}{% endblock %}


{% block content %}{% endblock %}



3. inc.news.title.html
News

With this command I preproces every template of a settings variable and I
get something like this:

news.unify.html

http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
http://www.w3.org/1999/xhtml; lang="{{
LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
%}>

News


{% for news_item in news %}
{{ news_item.title }}
{{ news_item.subtitle }}
{% endfor %}



So I have a two improves:

   1. It is more fast. And in a real project a view can render easyly 50
   templates
   2. I use news.html to develop and news.unify.html to production. So I
   don't lose legilibility.


What do you think about "unify templates feature"? Do you know if exists a
similar public project in github/gitlab/bitbucket etc?


Best,

-- 
Pablo Martín Cobos
Computer engineer
Python/Django developer
652 53 37 36
goi...@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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALNyWLGNcuK8DTnU9w9fyGFhFfT3dAz7vfj3B%2BnDHWTfneLNFw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: What do you think about unify templates feature?

Re: Potential suspension of Channels development

Re: Potential suspension of Channels development

Re: Potential suspension of Channels development

Re: Potential suspension of Channels development

Potential suspension of Channels development

Re: What do you think about unify templates feature?

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

Django 2.2 alpha 1 released

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

Re: [Looking for feedback] Make Admin raw_id_fields the default choice for FKs, or project-wide configurable

What do you think about unify templates feature?

16 matches

Site Navigation

Mail list logo

Footer information