Re: Feature: Template Components

[Joe Tennies]

I actually think this is a great idea. In my mind it parallels Drupal's
"block" idea. (This is actually what I keep hoping DjangoCMS is.)

That stated, it is more of a construct. I think a great idea is to make an
extension module.

I don't know how long you've been in this community, but Django is now
quite stable and people rely on their APIs. Your bold ideas really need to
be tested by fire before they go into the Django proper. There's been lots
of discussion about a year ago to remove/reduce a lot of the contrib.

Being in Django is where things go to die. Once an API is released to the
public, it takes a fair amount of work to remove/change it. You don't even
want to know how long it took to get schema migrations into Django. South
had been the defacto way for quite a few years. That stated, Andrew had to
make some changes to South due to design decisions that were made earlier
in South. Before that, there was other projects like django-evolution
(which just got an update 2 months ago).

So, I followed the Drupal group for a while. The thing the Django community
really needs is a couple good opinionated groups of how to put together a
good Django site. Drupal has Lullabot (who have quite a few core devs on
staff). Django is not going to be the people telling people how to use
Django. You seem like a great person to start this for Django. Note that
you'll have to have a thick skin and create some pretty great sites in your
own right to prove out your ideas to others. You'll also need to get your
ideas out via things like blog posts, tutorials, and podcasts.

I would like the Caktus, DjangoCMS, FeinCMS, etc people to do the same.
This would help people to see some different ideas on how to use and extend
Django.

On Sun, May 31, 2015 at 5:26 AM, Emil Stenström  wrote:

> On Sunday, 31 May 2015 11:36:51 UTC+2, riccardo.magliocchetti wrote:
>>
>> Il 31/05/2015 11:00, Emil Stenström ha scritto:
>> > On Sunday, 31 May 2015 10:27:24 UTC+2, riccardo.magliocchetti wrote:
>> > Il 30/05/2015 18:52, Emil Stenström ha scritto:
>> > But your proposal keeps html and js separated. I think you are
>> solving a
>> > problem
>> > for the one that just want to use a component but you are not
>> solving the
>> > problem for the one that is writing components. At least not in the
>> react.js
>> > way, especially from such a bold premise :)
>> >
>> > I agree that I don't quite do it the same way as React. But that's not
>> the point
>> > here either, to somehow bundle Reacts ideas inside Django. My point is
>> that
>> > keeping the four parts that make a component closely together in the
>> project
>> > source, would make for a better structure. They only idea that comes
>> from React
>> > is thinking in components rather than nested templates and template
>> tags, which
>> > are Django's current way of solving this.
>>
>> I see, but who are going to do a big js app without using a framework
>> like
>> angular / react.js / ember / whatever? I'm not saying your Component
>> proposal is
>> without merit but i can't see how it can fit where the js app is done
>> with a
>> framework.
>>
>
> The idea is simply to keep interface components together in the Django
> project tree. That wouldn't change your options in regards to what
> javascript framework to use, just give you some help with organizing your
> code.
>
> Say you decide to use React as just JS framework. Since React puts the
> HTML inside your javascript your Django component would simply be:
>
> class ReactCalendar(component.Component):
> def context(self, date):
> return {"date": date}
> class Media:
> template = None
> css = {'all': ('app/components/calendar/calendar.css',)}
> js = ('app/components/calendar/calendar.js',)
>
> Since React doesn't handle CSS the component model would give you a way of
> tying thing together anyway. And with the component template tag you would
> be able to decide where to include your React component.
>
> --
> 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/a05f2dc1-3515-4b23-96f5-479d2722b82c%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Joe Tennies
tenn...@gmail.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To 

Re: Feature: Support Server-Sent Events

[Curtis Maloney]

I think the real questions are:

1. What is stopping a 3rd party product from providing the features you
want?

If there is something Django can do to make it easier, point it out, and
I'll gladly champion a good feature.

2. Why should your solution be the "blessed" solution?

The discussion clearly shows there are several ways to skin this cat... why
is your way better than any other?  Until there is a clear winner [see
migrations and South] it should live as a 3rd party app, with Django
providing whatever mechanisms/support it can.

Personally, I've used DOM-SSE to implement a simple chat service in Django,
using Redis for the PUB-SUB server.  It was only really feasible because
(a) I used gevent, (b) no ORM means no need for async DB adapter, and (c)
the py-redis module is Pure Python, so can be monkey patched.

[FYI I've also translated that same code to raw WSGI app, and using
async-io, available on github if you're interested ]

--
Curtis


On 1 June 2015 at 08:03, Emil Stenström  wrote:

> On Sunday, 31 May 2015 15:56:09 UTC+2, Florian Apolloner wrote:
>>
>> On Saturday, May 30, 2015 at 10:40:26 PM UTC+1, Emil Stenström wrote:
>>>
>>> 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.
>>>
>>
>> How, you still need some kind of interprocess communication
>>
>
> Yes, interprocess communication is needed. The simplest way to get the two
> programs to talk would be to use a HTTP POST to the other program (which
> would run on another port). This would also make it possible for other
> programs to send messages through the same connection.
>
>
>> So the SSE process is VERY simple. It just connects to clients and passes
>>> on messages the all clients connected.
>>>
>> VERY simple is an oversimplification in my opinion. I also do not see any
>> reason for supporting it inside Django currently when things like
>> autobahn.ws
>> 
>> exist, the only thing missing there is the communication between the
>> processes.
>>
>
> Is the argument here that "since there are other ways of doing it I see no
> reason to do it in Django?". Autobahn is a huge dependency on your program,
> when all you need for most usecases is a small event loop and a way to pass
> messages. Setting up websockets and redis pubsub is also a huge hassle. I
> see the need for something simple, something you could get up and running
> quickly.
>
>
>> I am not sure what people are expecting here from Django (and from your
>> explanations I am still not really convinced or see a usecase at all).
>>
>
> A simple use-case is Facebook style notifications. When something happens
> to a user you want to send that user a notification right away, not 10
> seconds later because that's how often you were polling the server. Another
> use-case is a user chat. When a user sends a message you want that message
> to show up right away. Or maybe you keep track of server uptime on a status
> page. When a server goes down you want your users to be notified
> immediately, not later.
>
>
>> Since the message passing between the server processes should be
>> language/framework agnostic anyways, this would be better suited for a
>> third party project anyways. Reimplementing one of the existing
>> SSE/Websockets implementations does not really seem like a win to me either.
>>
>
> I agree that they should be language/framework agnostic, that's why I
> think a HTTP Post would work great to send messages. And I agree this could
> be developed as a separate project to start with. I *don't* agree that
> this wouldn't be something worthwhile to include in Django.
>
> --
> 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/d1148851-7ced-4463-9bf5-02a54d5a5ade%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 

Re: Feature: Support a javascript template language on the server

[Emil Stenström]

On Sunday, 31 May 2015 18:49:07 UTC+2, Enrique Paredes wrote:
>
> IMHO, this can be easily solved with nunjucks.js and jinja which are both 
> interchangeable, but in my experience it's better to had 2 template 
> languages. Using only one tpl gives you the need to implement the same in 
> the django views than in the js controller wich is "harsh" coupled and a 
> PITA.
>

I'm not sure what your argument is here. 

Are you saying you prefer implementing all templates in two languages, 
since implementing views twice is too much work? The time you save being 
able to reuse the same templates in the client side is huge, and avoids the 
maintenance burden of keeping two identical things in sync.

I'm also not saying you should implement views twice. Each time you click a 
link that request can go to the exact same server side view, get the 
correct data back (only the data), and re-render only the parts that 
changed.
 

> Also the need to reimplement django.shortcuts.render is unneded. Add in 
> the base tpl a {% if request.is_ajax %} then wrap the result in a entire 
> html tpl for regular http calls and the new content only in the other case.
>

I'm not sure I follow here. Are you saying I should just go through all my 
templates and split them in two? What do you mean by "new content" here? My 
suggestion is that you would send only the new DATA, and that the client 
would use that data, and the templates, to re-render the page. 

The good thing about changing render is that render gets both the template 
and the template_context as input (the two things we need on the client 
side to re-render the page), all you need is a way to get them out of 
there. Maybe this is possible to get from a HTTPResponse, if it is, no 
changes would have to be made to render().

Another option is to use django_braces and AjaxResponseView to respond back 
> ajax with only json data but again you'll be force to sync django views and 
> the controller for js.
>  
> Just my two cents, I'm used to build JS intense sites backed with django 
> without any problem.
>
> For me the work should be documenting how to use django with a client MV# 
> and list the options and the apis for that.
>

I'm not advocating client side MVC here, I think most sites would be better 
of just letting Django handle all the routing. That's why the idea of just 
modifying your existing views to return the template_context is so 
convenient. All you need on the client side is to turn link clicks to ajax 
calls (or fallback to normal clicks if the client doesn't support 
javascript), and render templates with the returned data.

>From your different suggestions throughout your e-mail it sounds to me you 
have had to duplicate lots of your code between the server and the client. 
This proposal would avoid much of that. 

-- 
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/e74237d5-18ad-45a9-99d3-d12f1ea6902b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Support Server-Sent Events

[Emil Stenström]

On Sunday, 31 May 2015 15:56:09 UTC+2, Florian Apolloner wrote:
>
> On Saturday, May 30, 2015 at 10:40:26 PM UTC+1, Emil Stenström wrote:
>>
>> 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.
>>
>
> How, you still need some kind of interprocess communication 
>

Yes, interprocess communication is needed. The simplest way to get the two 
programs to talk would be to use a HTTP POST to the other program (which 
would run on another port). This would also make it possible for other 
programs to send messages through the same connection.
 

> So the SSE process is VERY simple. It just connects to clients and passes 
>> on messages the all clients connected. 
>>
> VERY simple is an oversimplification in my opinion. I also do not see any 
> reason for supporting it inside Django currently when things like 
> autobahn.ws 
> 
>  
> exist, the only thing missing there is the communication between the 
> processes.
>

Is the argument here that "since there are other ways of doing it I see no 
reason to do it in Django?". Autobahn is a huge dependency on your program, 
when all you need for most usecases is a small event loop and a way to pass 
messages. Setting up websockets and redis pubsub is also a huge hassle. I 
see the need for something simple, something you could get up and running 
quickly.
 

> I am not sure what people are expecting here from Django (and from your 
> explanations I am still not really convinced or see a usecase at all). 
>

A simple use-case is Facebook style notifications. When something happens 
to a user you want to send that user a notification right away, not 10 
seconds later because that's how often you were polling the server. Another 
use-case is a user chat. When a user sends a message you want that message 
to show up right away. Or maybe you keep track of server uptime on a status 
page. When a server goes down you want your users to be notified 
immediately, not later.
 

> Since the message passing between the server processes should be 
> language/framework agnostic anyways, this would be better suited for a 
> third party project anyways. Reimplementing one of the existing 
> SSE/Websockets implementations does not really seem like a win to me either.
>

I agree that they should be language/framework agnostic, that's why I think 
a HTTP Post would work great to send messages. And I agree this could be 
developed as a separate project to start with. I *don't* agree that this 
wouldn't be something worthwhile to include in Django. 

-- 
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/d1148851-7ced-4463-9bf5-02a54d5a5ade%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Support Server-Sent Events

[Emil Stenström]

On Sunday, 31 May 2015 16:52:50 UTC+2, Rotund wrote:
>
> The fact that you keep describing your idea as another process/thread that 
> has back and forth communication with the actual Django instance seems to 
> indicate to me that it's another program. 
>

Yes, I was not clear about the distinction between separate process and 
separate program. I see this as a separate UNIX process.
 

> I think people here tend to follow more of the UNIX philosophy of a 
> collection of smaller simple programs that can easily interact (monolithic 
> stack being ignored as that's a much older decision). 
>

Isn't this exactly what I'm proposing? A small simple program that gives 
Django users access to server sent events in their Django project?
 

> If you want tighter integration with Django, I think it would best be done 
> via your program instead of Django itself.
>

I don't think whether this program is inside Django or not changes the 
technical implementation. I fully agree that this could be developed as a 
separate project, but I also think that Django as a project would benefit 
from including this and giving people a way to do async without needing on 
external dependencies. The whole batteries included applied to modern 
sites. I believe the problem here is that if Django keeps pushing away from 
things you need for JS heavy sites, it will slowly become irrelevant.

Keep up the good work. 
>
 
Thanks!

-- 
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/c8b33314-a227-4126-9618-a62bce1e0f13%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Support a javascript template language on the server

[Enrique Paredes]

IMHO, this can be easily solved with nunjucks.js and jinja which are both 
interchangeable, but in my experience it's better to had 2 template languages. 
Using only one tpl gives you the need to implement the same in the django views 
than in the js controller wich is "harsh" coupled and a PITA.


Also the need to reimplement django.shortcuts.render is unneded. Add in the 
base tpl a {% if request.is_ajax %} then wrap the result in a entire html tpl 
for regular http calls and the new content only in the other case.




Another option is to use django_braces and AjaxResponseView to respond back 
ajax with only json data but again you'll be force to sync django views and the 
controller for js.




Just my two cents, I'm used to build JS intense sites backed with django 
without any problem.




For me the work should be documenting how to use django with a client MV# and 
list the options and the apis for that.




Cheers!

E.

On Sat, May 30, 2015 at 6:52 PM, Emil Stenström  wrote:

> 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 

Re: Feature: Support Server-Sent Events

[Joe Tennies]

I'm going to kind of reiterate what Florian said.

The fact that you keep describing your idea as another process/thread that
has back and forth communication with the actual Django instance seems to
indicate to me that it's another program. I think people here tend to
follow more of the UNIX philosophy of a collection of smaller simple
programs that can easily interact (monolithic stack being ignored as that's
a much older decision). If you want tighter integration with Django, I
think it would best be done via your program instead of Django itself.

Now that stated, you may work on your project and discover that there is
some additional things that would be easier if done in Django. I'm thinking
some kind of way to register on the Django Signals on a separate processor
or another feature that is useful outside just your project. That would be
a good time to discuss such a feature.

Keep up the good work.

- Joe

On Sun, May 31, 2015 at 8:56 AM, Florian Apolloner 
wrote:

>
>
> On Saturday, May 30, 2015 at 10:40:26 PM UTC+1, Emil Stenström wrote:
>>
>> 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.
>>
>
> How, you still need some kind of interprocess communication
>
> So the SSE process is VERY simple. It just connects to clients and passes
>> on messages the all clients connected.
>>
>
> VERY simple is an oversimplification in my opinion. I also do not see any
> reason for supporting it inside Django currently when things like
> autobahn.ws exist, the only thing missing there is the communication
> between the processes. I am not sure what people are expecting here from
> Django (and from your explanations I am still not really convinced or see a
> usecase at all). Since the message passing between the server processes
> should be language/framework agnostic anyways, this would be better suited
> for a third party project anyways. Reimplementing one of the existing
> SSE/Websockets implementations does not really seem like a win to me either.
>
> Cheers,
> Florian
>
> --
> 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/86b8ff28-b35f-49cd-8e95-30ace07c9d51%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Joe Tennies
tenn...@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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CACiOJ6tK%3D%2BmRiE55Y_fg4y-KWtiroMR7fowPkec%2Bx4C5jwuUWQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Support Server-Sent Events

[Florian Apolloner]

On Saturday, May 30, 2015 at 10:40:26 PM UTC+1, Emil Stenström wrote:
>
> 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.
>

How, you still need some kind of interprocess communication 

So the SSE process is VERY simple. It just connects to clients and passes 
> on messages the all clients connected. 
>

VERY simple is an oversimplification in my opinion. I also do not see any 
reason for supporting it inside Django currently when things like 
autobahn.ws exist, the only thing missing there is the communication 
between the processes. I am not sure what people are expecting here from 
Django (and from your explanations I am still not really convinced or see a 
usecase at all). Since the message passing between the server processes 
should be language/framework agnostic anyways, this would be better suited 
for a third party project anyways. Reimplementing one of the existing 
SSE/Websockets implementations does not really seem like a win to me either.

Cheers,
Florian

-- 
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/86b8ff28-b35f-49cd-8e95-30ace07c9d51%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Template Components

[Emil Stenström]

On Sunday, 31 May 2015 11:36:51 UTC+2, riccardo.magliocchetti wrote:
>
> Il 31/05/2015 11:00, Emil Stenström ha scritto: 
> > On Sunday, 31 May 2015 10:27:24 UTC+2, riccardo.magliocchetti wrote: 
> > Il 30/05/2015 18:52, Emil Stenström ha scritto: 
> > But your proposal keeps html and js separated. I think you are 
> solving a 
> > problem 
> > for the one that just want to use a component but you are not 
> solving the 
> > problem for the one that is writing components. At least not in the 
> react.js 
> > way, especially from such a bold premise :) 
> > 
> > I agree that I don't quite do it the same way as React. But that's not 
> the point 
> > here either, to somehow bundle Reacts ideas inside Django. My point is 
> that 
> > keeping the four parts that make a component closely together in the 
> project 
> > source, would make for a better structure. They only idea that comes 
> from React 
> > is thinking in components rather than nested templates and template 
> tags, which 
> > are Django's current way of solving this. 
>
> I see, but who are going to do a big js app without using a framework like 
> angular / react.js / ember / whatever? I'm not saying your Component 
> proposal is 
> without merit but i can't see how it can fit where the js app is done with 
> a 
> framework. 
>

The idea is simply to keep interface components together in the Django 
project tree. That wouldn't change your options in regards to what 
javascript framework to use, just give you some help with organizing your 
code.

Say you decide to use React as just JS framework. Since React puts the HTML 
inside your javascript your Django component would simply be:

class ReactCalendar(component.Component):
def context(self, date):
return {"date": date}
class Media:
template = None
css = {'all': ('app/components/calendar/calendar.css',)}
js = ('app/components/calendar/calendar.js',)

Since React doesn't handle CSS the component model would give you a way of 
tying thing together anyway. And with the component template tag you would 
be able to decide where to include your React component.

-- 
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/a05f2dc1-3515-4b23-96f5-479d2722b82c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Support Server-Sent Events

[Emil Stenström]

On Sunday, 31 May 2015 11:16:17 UTC+2, Javier Guerra wrote:
>
> On Sun, May 31, 2015 at 3:52 AM, Emil Stenström  
> wrote: 
> > Could you help me understand why this have to be done inside a web 
> server 
> > container? 
>
> AFAICT, it doesn't have to be done in the container, but currently it 
> must be 'outside' of Django.  But having help from the container 
> allows a single request to be passed from one handler (a Django view) 
> to another (the SSE process).  it might be easier if you use an URL 
> that goes directly to the SSE process and isn't touched by Django, but 
> then you need some kind of router, or 'outer url dispatcher'.  unless 
> the SSE requests can be at a different port from the start? in that 
> case, the SSE process will need its own URL dispatcher. 
>

Since the only communication between the processes needed is to send 
messages, I don't think you need integration at the python level. Simply 
starting each process on a different port and having a way for Django to 
post a message to that port, would get us a long way. The SSE process would 
then need only one connection point, "/" if you will. Clients connect to it 
via a 

Re: Feature: Support Server-Sent Events

[Emil Stenström]

On Sunday, 31 May 2015 11:15:28 UTC+2, Federico Capoano wrote:
>
> On Sunday, May 31, 2015 at 10:52:26 AM UTC+2, Emil Stenström wrote:
> ... 
>
>> Also, I don't think you would need to mix redis (or any other persistent 
>> storage) into this. The connected clients could simply be stored in an 
>> in-memory array, that is discarded if the server crashes. When the server 
>> is started again the clients will automatically connect again, and the list 
>> of clients would be built up again.
>>
>
> How would a distributed setup be handled by this approach?
> I mean: multiple instances of the sse behind a loadbalancer.
>

I think the simplest way would be to just set up two different processes, 
and don't let all clients connect to the same one. Django could then 
maintain a list of all processes and send the same message to each process. 
Each process would then be responsible to forward it to its own set of 
clients. 

-- 
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/99c84109-8486-46e9-9f23-2e5c8a02c567%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Template Components

[Riccardo Magliocchetti]

Hi Emil,

Il 31/05/2015 11:00, Emil Stenström ha scritto:

Hi,

On Sunday, 31 May 2015 10:27:24 UTC+2, riccardo.magliocchetti wrote:

Hi,

Il 30/05/2015 18:52, Emil Stenström ha scritto:
But your proposal keeps html and js separated. I think you are solving a
problem
for the one that just want to use a component but you are not solving the
problem for the one that is writing components. At least not in the react.js
way, especially from such a bold premise :)

I agree that I don't quite do it the same way as React. But that's not the point
here either, to somehow bundle Reacts ideas inside Django. My point is that
keeping the four parts that make a component closely together in the project
source, would make for a better structure. They only idea that comes from React
is thinking in components rather than nested templates and template tags, which
are Django's current way of solving this.


I see, but who are going to do a big js app without using a framework like 
angular / react.js / ember / whatever? I'm not saying your Component proposal is 
without merit but i can't see how it can fit where the js app is done with a 
framework.



--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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/556AD65D.7030707%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Support Server-Sent Events

[Javier Guerra Giraldez]

On Sun, May 31, 2015 at 3:52 AM, Emil Stenström  wrote:
> Could you help me understand why this have to be done inside a web server
> container?

AFAICT, it doesn't have to be done in the container, but currently it
must be 'outside' of Django.  But having help from the container
allows a single request to be passed from one handler (a Django view)
to another (the SSE process).  it might be easier if you use an URL
that goes directly to the SSE process and isn't touched by Django, but
then you need some kind of router, or 'outer url dispatcher'.  unless
the SSE requests can be at a different port from the start? in that
case, the SSE process will need its own URL dispatcher.


> Also, I don't think you would need to mix redis (or any other persistent
> storage) into this. The connected clients could simply be stored in an
> in-memory array, that is discarded if the server crashes. When the server is
> started again the clients will automatically connect again, and the list of
> clients would be built up again.

in-memory as a Python object? but i think the SSE handler must be a
different interpreter instance... unless it's a thread... not sure if
the GIL would be an issue... or an "external" in-memory table? well,
that's what Redis is.


-- 
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/CAFkDaoSdpgtOheLeyKB_EQAvA5y_peFGCdWNFBZW1xx0XedMTg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Support Server-Sent Events

[Federico Capoano]

Hey Emil,

On Sunday, May 31, 2015 at 10:52:26 AM UTC+2, Emil Stenström wrote:
... 

> Also, I don't think you would need to mix redis (or any other persistent 
> storage) into this. The connected clients could simply be stored in an 
> in-memory array, that is discarded if the server crashes. When the server 
> is started again the clients will automatically connect again, and the list 
> of clients would be built up again.
>

How would a distributed setup be handled by this approach?
I mean: multiple instances of the sse behind a loadbalancer.

Federico 

-- 
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/a421b8d5-4794-42b5-a1a6-289a9d476d78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Template Components

[Emil Stenström]

Hi,

On Sunday, 31 May 2015 10:27:24 UTC+2, riccardo.magliocchetti wrote:
>
> Hi, 
>
> Il 30/05/2015 18:52, Emil Stenström ha scritto: 
> > Hi, 
> > 
> > This is the first feature proposal as part of my general drive for 
> getting 
> > Django to work better for javascript heavy sites. 
>
> This is a bold premise :) 
>

Yes, I know it is bold. If you look at my three proposed features together, 
and think of a Django with these features included... I would definitely 
think that building javascript applications would be much easier. That's 
how I think of this. 

[snip] 
> > ... 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 %} 
>
> But your proposal keeps html and js separated. I think you are solving a 
> problem 
> for the one that just want to use a component but you are not solving the 
> problem for the one that is writing components. At least not in the 
> react.js 
> way, especially from such a bold premise :) 
>
 
I agree that I don't quite do it the same way as React. But that's not the 
point here either, to somehow bundle Reacts ideas inside Django. My point 
is that keeping the four parts that make a component closely together in 
the project source, would make for a better structure. They only idea that 
comes from React is thinking in components rather than nested templates and 
template tags, which are Django's current way of solving this.

So this is really a rather small suggestion, but that I think would make 
the component mindset fit better in with Django. Also, a lot of the code is 
already written in the Media class.

Thanks for taking the time to comment!

/E

-- 
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/9540de56-ba65-4309-96d7-be5eb216aea0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Support Server-Sent Events

[Emil Stenström]

Could you help me understand why this have to be done inside a web server 
container?

When I've previously read about reasons for that they tend to be things 
like "handling slow clients", something that an event loop is excellent at 
automatically. To me, this means that this process could run outside of all 
this, and simply be started with "python manage.py runsse 0.0.0.0:9000". 

Also, I don't think you would need to mix redis (or any other persistent 
storage) into this. The connected clients could simply be stored in an 
in-memory array, that is discarded if the server crashes. When the server 
is started again the clients will automatically connect again, and the list 
of clients would be built up again.

On Sunday, 31 May 2015 09:40:43 UTC+2, Roberto De Ioris wrote:
>
>
> > On Sun, May 31, 2015 at 1:23 AM, Roberto De Ioris  > 
> > wrote: 
> >> I obviously agree, but take in account that this uWSGI plugin 
> simplified 
> >> the steps a lot: 
> >> 
> >> https://github.com/unbit/uwsgi-sse-offload 
> > 
> > 
> > nice.  it certainly looks cleaner than having an external gevent 
> > process.  does it support sending messages to a specific subscriber 
> > (or subset of subscribers)? 
> > 
> > maybe the easiest way would be to set some variable either in the 
> > router or in the app view function and use it as part of the redis 
> > pubsub channel name. 
> > 
> > -- 
> > Javier 
> > 
>
> the channel name can be specified via variables, so it should be pretty 
> versatile from this point of view. The plugin is pretty tiny so if you 
> have ideas to improve it, feel free to open a github issue 
>
> -- 
> Roberto De Ioris 
> http://unbit.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0598ed1c-214c-4aec-b567-2704c0cbbd33%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Template Components

[Riccardo Magliocchetti]

Hi,

Il 30/05/2015 18:52, Emil Stenström ha scritto:

Hi,

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


This is a bold premise :)


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


This is a nice react.js introduction:
https://facebook.github.io/react/docs/thinking-in-react.html

[snip]

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


But your proposal keeps html and js separated. I think you are solving a problem 
for the one that just want to use a component but you are not solving the 
problem for the one that is writing components. At least not in the react.js 
way, especially from such a bold premise :)


thanks

--
Riccardo Magliocchetti
@rmistaken

http://menodizero.it

--
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/556AC614.5010604%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Support Server-Sent Events

[Roberto De Ioris]

> On Sun, May 31, 2015 at 1:23 AM, Roberto De Ioris 
> wrote:
>> I obviously agree, but take in account that this uWSGI plugin simplified
>> the steps a lot:
>>
>> https://github.com/unbit/uwsgi-sse-offload
>
>
> nice.  it certainly looks cleaner than having an external gevent
> process.  does it support sending messages to a specific subscriber
> (or subset of subscribers)?
>
> maybe the easiest way would be to set some variable either in the
> router or in the app view function and use it as part of the redis
> pubsub channel name.
>
> --
> Javier
>

the channel name can be specified via variables, so it should be pretty
versatile from this point of view. The plugin is pretty tiny so if you
have ideas to improve it, feel free to open a github issue

-- 
Roberto De Ioris
http://unbit.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/0aca01bc3ace1228b4a160300914b485.squirrel%40manage.unbit.it.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Support Server-Sent Events

[Javier Guerra Giraldez]

On Sun, May 31, 2015 at 1:23 AM, Roberto De Ioris  wrote:
> I obviously agree, but take in account that this uWSGI plugin simplified
> the steps a lot:
>
> https://github.com/unbit/uwsgi-sse-offload


nice.  it certainly looks cleaner than having an external gevent
process.  does it support sending messages to a specific subscriber
(or subset of subscribers)?

maybe the easiest way would be to set some variable either in the
router or in the app view function and use it as part of the redis
pubsub channel name.

-- 
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/CAFkDaoRZGi%3DVTk5_W%3Dk%3DWGcZ8zu%2BUyOnZwjLF4rWvpWV0QknVw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Support Server-Sent Events

[Roberto De Ioris]

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

I obviously agree, but take in account that this uWSGI plugin simplified
the steps a lot:

https://github.com/unbit/uwsgi-sse-offload

-- 
Roberto De Ioris
http://unbit.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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/f32688a1ec922e02ca91219c2d608412.squirrel%40manage.unbit.it.
For more options, visit https://groups.google.com/d/optout.