Re: Feature: Support Server-Sent Events

[Javier Guerra Giraldez]

On Sat, May 30, 2015 at 4:19 PM, Florian Apolloner
 wrote:
> ie how would it use Django's current featureset which is basically blocking
> everywhere…

On Sat, May 30, 2015 at 4:40 PM, Emil Stenström  wrote:
> The separate process would have none of Django's features, it would just be
> a way to send messages to connected clients.


take a look on how it's done with uWSGI: [1].  Basically, the http
request arrives to a Django view in the normal way; then it generates
a response with a custom header, which the uWSGI system recognizes
(much like X-Sendfile), and routes the request to a gevent-based wsgi
app that uses an sse package (probably [2]) to keep the connection.

in the given example, there's no further communication between Django
and the SSE process, but the author then comments it could be done
either with the uWSGI caching framework, or via Redis.

If I were to implement this today (and in fact, i have an application
that might need this in the near future), i would use basically this
scheme (as I'm using uWSGI for all my deployments), and Redis.  The
SSE process would keep in Redis the current set of connected users,
and the Django process would send messages via Redis to the SSE
process.  Of course, not only 'broadcast' messages to every connected
user, but user-specific messages too.

I don't see how would i do it for a reusable app, since it looks most
of the code would run 'outside' Django.  Doing it for the Django core
seems even more problematic, since it would also have to be much more
flexible in requirements, both for the WSGI container (does mod_wsgi
support async python code?  i guess gunicorn does), and also for the
communications between the 'main' Django views and the SSE part.
(probably the cache API would be appropriate)



[1]: 
https://uwsgi-docs.readthedocs.org/en/latest/articles/OffloadingWebsocketsAndSSE.html
[2]: https://github.com/niwinz/sse

-- 
Javier

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAFkDaoSSZGZcPsNEomS5%2BPnSAVP6LLmbEcSO5Epu01t6UsxKXg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Fellow Report - May 30, 2015

[Tim Graham]

Report for week ending May 30, 2015:

Triaged

---

https://code.djangoproject.com/ticket/24850 - Squashed migration not 
recognized as an initial migration (duplicate)

https://code.djangoproject.com/ticket/24851 - Regression in reverse 
one-to-one field in list_display (accepted)

https://code.djangoproject.com/ticket/13223 - ValueError with inline and 
save as new (duplicate)

https://code.djangoproject.com/ticket/24283 - ModelAdmin.media does not use 
get_prepopulated_fields (duplicate)

https://code.djangoproject.com/ticket/19431 - Prepopulate modeladmin forms 
datetime fields using querystrings (duplicate)

https://code.djangoproject.com/ticket/24849 - Broken squashmigration when 
model related to another one gets deleted (accepted)

https://code.djangoproject.com/ticket/17417 - "Save as new" does not work 
when a ValidationError is raised (duplicate)

https://code.djangoproject.com/ticket/15935 - Allow django admin filter to 
be hidable (duplicate)

https://code.djangoproject.com/ticket/24856 - raw_id_fields popup missing 
(worksforme)

https://code.djangoproject.com/ticket/24864 - Django will not listen to 
same port on IPv4 and IPv6 at the same time (won’t fix)

https://code.djangoproject.com/ticket/24865 - Add a feature to 
programmatically remove stale content types (accepted)

https://code.djangoproject.com/ticket/24859 - UUIDField does not validate 
query value (accepted)

https://code.djangoproject.com/ticket/24858 - Add support for 
get_foo_display() with ArrayField (accepted)

https://code.djangoproject.com/ticket/24853 - FK value not inserted in 
database in data migration (won’t fix)

https://code.djangoproject.com/ticket/24867 - admin.E202 seems to include 
superclass references? (invalid)

https://code.djangoproject.com/ticket/24872 - dbshell don't read parameters 
correctly with sql_server.pyodbc (django-pyodbc-azure) (needsinfo)

https://code.djangoproject.com/ticket/24869 - Model unicode and Foreign key 
(needsinfo)

https://code.djangoproject.com/ticket/24860 - Migrations leak stale 
RelatedManager related_model definitions (needsinfo)

https://code.djangoproject.com/ticket/24873 - Error while using Prefech on 
more than two levels (accepted)

https://code.djangoproject.com/ticket/24874 - Why does "AbstractBaseUser" 
contain "password" and "last_login" fields? (invalid)

https://code.djangoproject.com/ticket/24876 - Skipping migrations checking 
in sql* commands (duplicate)

Authored



https://github.com/django/djangoproject.com/pull/475 - Fixed #459 -- Fixed 
ContactForm crash on empty name.

https://github.com/django/djangoproject.com/pull/476 - Fixed #457 -- Fixed 
docs search suggestions crash.

https://github.com/django/django/pull/4713 - Fixed #24836 -- Made 
force_text() resolve lazy objects.

https://github.com/django/django/pull/4717 - Fixed #24851 -- Fixed crash 
with reverse one-to-one relation in ModelAdmin.list_display

https://github.com/django/django/pull/4718 - Added contrib.auth migration 
for refs #13147.

Reviewed/committed

--

https://github.com/django/django/pull/4630 - Fixed #24773 -- Added a json() 
method on test client responses.

https://github.com/django/django/pull/4695 - Fixed #24841 -- Made 
BaseRangeField.prepare_value() call base_field's prepare_value()

https://github.com/django/django/pull/4708 - Fixed #24848 -- Fixed 
ValueError for faulty migrations module.

https://github.com/django/django/pull/4707 - Fixed #24788 -- Allowed Forms 
to specify a prefix at the class level.

https://github.com/django/django/pull/4706 - Fixed #24835 -- exists() 
incorrect after annotation with Count()

https://github.com/django/django/pull/4712 - Fixed #24847 -- Items set on a 
RequestContext after creation get lost

https://github.com/django/django/pull/4715 - Fixed #24817 -- Prevented loss 
of null info in MySQL field renaming.

https://github.com/django/django/pull/4665 - Fixed #24732 -- Reordered 
tutorial to cover basics before bells and whistles.

https://github.com/django/django/pull/4530 - Refs #23643 -- Fixed debug 
view regression on Python 2.

https://github.com/django/django/pull/4703 - Fixed #24846 -- Added support 
to MySQL SchemaEditor for all blob/text data types

Reviews of core dev work


https://github.com/django/django/pull/4699 - Fixed #24699 -- Added 
aggregate support for DurationField on Oracle

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/84a76aab-d211-4841-b772-0b639bdb6ff0%40googlegroups.com.
For more options, visit 

Re: Fate of sql* management commands

[Tim Graham]

They were dropped as part of the removal of the old code that supported 
syncing apps without migrations.

https://github.com/django/django/commit/7e8cf74dc74539f40f4cea53c1e8bba82791fcb6

You could probably reimplement them at least to some extent using the new 
schema backends. By the way, I suspect this could be implemented as a 
third-party app if there is opposition to including it in Django itself. 

On Saturday, May 30, 2015 at 6:39:41 PM UTC-4, Marcin Nowak wrote:
>
> Tim,
>
> I've just realised that there is no sql* commands in the newest Django.
> Generating SQL from models was very useful. Why do you decided to drop 
> that functionality? Because of builit-in migrations? 
> Can you just bring them back? 
>
> Thanks.
> Marcin.
>
>
> On Friday, May 29, 2015 at 7:26:26 PM UTC+2, Marcin Nowak wrote:
>>
>> Thanks, I didn't saw it.
>>
>> But I've found quick ad-hoc solution using monkey patching.
>> Just include this snippet in project`s __init__:
>>
>> from django.core.management import sql
>>
>> def check_for_migrations_bypassed(*args, **kw):
>> pass
>>
>> sql.check_for_migrations = check_for_migration_bypassed
>>
>> (Tested with v1.8)
>>
>> /BR
>> Marcin
>>
>> On Friday, May 29, 2015 at 6:38:11 PM UTC+2, Tim Graham wrote:
>>>
>>> There's a ticket waiting someone to implement what has been discussed:
>>>
>>> https://code.djangoproject.com/ticket/24481
>>>
>>> On Friday, May 29, 2015 at 12:05:48 PM UTC-4, Marcin Nowak wrote:



 On Monday, March 30, 2015 at 1:58:02 AM UTC+2, Russell Keith-Magee 
 wrote:
>
>
>>
>> *What is the new way to dump the sql schema of currently installed 
>> django appz ?* It'd maybe be worth that I provide a doc patch to 
>> inform users about it.
>> *If there is none, is there an agreement to restore at least sqlall 
>> and sqlclear ?*
>>
>  
> No, there isn't :-)
>

 We need old sql /sqlall behaviour. Currently we can't generate sql for 
 contrib apps. 
 Calling `sql auth` raises error:

 CommandError: App 'auth' has migrations. Only the sqlmigrate and 
 sqlflush commands can be used when an app has migrations.

 We're expecting SQL output instead.

 *We need to bypass migration mechanism for some specific projects*. 
 Please make life easier but not harder. Django is unusable from v1.7 
 for some of us! 

 Or please give us hint how to achieve old behaviour.

 /BR
 Marcin

>>>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/df2a7451-1f9f-4dd8-b124-2f5193f687c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fate of sql* management commands

[Marcin Nowak]

Tim,

I've just realised that there is no sql* commands in the newest Django.
Generating SQL from models was very useful. Why do you decided to drop that 
functionality? Because of builit-in migrations? 
Can you just bring them back? 

Thanks.
Marcin.


On Friday, May 29, 2015 at 7:26:26 PM UTC+2, Marcin Nowak wrote:
>
> Thanks, I didn't saw it.
>
> But I've found quick ad-hoc solution using monkey patching.
> Just include this snippet in project`s __init__:
>
> from django.core.management import sql
>
> def check_for_migrations_bypassed(*args, **kw):
> pass
>
> sql.check_for_migrations = check_for_migration_bypassed
>
> (Tested with v1.8)
>
> /BR
> Marcin
>
> On Friday, May 29, 2015 at 6:38:11 PM UTC+2, Tim Graham wrote:
>>
>> There's a ticket waiting someone to implement what has been discussed:
>>
>> https://code.djangoproject.com/ticket/24481
>>
>> On Friday, May 29, 2015 at 12:05:48 PM UTC-4, Marcin Nowak wrote:
>>>
>>>
>>>
>>> On Monday, March 30, 2015 at 1:58:02 AM UTC+2, Russell Keith-Magee wrote:


>
> *What is the new way to dump the sql schema of currently installed 
> django appz ?* It'd maybe be worth that I provide a doc patch to 
> inform users about it.
> *If there is none, is there an agreement to restore at least sqlall 
> and sqlclear ?*
>
  
 No, there isn't :-)

>>>
>>> We need old sql /sqlall behaviour. Currently we can't generate sql for 
>>> contrib apps. 
>>> Calling `sql auth` raises error:
>>>
>>> CommandError: App 'auth' has migrations. Only the sqlmigrate and 
>>> sqlflush commands can be used when an app has migrations.
>>>
>>> We're expecting SQL output instead.
>>>
>>> *We need to bypass migration mechanism for some specific projects*. 
>>> Please make life easier but not harder. Django is unusable from v1.7 for 
>>> some of us! 
>>>
>>> Or please give us hint how to achieve old behaviour.
>>>
>>> /BR
>>> Marcin
>>>
>>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ee82af74-ee72-4dbc-aa21-79070bcc4f79%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature request - models.TextInAParagraphField

[Marc Tamlyn]

Hi Reiner.

You'll get answers to questions like this on the django-users email list, <
django-developers@googlegroups.com> - the web interface is <
https://groups.google.com/forum/#!forum/django-users>.

The list you've posted to is django-developers, which is for the discussion
of the development of Django itself.

You might also find the #django IRC channel on irc.freenode.net helpful.

As a start point, you may also wish to read the docs for help_text
.

Marc

On 30 May 2015 at 23:06,  wrote:

> Hello,
>
> It would be very helpful to create forms in the model only. The thing I
> miss
> is a simple text in the model that would appear in the output form exactly
> on the position from the model as text e.g. in a Paragraph.
>
> I fail to do it myself from documentation.
>
> Example :
>
> in models.py
>
> class Example(models.Model):
> Name   =
> models.CharField(max_length=100,blank=True,null=True)
> # Now a field that needs no DB representation
> Question_TIW =
> models.TextInAParagraphField(verbose_name='Some informational Text')
> # or assign verbose_name later in view
> Ans1_OKH   = models.BooleanField(default=False)
> Ans2_OKH   = models.BooleanField(default=False)
> Ans3_OKH   = models.BooleanField(default=False)
>
> in views.py
>
> class ExampleNew(MyCreateView):
> # I use model based views only
> # Here Labels get added and Texts for Information get added to the
> context
> #
> form_class = ExampleForm
>
> in forms.py
>
> class ExampleForm(BootstrapForm):
> # class based form
> # In BootstrapForm attributes are added to widgets and Tooltips get
> added for Popovers
> #
> Meta=BootstrapMeta(Example)
> #
> # In BootstrapMeta widgets and renderers get assigned / I use it
> this way
> # endswith '_OKH' is a horizontal SelectButton with Label to the
> right as DIV row
> # to endswith '_TIW' I would assign a new TextInWellRenderer :)
> #
>
> urls.py
>
> url(r'^example/$', ExampleNew.as_view(mymodel=Example),   name='example'),
>
> 
>
> So 6 lines of code per Form (maybe 4, as I use the same view for many
> models)
>  + One line each Field
>  + Generic code
>
> Result should be a Form
>
> with a Name input,
> followed by the text,
> followed by Select Buttons to click
> followed by a submit button
>
> /example
>
> I think that would make forms in Django a lot easier to use and more
> effective
> with less work to do.
>
> kind regards
> Reiner
>
> --
> 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/4d7640ff-c064-4db5-8d3c-50b2db10e142%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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1G40Hvjb4-ePn7shGM9OG6v0g647t7Q32njTHLxU25qEA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Feature request - models.TextInAParagraphField

[wigmbhmtl]

Hello,

It would be very helpful to create forms in the model only. The thing I miss
is a simple text in the model that would appear in the output form exactly
on the position from the model as text e.g. in a Paragraph.

I fail to do it myself from documentation.

Example :

in models.py

class Example(models.Model):
Name   = 
models.CharField(max_length=100,blank=True,null=True) 
# Now a field that needs no DB representation
Question_TIW = models.TextInAParagraphField(verbose_name='Some 
informational Text')
# or assign verbose_name later in view
Ans1_OKH   = models.BooleanField(default=False)
Ans2_OKH   = models.BooleanField(default=False)
Ans3_OKH   = models.BooleanField(default=False)

in views.py 

class ExampleNew(MyCreateView):
# I use model based views only
# Here Labels get added and Texts for Information get added to the 
context
#
form_class = ExampleForm

in forms.py

class ExampleForm(BootstrapForm):
# class based form
# In BootstrapForm attributes are added to widgets and Tooltips get 
added for Popovers
#
Meta=BootstrapMeta(Example)
#
# In BootstrapMeta widgets and renderers get assigned / I use it 
this way
# endswith '_OKH' is a horizontal SelectButton with Label to the 
right as DIV row
# to endswith '_TIW' I would assign a new TextInWellRenderer :)
#

urls.py 

url(r'^example/$', ExampleNew.as_view(mymodel=Example),   name='example'),



So 6 lines of code per Form (maybe 4, as I use the same view for many 
models)
 + One line each Field
 + Generic code

Result should be a Form 

with a Name input, 
followed by the text,
followed by Select Buttons to click
followed by a submit button

/example

I think that would make forms in Django a lot easier to use and more 
effective
with less work to do.

kind regards
Reiner

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4d7640ff-c064-4db5-8d3c-50b2db10e142%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Support Server-Sent Events

[Emil Stenström]

Hi,

The separate process would have none of Django's features, it would just be 
a way to send messages to connected clients. Here's an example of how it 
could work:

   - Client A and Client B connects to my site. Django serves the start 
   page as normal.
   - The start page serves up a javascript file that makes Client A and 
   Client B open a connection to the SSE process. The clients listen for 
   messages on that connection.
   - Client A clicks a button on the site, that sends an normal ajax 
   request to Django. In the view a message is passed from Django to the SSE 
   process.
   - The SSE process passes the message though the open connection to both 
   Client A and Client B who are connected.
   - In our own custom code we can decide what we want to do with the 
   message. Maybe just show it in a list somewhere.
   
So the SSE process is VERY simple. It just connects to clients and passes 
on messages the all clients connected. 

Does this make sense?

/E
On Saturday, 30 May 2015 23:19:25 UTC+2, Florian Apolloner wrote:
>
> Hi Emil, 
>
> while supporting server-sent events (or even websockets for that matter) 
> would be great, this is basically a problem which has to be tackled in WSGI 
> first in my opinion. That said, when you talk about a separate process, how 
> would it look like (aside from using asycio), ie how would it use Django's 
> current featureset which is basically blocking everywhere…
>
> Cheers,
> Florian
>
> On Saturday, May 30, 2015 at 5:52:36 PM UTC+1, Emil Stenström wrote:
>>
>> Hi, 
>>
>> This is the third feature proposal as part of my general drive for 
>> getting Django to work better for javascript heavy sites. 
>>
>> Support Server-Sent Events 
>> -- 
>>
>> If you want a snappy user experience, AJAX polling isn't enough. There 
>> are two major ways to get out of the request-response cycle. Namely: 
>> websockets and server-sent events. 
>>
>> Websockets are complicated beasts, and getting cross-browser support for 
>> them requires implementing several protocol versions. They are also 
>> bidirectional, meaning you can send stuff to the server with them. 
>>
>> Server-Sent Events use normal HTTP, and are natively supported 
>> everywhere except Internet Explorer. Since they don't use a custom 
>> protocol there are several polyfills that enable IE support too, 
>> bringing browser compliance close to 100%. SSE only supports sending 
>> data from server to client, not the other way around. 
>>
>> The ease of implementation for server-sent events makes it a much better 
>> Django fit in my opinion. Also, I don't think the need for client -> 
>> server requests is that big, you can easily solve that with AJAX calls 
>> instead. 
>>
>> More reading on how it works: 
>> http://www.html5rocks.com/en/tutorials/eventsource/basics/ 
>>
>> --- 
>>
>> Just like websockets, server-sent events rely on persistent connections 
>> to each connected client. This means that we need a separate process to 
>> make this work properly. I understand this is a controversial 
>> suggestion, but it allows the rest of Django to continue working like 
>> before, and still offer async support to users. It's the best of two 
>> worlds. 
>>
>> So how would you implement such a process in a performant way? With 
>> Python 3's asyncio package (for Python 2 support there's trollius: 
>> https://pypi.python.org/pypi/trollius). This means no external 
>> dependencies (except for old pythons). 
>>
>> You would start the process separately, add a script tag to your page, 
>> and all clients that connected to the page would be connected to the 
>> process. Now Django could push messages through that process as part of 
>> the request-response cycle, and all clients would be notified. Other 
>> processes (a cron job?) could do the same. 
>>
>> Simply stated: we would finally get async support in Django, without 
>> having to rewrite large parts of Django. Also, we need no persistent 
>> message storage. Connected clients get the messages, then it's discarded. 
>>
>> There is existing work on this that could be a starting point for a more 
>> Django:y API: https://github.com/brutasse/asyncio-sse 
>>
>> --- 
>>
>> I think server-sent events would be a great reason to choose Django over 
>> other frameworks. It would finally answer the request for "async" 
>> features in Django, with a system that's as easy to setup (just start 
>> the process) as to implement. 
>>
>> Would anyone we willing to work with me on this? Do you think it makes 
>> sense to put this in Django? I don't see any need for this code to 
>> change often, and it fits well with the "building apps quickly and with 
>> less code" mantra. 
>>
>> Thoughts? Ideas? 
>>
>> (And yes, this idea would work great together with the js template 
>> rendering. Pushing database updates from the server to the client, and 
>> they instantly updating the template accordingly) 
>>
>> Regards, 
>>
>> Emil Stenström 
>> Twitter: 

Re: Feature: Support Server-Sent Events

[Florian Apolloner]

Hi Emil, 

while supporting server-sent events (or even websockets for that matter) 
would be great, this is basically a problem which has to be tackled in WSGI 
first in my opinion. That said, when you talk about a separate process, how 
would it look like (aside from using asycio), ie how would it use Django's 
current featureset which is basically blocking everywhere…

Cheers,
Florian

On Saturday, May 30, 2015 at 5:52:36 PM UTC+1, Emil Stenström wrote:
>
> Hi, 
>
> This is the third feature proposal as part of my general drive for 
> getting Django to work better for javascript heavy sites. 
>
> Support Server-Sent Events 
> -- 
>
> If you want a snappy user experience, AJAX polling isn't enough. There 
> are two major ways to get out of the request-response cycle. Namely: 
> websockets and server-sent events. 
>
> Websockets are complicated beasts, and getting cross-browser support for 
> them requires implementing several protocol versions. They are also 
> bidirectional, meaning you can send stuff to the server with them. 
>
> Server-Sent Events use normal HTTP, and are natively supported 
> everywhere except Internet Explorer. Since they don't use a custom 
> protocol there are several polyfills that enable IE support too, 
> bringing browser compliance close to 100%. SSE only supports sending 
> data from server to client, not the other way around. 
>
> The ease of implementation for server-sent events makes it a much better 
> Django fit in my opinion. Also, I don't think the need for client -> 
> server requests is that big, you can easily solve that with AJAX calls 
> instead. 
>
> More reading on how it works: 
> http://www.html5rocks.com/en/tutorials/eventsource/basics/ 
>
> --- 
>
> Just like websockets, server-sent events rely on persistent connections 
> to each connected client. This means that we need a separate process to 
> make this work properly. I understand this is a controversial 
> suggestion, but it allows the rest of Django to continue working like 
> before, and still offer async support to users. It's the best of two 
> worlds. 
>
> So how would you implement such a process in a performant way? With 
> Python 3's asyncio package (for Python 2 support there's trollius: 
> https://pypi.python.org/pypi/trollius). This means no external 
> dependencies (except for old pythons). 
>
> You would start the process separately, add a script tag to your page, 
> and all clients that connected to the page would be connected to the 
> process. Now Django could push messages through that process as part of 
> the request-response cycle, and all clients would be notified. Other 
> processes (a cron job?) could do the same. 
>
> Simply stated: we would finally get async support in Django, without 
> having to rewrite large parts of Django. Also, we need no persistent 
> message storage. Connected clients get the messages, then it's discarded. 
>
> There is existing work on this that could be a starting point for a more 
> Django:y API: https://github.com/brutasse/asyncio-sse 
>
> --- 
>
> I think server-sent events would be a great reason to choose Django over 
> other frameworks. It would finally answer the request for "async" 
> features in Django, with a system that's as easy to setup (just start 
> the process) as to implement. 
>
> Would anyone we willing to work with me on this? Do you think it makes 
> sense to put this in Django? I don't see any need for this code to 
> change often, and it fits well with the "building apps quickly and with 
> less code" mantra. 
>
> Thoughts? Ideas? 
>
> (And yes, this idea would work great together with the js template 
> rendering. Pushing database updates from the server to the client, and 
> they instantly updating the template accordingly) 
>
> Regards, 
>
> Emil Stenström 
> Twitter: @EmilStenstrom 
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/82e2e4c2-ebc2-4d65-a1f0-5947e2ceed2e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django Admin New Look

[Emil Stenström]

I just wanted to add that this looks GREAT. Maintaining the old colors was 
a smart move, as this makes things familiar but still new. This work was 
long overdue!

/E

On Saturday, 23 May 2015 14:00:18 UTC+2, elky wrote:
>
> HI Andy,
>
> Yes, this thread is actual for discussing this theme.
>
> Current pull request is https://github.com/django/django/pull/4627
>
> I hope I'll have enough time to work on it this weekend.
>
>
> On Saturday, 23 May 2015 15:35:51 UTC+5, Andy Baker wrote:
>>
>> Hi,
>>
>> Is this thread still the most up to date place for discussing this? I'm 
>> trying to work out what the current status is and whether it is likely to 
>> land in 1.9.
>>
>> For the benefit of anyone else coming to this late here's what I can 
>> track down:
>>
>> Last comment here prior to mine was jezdez on April 14th
>>
>> The standalone repo is here: https://github.com/elky/django-flat-theme 
>> (last commit May 8th)
>>
>> The Trac ticket is here: 
>> https://code.djangoproject.com/ticket/2#ticket (Status: 'accepted' 
>> but 'patch needs improvement' - last change May 11th)
>>
>> The original pull request is here: 
>> https://github.com/django/django/pull/4232 (Status closed. last update: 
>> March 11th)
>>
>> So it looks like it's still on track - I just can't find any recent 
>> discussion on it. If that's normal then apologies for the noise.
>>
>> On Wednesday, 4 March 2015 19:15:33 UTC, elky wrote:
>>>
>>> Hi guys,
>>>
>>> I think django admin needs new look. I played with styles recently and 
>>> that's the result: https://github.com/django/django/pull/4232
>>>
>>> Inspired by a new djangoproject.com site. 
>>>
>>> New theme looks modern, fresh and clean. There are CSS changes only. No 
>>> any HTML changes.
>>>
>>> Let's discuss it. I will appreciate any feedback.
>>>
>>> Thanks
>>>
>>> P.S. I can create demo app if it needs.
>>>
>>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b9d3137e-82ad-4612-af5b-85b0a205a7f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Support Server-Sent Events

[Emil Stenström]

Hi Collin,

I'll answer in this thread to keep here things tidy.

Since Server-Sent Events are just HTTP you can scale them the same way you 
scale your normal web app. Split users so some users hit one server and 
some users hit another. Then let Django communicate with all server 
processes instead of just one.

But I wouldn't say this would have to be the responsibility of Django, just 
like scaling your database isn't Django's concern. As long as you can 
decide who connects to what machine it should be able to scale horizontally.

/Emil

On Saturday, 30 May 2015 19:04:26 UTC+2, Collin Anderson wrote:
>
> Hi Emil,
>
> I also like "server sent events" (EventSource). They get through proxies 
> much more reliably than WebSockets. :)
>
> "You would start the process separately, add a script tag to your page, 
> and all clients that connected to the page would be connected to the 
> process. Now Django could push messages through that process as part of the 
> request-response cycle, and all clients would be notified. Other processes 
> (a cron job?) could do the same."
>
> Have you thought about how to scale this across multiple machines?
>
> Thanks,
> Collin
>
>
> On Saturday, May 30, 2015 at 12:51:33 PM UTC-4, Emil Stenström wrote:
>>
>> Hi! 
>>
>> A couple of weeks ago I held a presentation on PyCon Sweden 2015 with 
>> the title "Why Django Sucks". The idea was to follow in the footsteps of 
>> great conference talks like these: 
>> https://www.youtube.com/playlist?list=PLGYrvlVoAdf9j3v_teol3s7hl8gkUd8E2 
>>
>> These talks are great because they encourage people to take an outside, 
>> critical, perspective of Django and where it's going. 
>>
>> My talk was well received, with many both interested and skeptical 
>> questions afterwards. Unfortunately, the final video was missing the 
>> sound, so the camera crew is working on fixing that now. I'll post it to 
>> this thread as soon as I get it. Meanwhile, here's a text summary: 
>>
>> --- 
>>
>> The theme for my talk was that Django's bad support for Javascript heavy 
>> sites. Everyone is using javascript for their sites nowadays. Problem 
>> is, Django (and large parts if the Django community) has long had a 
>> approach to Javascript that can be summed up with Simon Willison's reply 
>> to someone asking for AJAX support in 2005: 
>>
>> "For me "Ajax support" really is pure marketing fluff - as far as I'm 
>> concerned EVERY web framework supports Ajax unless it does something 
>> truly moronic like refuse to let you output documents that don't have 
>> the standard header/footer template." 
>> Source: http://bit.ly/django2005 
>>
>> The problem with this mindset (I'm not picking at Simon from 10 years 
>> ago) is that the web as large is moving towards MORE javascript, with 
>> live notifications, live updating templates, and reusable template 
>> components. And these are hard to implement in Django as things work 
>> today. I see this is the biggest competitive disadvantage Django has 
>> going forward. 
>>
>> So, what specific features am I proposing? I will get to a specific set 
>> of features soon. But first I want to make clear that a completely 
>> different set of features could get us to the same goal. That is: it's 
>> possible to agree on the broader goal for Django, and disagree on my 
>> specific set of features. If you don't agree on the features, I would 
>> love to see your proposed feature list. 
>>
>> Just to give one alternate path: In that old thread from 2005, Jacob 
>> Kaplan-Moss suggested exposing the ORM through Javascript with an RPC 
>> API: 
>> https://groups.google.com/d/msg/django-developers/XmKfVxyuyAU/lkp6N1HTzG4J 
>>
>> Jacobs suggestion is interesting, but I have three other features that I 
>> would like to discuss. I think they would greatly ease building 
>> javascript heavy sites with Django. 
>>
>> *I will split the specific suggestions into three different e-mail 
>> threads, so we can discuss them separately*. 
>>
>> Here's a short intro to them: 
>>
>> 1. Template Components 
>> React.js popularized the notion that in front-end development, code 
>> organization should be based on interface components, not split up into 
>> HTML, Javascript and CSS. It's simply a different way to organize the 
>> code for your front-end, that I strongly think Django should make 
>> easier. (read more in separate thread) 
>>
>> 2. Support a client side template language 
>> The multiple template engine work has made it possible to switch out 
>> Django Templates with another engine. One of the most powerful things 
>> this enables is to use a template language that is executable both on 
>> the server and client. This means you can do the same kind of live 
>> updates to your page that the Meteor.js people are doing, and just 
>> re-render parts of the DOM as a direct result of a database update. 
>> (read more in separate thread) 
>>
>> 3. Support Server-Sent Events 
>> If you want a snappy user experience, polling isn't 

Re: Idea: Better support for javascript heavy sites

[Collin Anderson]

Hi Emil,

I also like "server sent events" (EventSource). They get through proxies 
much more reliably than WebSockets. :)

"You would start the process separately, add a script tag to your page, and 
all clients that connected to the page would be connected to the process. 
Now Django could push messages through that process as part of the 
request-response cycle, and all clients would be notified. Other processes 
(a cron job?) could do the same."

Have you thought about how to scale this across multiple machines?

Thanks,
Collin


On Saturday, May 30, 2015 at 12:51:33 PM UTC-4, Emil Stenström wrote:
>
> Hi! 
>
> A couple of weeks ago I held a presentation on PyCon Sweden 2015 with 
> the title "Why Django Sucks". The idea was to follow in the footsteps of 
> great conference talks like these: 
> https://www.youtube.com/playlist?list=PLGYrvlVoAdf9j3v_teol3s7hl8gkUd8E2 
>
> These talks are great because they encourage people to take an outside, 
> critical, perspective of Django and where it's going. 
>
> My talk was well received, with many both interested and skeptical 
> questions afterwards. Unfortunately, the final video was missing the 
> sound, so the camera crew is working on fixing that now. I'll post it to 
> this thread as soon as I get it. Meanwhile, here's a text summary: 
>
> --- 
>
> The theme for my talk was that Django's bad support for Javascript heavy 
> sites. Everyone is using javascript for their sites nowadays. Problem 
> is, Django (and large parts if the Django community) has long had a 
> approach to Javascript that can be summed up with Simon Willison's reply 
> to someone asking for AJAX support in 2005: 
>
> "For me "Ajax support" really is pure marketing fluff - as far as I'm 
> concerned EVERY web framework supports Ajax unless it does something 
> truly moronic like refuse to let you output documents that don't have 
> the standard header/footer template." 
> Source: http://bit.ly/django2005 
>
> The problem with this mindset (I'm not picking at Simon from 10 years 
> ago) is that the web as large is moving towards MORE javascript, with 
> live notifications, live updating templates, and reusable template 
> components. And these are hard to implement in Django as things work 
> today. I see this is the biggest competitive disadvantage Django has 
> going forward. 
>
> So, what specific features am I proposing? I will get to a specific set 
> of features soon. But first I want to make clear that a completely 
> different set of features could get us to the same goal. That is: it's 
> possible to agree on the broader goal for Django, and disagree on my 
> specific set of features. If you don't agree on the features, I would 
> love to see your proposed feature list. 
>
> Just to give one alternate path: In that old thread from 2005, Jacob 
> Kaplan-Moss suggested exposing the ORM through Javascript with an RPC API: 
> https://groups.google.com/d/msg/django-developers/XmKfVxyuyAU/lkp6N1HTzG4J 
>
> Jacobs suggestion is interesting, but I have three other features that I 
> would like to discuss. I think they would greatly ease building 
> javascript heavy sites with Django. 
>
> *I will split the specific suggestions into three different e-mail 
> threads, so we can discuss them separately*. 
>
> Here's a short intro to them: 
>
> 1. Template Components 
> React.js popularized the notion that in front-end development, code 
> organization should be based on interface components, not split up into 
> HTML, Javascript and CSS. It's simply a different way to organize the 
> code for your front-end, that I strongly think Django should make 
> easier. (read more in separate thread) 
>
> 2. Support a client side template language 
> The multiple template engine work has made it possible to switch out 
> Django Templates with another engine. One of the most powerful things 
> this enables is to use a template language that is executable both on 
> the server and client. This means you can do the same kind of live 
> updates to your page that the Meteor.js people are doing, and just 
> re-render parts of the DOM as a direct result of a database update. 
> (read more in separate thread) 
>
> 3. Support Server-Sent Events 
> If you want a snappy user experience, polling isn't enough. There are 
> two major ways to get out of the request-response cycle. Namely: 
> websockets and server-sent events. Server-Sent Events have a much 
> simpler protocol, and could be implemented with asyncio (no external 
> dependencies except for backwards compatibility) in a performant way. It 
> would be a great reason to choose Django over other frameworks. (read 
> more in separate thread) 
>
> --- 
>
> This is not a "request for features". I am in no way saying that I think 
> you should build things for me. Instead I'm willing to work on  them 
> together with anyone interested, if these are features that the core 
> team would be interested in. 
>
> But first I would like to see if you: 
> 1. Agree 

Re: Idea: Better support for javascript heavy sites

[Emil Stenström]

On Saturday, 30 May 2015 18:51:33 UTC+2, Emil Stenström wrote:
>
> *I will split the specific suggestions into three different e-mail 
> threads, so we can discuss them separately*. 
>

Here's are the three different proposals:
https://groups.google.com/forum/#!topic/django-developers/fRPXSGnPng0
https://groups.google.com/forum/#!topic/django-developers/gawpGr9EtKM
https://groups.google.com/forum/#!topic/django-developers/FmBM8VdxJ08 

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/89ed6aab-2266-4847-8c4c-dcb6f9729633%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Feature: Support Server-Sent Events

[Emil Stenström]

Hi,

This is the third feature proposal as part of my general drive for 
getting Django to work better for javascript heavy sites.


Support Server-Sent Events
--

If you want a snappy user experience, AJAX polling isn't enough. There 
are two major ways to get out of the request-response cycle. Namely: 
websockets and server-sent events.


Websockets are complicated beasts, and getting cross-browser support for 
them requires implementing several protocol versions. They are also 
bidirectional, meaning you can send stuff to the server with them.


Server-Sent Events use normal HTTP, and are natively supported 
everywhere except Internet Explorer. Since they don't use a custom 
protocol there are several polyfills that enable IE support too, 
bringing browser compliance close to 100%. SSE only supports sending 
data from server to client, not the other way around.


The ease of implementation for server-sent events makes it a much better 
Django fit in my opinion. Also, I don't think the need for client -> 
server requests is that big, you can easily solve that with AJAX calls 
instead.


More reading on how it works:
http://www.html5rocks.com/en/tutorials/eventsource/basics/

---

Just like websockets, server-sent events rely on persistent connections 
to each connected client. This means that we need a separate process to 
make this work properly. I understand this is a controversial 
suggestion, but it allows the rest of Django to continue working like 
before, and still offer async support to users. It's the best of two worlds.


So how would you implement such a process in a performant way? With 
Python 3's asyncio package (for Python 2 support there's trollius: 
https://pypi.python.org/pypi/trollius). This means no external 
dependencies (except for old pythons).


You would start the process separately, add a script tag to your page, 
and all clients that connected to the page would be connected to the 
process. Now Django could push messages through that process as part of 
the request-response cycle, and all clients would be notified. Other 
processes (a cron job?) could do the same.


Simply stated: we would finally get async support in Django, without 
having to rewrite large parts of Django. Also, we need no persistent 
message storage. Connected clients get the messages, then it's discarded.


There is existing work on this that could be a starting point for a more 
Django:y API: https://github.com/brutasse/asyncio-sse


---

I think server-sent events would be a great reason to choose Django over 
other frameworks. It would finally answer the request for "async" 
features in Django, with a system that's as easy to setup (just start 
the process) as to implement.


Would anyone we willing to work with me on this? Do you think it makes 
sense to put this in Django? I don't see any need for this code to 
change often, and it fits well with the "building apps quickly and with 
less code" mantra.


Thoughts? Ideas?

(And yes, this idea would work great together with the js template 
rendering. Pushing database updates from the server to the client, and 
they instantly updating the template accordingly)


Regards,

Emil Stenström
Twitter: @EmilStenstrom

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5569EACC.4040400%40kth.se.
For more options, visit https://groups.google.com/d/optout.

Feature: Template Components

[Emil Stenström]

Hi,

This is the first feature proposal as part of my general drive for 
getting Django to work better for javascript heavy sites.


Template Components
---

React.js popularized the notion that in front-end development, code 
organization should be based on interface components, not split up into 
HTML, Javascript and CSS. Here's the original presentation and the 
rationale behind organizing around components:

https://www.youtube.com/watch?v=x7cQ3mrcKaY=2m7s

In Django, adding a Javascript calendar to you site requires changes to 
four different locations in your project:


- /app/templatetags/calendar_tags.py <- A custom inclusion template tag
- /app/templates/calendar.html <- Some HTML in the template dir
- /static/css/style.css <- Add some CSS to style.css
- /static/js/script.js <- Add some JS to scipt.js

There is no connection within Django between HTML and the CSS + JS. 
Django does not help you, or even suggest a structure for you, like it 
does with all Python code.


On the other hand, we have Form Assets:
https://docs.djangoproject.com/en/1.8/topics/forms/media/

Example:

from django import forms
class CalendarWidget(forms.TextInput):
class Media:
css = {'all': ('calendar.css',)}
js = ('calendar.js',)


w = CalendarWidget()
print(w.media)




... which define a kind of component, but one that is tied to a form 
field. My suggestion is a new package: django.template.component, that 
builds on the Media class from Form Assets, and allows you to define 
your components like this:


from django.template import component
class Calendar(component.Component):
def context(self, date):
return {"date": date}
class Media:
template = "app/components/calendar/calendar.html"
css = {'all': ('app/components/calendar/calendar.css',)}
js = ('app/components/calendar/calendar.js',)

component.register(name="calendar", component=Calendar)

... and later in your template:

{% load components %}
{% block extra_media %}{% component_dependencies %}{% endblock %}
{% block main %}
{% component "calendar" date=custom_date %}
{% endblock %}

---

Advantages:
- You to keep the python, html, css, and javascript in one location, and 
explicitly define the dependencies between them.
- All  and 

Feature: Support a javascript template language on the server

[Emil Stenström]

Hi,

This is the second feature proposal as part of my general drive for 
getting Django to work better for javascript heavy sites.


Support a javascript template language on the server


The multiple template engine work has made it possible to switch out 
Django Templates with another engine. One of the most powerful things 
this enables is to use a template language that is executable both on 
the server and client.


A typical use-case for this could be that you have a list of tweets on 
your site. When the user first loads the page you send the full HTML for 
all the rendered tweets over. When there's a new tweet you would like to 
just add that one tweet to the list, without re-rendering the whole 
page. Now you have a couple of options:


1. Reimplement the Django template code from your site in javascript. 
This is harder the more complex the template your have. Also risks bugs 
when you change the server-side template but forget the client-side one.


2. Use Pjax, render everything on the server and send the result to the 
page. This sends unnecessary data over the wire, and requires that you 
figure out how to append the data in the correct location.


3. Send the server-side templates to the browser, and then re-render on 
the client when new data arrives. This uses the least data over the 
wire, and does not require that you keep track of mappings, just update 
the data and re-render everything (React.js's virtual DOM can make this 
really fast if you need it to be).


Option 3 opens up lots of interesting use-cases for Django, that 
previously was only possible for javascript-based frameworks.


---

To be clear, I'm not saying that Django should include any front-end 
code at all. That's something that the individual developer should have 
full control over. But what needs to happen is that the same templates 
that Django uses needs to be accessible to, and executable in, javascript.


For this to work, two things needs to be built:

1. A way to access the template and the template context for a view 
separately, so that it can be delivered to the client. Maybe the easiest 
would be to modify django.shortcuts.render so it returns both the input 
and the result. The client could then get access to this via a 

Idea: Better support for javascript heavy sites

[Emil Stenström]

Hi!

A couple of weeks ago I held a presentation on PyCon Sweden 2015 with 
the title "Why Django Sucks". The idea was to follow in the footsteps of 
great conference talks like these:

https://www.youtube.com/playlist?list=PLGYrvlVoAdf9j3v_teol3s7hl8gkUd8E2

These talks are great because they encourage people to take an outside, 
critical, perspective of Django and where it's going.


My talk was well received, with many both interested and skeptical 
questions afterwards. Unfortunately, the final video was missing the 
sound, so the camera crew is working on fixing that now. I'll post it to 
this thread as soon as I get it. Meanwhile, here's a text summary:


---

The theme for my talk was that Django's bad support for Javascript heavy 
sites. Everyone is using javascript for their sites nowadays. Problem 
is, Django (and large parts if the Django community) has long had a 
approach to Javascript that can be summed up with Simon Willison's reply 
to someone asking for AJAX support in 2005:


"For me "Ajax support" really is pure marketing fluff - as far as I'm
concerned EVERY web framework supports Ajax unless it does something
truly moronic like refuse to let you output documents that don't have
the standard header/footer template."
Source: http://bit.ly/django2005

The problem with this mindset (I'm not picking at Simon from 10 years 
ago) is that the web as large is moving towards MORE javascript, with 
live notifications, live updating templates, and reusable template 
components. And these are hard to implement in Django as things work 
today. I see this is the biggest competitive disadvantage Django has 
going forward.


So, what specific features am I proposing? I will get to a specific set 
of features soon. But first I want to make clear that a completely 
different set of features could get us to the same goal. That is: it's 
possible to agree on the broader goal for Django, and disagree on my 
specific set of features. If you don't agree on the features, I would 
love to see your proposed feature list.


Just to give one alternate path: In that old thread from 2005, Jacob 
Kaplan-Moss suggested exposing the ORM through Javascript with an RPC API:

https://groups.google.com/d/msg/django-developers/XmKfVxyuyAU/lkp6N1HTzG4J

Jacobs suggestion is interesting, but I have three other features that I 
would like to discuss. I think they would greatly ease building 
javascript heavy sites with Django.


*I will split the specific suggestions into three different e-mail 
threads, so we can discuss them separately*.


Here's a short intro to them:

1. Template Components
React.js popularized the notion that in front-end development, code 
organization should be based on interface components, not split up into 
HTML, Javascript and CSS. It's simply a different way to organize the 
code for your front-end, that I strongly think Django should make 
easier. (read more in separate thread)


2. Support a client side template language
The multiple template engine work has made it possible to switch out 
Django Templates with another engine. One of the most powerful things 
this enables is to use a template language that is executable both on 
the server and client. This means you can do the same kind of live 
updates to your page that the Meteor.js people are doing, and just 
re-render parts of the DOM as a direct result of a database update. 
(read more in separate thread)


3. Support Server-Sent Events
If you want a snappy user experience, polling isn't enough. There are 
two major ways to get out of the request-response cycle. Namely: 
websockets and server-sent events. Server-Sent Events have a much 
simpler protocol, and could be implemented with asyncio (no external 
dependencies except for backwards compatibility) in a performant way. It 
would be a great reason to choose Django over other frameworks. (read 
more in separate thread)


---

This is not a "request for features". I am in no way saying that I think 
you should build things for me. Instead I'm willing to work on  them 
together with anyone interested, if these are features that the core 
team would be interested in.


But first I would like to see if you:
1. Agree on the main point that Django should do more for javascript 
heavy sites.
2. Agree that one or more of the specific features that I'm proposing 
would be a good fit for Django (see separate threads).


No matter what, I would love to hear your thoughts and ideas here.

Regards,

Emil Stenström
Twitter: @EmilStenstrom

--
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 

Re: URL namespaces

[Tai Lee]

>
> An app doesn't necessarily have to use its own patterns. With that said, 
> it's up to the user to make sure it works if they are to mess with the 
> app_name. Two conflicting apps can be installed with different namespaces, 
> but there will always be a default (the last one, if there is no namespace 
> with the same name). With a consistent use of `current_app` (even if it's 
> not the *current* application used in the request), you can avoid problems.
>

Right. So if I understand correctly, you can avoid problems even when 
installing two different apps into the same app namespace as long as you 
*always* supply `current_app` when reversing URLs? In which case, I don't 
think we need to worry about being able to change the app namespace to 
avoid conflicts (maybe we should even disallow it), and instead just make 
it easier to *always* supply `current_app`, which brings me to my next 
point.

If possible, I'd like to add `current_app` to the request by default, but 
> that has been attempted before, and backwards compatibility is a problem. 
> That would allow an app to more reliably reverse its own urls, provided 
> that their code and templates are called from within their own application.
>

I'd take this a step further. In this comment -- 
https://code.djangoproject.com/ticket/21927#comment:9 -- I made a 
suggestion that Django set a `current_app` hint in thread local storage 
with a middleware class or even before middleware runs, and then have 
`reverse()` and `{% url %}` fallback to that default hint ONLY if no 
current app is explicitly provided via the current mechanisms, so it should 
be a relatively safe change.

This should make it much more convenient and possible to reverse URLs 
correctly regardless of conflicting app namespaces, even in code that 
doesn't have access to the request object. For example, model methods that 
are executed in templates and do not have access to a `request` or 
`RequestContext` object. As far as I know, 1 thread = 1 request, so using 
thread local storage should be safe to provide such a hint for any code 
that executes in response to a request. For management commands, it would 
still need to be supplied explicitly. What do you think?

Cheers.
Tai.

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ba7b83e0-8961-45f9-89f0-e45ce25224fb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.