Re: Feature: Template Components

2015-06-02 Thread Sam Solomon
If someone actually wants to use it I can set aside some time within the
next week or two to actually open source the whole thing (docs + source on
github/pypi).

Here is an example of some of the basic functionality though:

*What the following code does:*
Creates a page for taking attendance of something that has 2 components, a
listing component that lists existing attendees and a entry component that
adds new people to the list.

We have javascript that disables the default form action and on form submit
submits via ajax. If there are errors, the form is displayed again with any
errors showing (over ajax), if there aren't errors, it resets the form and
also updates the listing component over ajax in a format like this (note,
though we haven't extended ourselves, it was made so that you could send
payloads other than "new_html" and make a custom handler for
"framework_example_attendance_entry" that could do something other than
simply dump new_html into the given div):
{
"actions": {
"framework_example_attendance_entry": {
"component_key": "framework_example_attendance_entry",
"new_html": "



Name:





",
"version": 1,
"js_failure_mode": "no_warn_no_update"
},
"framework_example_listing": {
"component_key": "framework_example_listing",
"new_html": "
George - Aug. 12, 2014, 1:46 p.m.
Smith - Aug. 12, 2014, 1:46 p.m.
Joseph - Aug. 12, 2014, 1:23 p.m. 
Steve - Aug. 12, 2014, 1:22 p.m.
John - Aug. 12, 2014, 1:22 p.m.
Andy - Aug. 12, 2014, 12:09 p.m.
Sam - Aug. 12, 2014, 11:13 a.m.
",
"version": 1,
"js_failure_mode": "no_warn_no_update"
}
}
}

*views.py:*

class AttendanceMixin(object):
# We encourage using Mixins that contain @obj_cache decorated methods
# that will (or in some cases may) be used by multiple components.
@obj_cache
def attendance_list(self):
return list(AttendanceRecord.objects.order_by('-id'))

@obj_cache
def num_attendees(self):
# This is free IFF we already need a list of attendees in the
# request, otherwise  we should be using
# `AttendanceRecord.objects.count()`

# Also note that it is fine to chain @obj_cache decorated methods.
return len(self.attendance_list)

class AttendanceEntryComponent(AttendanceMixin, Component):
template_name = "framework_example/entry_component.html"

def init(self):
self.ctx.this_form_url = self.this_url()

if not self.is_post():
self.ctx.attendance_form = AttendanceRecordForm(
**self.form_init())

def handler(self, request):
self.ctx.attendance_form = AttendanceRecordForm(request.POST,
**self.form_init())
if self.ctx.attendance_form.is_valid():
self.ctx.attendance_form.save()
self.ctx.attendance_form = AttendanceRecordForm(
**self.form_init())
self.add_dependent_component(AttendanceListingComponent)
return True

def final(self):
# The @obj_cache decorator turns methods into properties so note
# that this isn't `self.num_attendees()`
self.ctx.num_attendees = self.num_attendees

class AttendanceListingComponent(AttendanceMixin, Component):
template_name = "framework_example/listing_component.html"

def init(self):
self.ctx.attendance_list = self.attendance_list

class AttendancePage(Page):
template_name = "framework_example/attendance_page.html"

def set_components(self):
self.add_component(AttendanceListingComponent)

*urls.py:*
component_url(r'^attendance_listing/$',
  ComponentClass=AttendanceListingComponent,
  name="framework_example_listing"),
component_url(r'^$',
  ComponentClass=AttendanceEntryComponent,
  name="framework_example_attendance_entry",
  PageClass=AttendancePage),


*templates/framework_example/entry_component.html:*

Add a new attendee (Currently {{ num_attendees }} attending)


{% csrf_token %}
{{ attendance_form.as_p }}



*templates/framework_example/listing_component.html:*

{% for attendance_record in attendance_list %}

{{ attendance_record.name }} - {{
attendance_record.arrival_time }}

{% endfor %}


*templates/framework_example/attendance_page.html*

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

2015-06-02 Thread Lee Trout
I don't want to add any noise here- but I just had a chance to glance over
this conversation and I've basically been doing what Carl describes with
Angular. (In fact I joke often about calling it Djangular). I have a view
that prerenders angular templates (accepts the path to the template in the
url e.g. /views/renderng/path/to/ng/template.html) filling in data that is
available on the server and minimizing what I'm tracking in the scope in
Angular.

It's been working really well but I did have to change my Angular
interpolation provider start and end markers to [[ and ]]. So I have
templates similar to:

Hello {{ user.first_name }}
You have [[ data.points ]] points

Or to share a URL for a specific controller:




I also do as Carl suggested and smuggle data in script tags. This has been
useful when rendering the base template and sharing global URLs.


window.foo = {
urls: {
dataEndpointFoo: "{% url  "endpoint-foo" %}"
}
};



On Tue, Jun 2, 2015 at 3:05 PM, Emil Stenström  wrote:

> On Tuesday, 2 June 2015 20:31:41 UTC+2, Carl Meyer wrote:
>>
>> On 06/02/2015 11:53 AM, Emil Stenström wrote:
>> > I would love to see some code here if you have it available? How do you
>> > pass the JSON and the templates from the view to the client side?
>>
>> I don't have code I can share at the moment, but I'm hoping to blog
>> about this technique, and I'll let you know if/when I do.
>>
>
> Please do, and thanks again for sharing how you get this going. I
> subscribed to the oddbird blog, so if you post it there you don't have to
> tell me :)
>
> --
> 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/a34fff52-24df-4a54-a512-0553b0ffc322%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/CAABi-DpknKGODsVqW%2BSik-96JpBJcp3%3DZ0Wjk3NVpBPhA2e_5w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


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

2015-06-02 Thread Emil Stenström
On Tuesday, 2 June 2015 20:31:41 UTC+2, Carl Meyer wrote:
>
> On 06/02/2015 11:53 AM, Emil Stenström wrote: 
> > I would love to see some code here if you have it available? How do you 
> > pass the JSON and the templates from the view to the client side? 
>
> I don't have code I can share at the moment, but I'm hoping to blog 
> about this technique, and I'll let you know if/when I do. 
>

Please do, and thanks again for sharing how you get this going. I 
subscribed to the oddbird blog, so if you post it there you don't have to 
tell me :) 

-- 
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/a34fff52-24df-4a54-a512-0553b0ffc322%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2015-06-02 Thread Carl Meyer
Hi Emil,

On 06/02/2015 11:53 AM, Emil Stenström wrote:
> On Tuesday, 2 June 2015 19:06:35 UTC+2, Carl Meyer wrote:
> Using Jinja2 on the server and nunjucks on the client with shared
> templates works very well, is quite easy, and doesn't require
> Node.js on
> the server. I've been using this combination for a year and a half on
> several different projects and am quite happy with it.
>  
> I'm very happy to hear that this works in production. I picked nunjucks
> as an example just based on reading about it, but now I know that this
> is something that actually works. Thanks for that!
> 
> The primary discipline involved is ensuring that you only pass
> JSON-serializable objects to your templates (this is required for any
> template-sharing technique). In practice, this just means you need a
> full set of serializers and to use them consistently. The same
> serializers should be used in your server-side views and in your
> API, so
> the objects passed to your templates on the server and client side are
> the same. (I think using serializers and avoiding passing model
> instances/querysets directly into template contexts is a good practice
> anyway.)
>  
> I would love to see some code here if you have it available? How do you
> pass the JSON and the templates from the view to the client side?

I don't have code I can share at the moment, but I'm hoping to blog
about this technique, and I'll let you know if/when I do.

It's not very complicated, though. Data gets from server to client in
one of two ways: either it is rendered to a template on the server side
from a normal Django view and then returned as an HTML HTTP response, or
it is queried by the client using XMLHttpRequest from a JSON API and
then rendered in (possibly the same) template on the client side. The
key is that you use the same serializers in both cases. So in one
project, we're using Django Rest Framework and DRF serializers. A simple
view might look like this:

def person_detail(request, person_id):
person = get_object_or_404(Person, pk=person_id)
context = {
'person': PersonSerializer(person).data,
}
return render(request, 'person_detail.html.j2', context)

And then there's also a set of DRF API endpoints for Person, using the
same PersonSerializer, so JS can query that API via XHR, and render the
very same 'person_detail.html.j2' template (or more likely, a partial
included in that template) on the client side.

Or sometimes JSON (in the same format, from the same serializers) gets
pushed to the client via Websockets (or SSE I suppose, though I haven't
used SSE myself) for real-time updates, where it again can be used to
render the same templates.

The templates get to the client via nunjucks precompilation. Nunjucks
can compile Jinja2 templates to a file of plain JS code, and then that
file is referenced like any other static JS asset. (Precompilation is a
build step, it doesn't happen at runtime.) What you end up with is a JS
object mapping template paths to functions that you call with a context
and get back HTML (and it's quite fast, since there's no template
parsing at runtime).

It's also possible to do things like smuggle JSON data in a 

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

2015-06-02 Thread Emil Stenström


On Tuesday, 2 June 2015 19:06:35 UTC+2, Carl Meyer wrote:
>
> On 06/02/2015 05:54 AM, Aymeric Augustin wrote: 
>
 

> Using Jinja2 on the server and nunjucks on the client with shared 
> templates works very well, is quite easy, and doesn't require Node.js on 
> the server. I've been using this combination for a year and a half on 
> several different projects and am quite happy with it. 
>
 
I'm very happy to hear that this works in production. I picked nunjucks as 
an example just based on reading about it, but now I know that this is 
something that actually works. Thanks for that!

The primary discipline involved is ensuring that you only pass 
> JSON-serializable objects to your templates (this is required for any 
> template-sharing technique). In practice, this just means you need a 
> full set of serializers and to use them consistently. The same 
> serializers should be used in your server-side views and in your API, so 
> the objects passed to your templates on the server and client side are 
> the same. (I think using serializers and avoiding passing model 
> instances/querysets directly into template contexts is a good practice 
> anyway.) 
>
 
I would love to see some code here if you have it available? How do you 
pass the JSON and the templates from the view to the client side?

The main problem is that if you want to extend the template language 
> with custom tags/filters, you have to write these extensions twice. We 
> tend to accommodate this by just writing many fewer template language 
> extensions, doing more display-preparation work in serializers instead, 
> and relying on Jinja's built-in expressive power (e.g. macros) instead 
> of template language extensions. 
>

Yeah, I figured as much. I think that Django is in a better position here 
than other frameworks since actual python code in templates are discouraged.

-- 
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/cbcaced0-1def-49be-9816-5895442885fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2015-06-02 Thread Bobby Mozumder

> On Jun 2, 2015, at 2:43 AM, Emil Stenström  wrote:
> 
> On Tuesday, 2 June 2015 05:19:43 UTC+2, Bobby Mozumder wrote:
> At this point it’s probably easiest for Django to provide templates only for 
> Javascript front-end, and for Django to only serve API endpoints. 
> 
> We really don’t need Django to serve HTML pages anymore, except for the 
> initial page-load. 
> 
> In 2012, Twitter posted in their engineering blog about their conclusions of 
> trying to move all rendering to the client. It was just too slow. The answer, 
> and what is considered "best practice" now, is to render everything on the 
> server the first load, and render all subsequent page loads to the client. 
> This also means you get a nice fallback for clients that don't support 
> javascript.
> 

Yes, my expectation is that Django still only serves API endpoints, with 
something like Node.js & Ember Fastboot serving pages.

Ember's Fastboot would make for an ideal candidate as a starting point for a 
new design for Django’s template view layer.

-bobby

-- 
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/6C44F42E-9BDD-4DEE-A6F0-937E95D55C5E%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


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

2015-06-02 Thread Andrew Ingram
I feel we're getting a bit derailed here, but it seems I didn't explain
what I was doing well enough.

I'm saying that in both approaches I've used, I was authoring an isomorphic
React application - i.e. returning a fully-rendered html document with all
the React checksum IDs pre-populated. In my first approach I had a very
thin express server in node that passed request parameters to React Router,
which ultimately returned a rendered page. In my second approach, I had
Django hand over template context and request parameters to the node
process, which also returned the fully-rendered document. I picked the
second approach because it performed better to start with, but I prefer the
first approach in terms of how clean the stack is.

I'm a big fan of all the front-end work Facebook is putting out, I'm a
total convert, it's basically solved almost everything that's annoyed me
about web dev for the last 10 years. But Django has an excellent data
layer, and I want to keep using it if I can.

Andy



On 2 June 2015 at 18:17, Emil Stenström  wrote:

> On Tuesday, 2 June 2015 12:58:22 UTC+2, Andrew Ingram wrote:
>>
>> Based on my own experiences building isomorphic JavaScript apps with
>> Django, I haven't had any issues where I felt Django was getting in my way.
>> I've tackled the problem in two different ways, both of which worked
>> without any great difficulty:
>>
>
> I think the reason that Django has not been in the way here is that you
> have pushed it out of the way, and just reimplemented features that Django
> should have in javascript instead. I'm not saying this is bad for your
> project, it's just a shame that it's not something that Django can handle.
> More concretely:
>
> 1. The primary web-app is actually a node process. Everything you'd
>> consider a view is handled by React and React-Router, data requirements are
>> handled by making an HTTP request to Django REST Framework. This isn't
>> especially efficient, since the base response times aren't great when
>> you're depending on HTTP for data (this can obviously be improved by
>> getting the data via other channels).
>>
>
> Here you use routing and views from React instead of using Django. The
> problem with this is as you say latency since getting data is a HTTP
> request, but you also get slow initial load times since there's no content
> to show. Rendering on the server first to get a quick initial load, and
> then delegating to React would give us the best of both worlds.
>
>
>> 2. Use node purely as a rendering engine. I actually created an
>> alternative to TemplateResponseMixin that communicated with a node process
>> via zerorpc (chosen for the sake of simplicity) rather than rendering a
>> template from disk. This abstraction could be made neater by packaging it
>> up as a custom template engine that takes care of converting the data into
>> a format that zerorpc accepts (ie no querysets or rich objects). This
>> approach was significantly faster with base response times of about 8ms for
>> a simple page with no data dependencies, but I felt I was implementing my
>> routing logic twice (once in Django, once in node).
>>
>
> This sounds excellent. It's almost like implementing a new template
> engine, but instead just running it through node. The downside is that it
> requires you to install, deploy and maintain a separate javascript
> environment. What js template language were you using?
>
> I think implementing that same language for Django would give you the best
> of two worlds. All server-side rendering would remain like for any
> server-side app, but you could also send your templates to the view for
> fast client side rendering.
>
>
>> The second approach is easier to get running at acceptable performance
>> levels quickly, but is quite clunky to implement. Going forward I'm
>> probably going to favour the first approach, which essentially means
>> turning my Django projects into nothing more than a data layer, which is
>> fine for me because I've found that once you're using React (or similar)
>> heavily, you're not using much else from Django anyway.
>>
>
> Did you read the Twitter post on this (
> https://blog.twitter.com/2012/improving-performance-on-twittercom)? They
> went the same route, moving all template logic to the client, found it was
> too slow on initial load, and then favoured the dual approach I'm hoping
> for.
>
> --
> 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/da6ffda5-b6b0-4d41-91f0-d6101a3ddd2d%40googlegroups.com
> 

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

2015-06-02 Thread Emil Stenström
On Tuesday, 2 June 2015 13:54:44 UTC+2, Aymeric Augustin wrote:
>
> 2015-05-30 17:52 GMT+01:00 Emil Stenström :
>
>> 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 a javascript template language on the server

2015-06-02 Thread Emil Stenström
On Tuesday, 2 June 2015 12:58:22 UTC+2, Andrew Ingram wrote:
>
> Based on my own experiences building isomorphic JavaScript apps with 
> Django, I haven't had any issues where I felt Django was getting in my way. 
> I've tackled the problem in two different ways, both of which worked 
> without any great difficulty:
>

I think the reason that Django has not been in the way here is that you 
have pushed it out of the way, and just reimplemented features that Django 
should have in javascript instead. I'm not saying this is bad for your 
project, it's just a shame that it's not something that Django can handle. 
More concretely:

1. The primary web-app is actually a node process. Everything you'd 
> consider a view is handled by React and React-Router, data requirements are 
> handled by making an HTTP request to Django REST Framework. This isn't 
> especially efficient, since the base response times aren't great when 
> you're depending on HTTP for data (this can obviously be improved by 
> getting the data via other channels).
>

Here you use routing and views from React instead of using Django. The 
problem with this is as you say latency since getting data is a HTTP 
request, but you also get slow initial load times since there's no content 
to show. Rendering on the server first to get a quick initial load, and 
then delegating to React would give us the best of both worlds.
 

> 2. Use node purely as a rendering engine. I actually created an 
> alternative to TemplateResponseMixin that communicated with a node process 
> via zerorpc (chosen for the sake of simplicity) rather than rendering a 
> template from disk. This abstraction could be made neater by packaging it 
> up as a custom template engine that takes care of converting the data into 
> a format that zerorpc accepts (ie no querysets or rich objects). This 
> approach was significantly faster with base response times of about 8ms for 
> a simple page with no data dependencies, but I felt I was implementing my 
> routing logic twice (once in Django, once in node).
>

This sounds excellent. It's almost like implementing a new template engine, 
but instead just running it through node. The downside is that it requires 
you to install, deploy and maintain a separate javascript environment. What 
js template language were you using?

I think implementing that same language for Django would give you the best 
of two worlds. All server-side rendering would remain like for any 
server-side app, but you could also send your templates to the view for 
fast client side rendering.
 

> The second approach is easier to get running at acceptable performance 
> levels quickly, but is quite clunky to implement. Going forward I'm 
> probably going to favour the first approach, which essentially means 
> turning my Django projects into nothing more than a data layer, which is 
> fine for me because I've found that once you're using React (or similar) 
> heavily, you're not using much else from Django anyway.
>
 
Did you read the Twitter post on this 
(https://blog.twitter.com/2012/improving-performance-on-twittercom)? They 
went the same route, moving all template logic to the client, found it was 
too slow on initial load, and then favoured the dual approach I'm hoping 
for.

-- 
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/da6ffda5-b6b0-4d41-91f0-d6101a3ddd2d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2015-06-02 Thread Carl Meyer
On 06/02/2015 05:54 AM, Aymeric Augustin wrote:
> 2015-05-30 17:52 GMT+01:00 Emil Stenström >:
[snip]
> 2. A template language that has a solid javascript implementation.
> To be able to render the templates the server side and client side
> must use the same language. I see two options here, either make sure
> the Jinja flavor we are supporting works with JS templatations
> (maybe https://mozilla.github.io/nunjucks/ ?), or get a handlebars
> implementation working with Django (https://github.com/wbond/pybars3
> ?). Or maybe there's some third option I didn't think of...
> 
> 
> To achieve this goal, I think Andrew Ingram's second suggestion is the
> easiest solution since Django 1.8: implement a template engine that
> hands over data to a Node.js process, lets it render the template, gets
> the HTML back, and returns it.
> 
> That's a good candidate for a pluggable application. It will probably
> have some specific deployment instructions ("run this Node.js next to
> your Django...)

I'm sure this Node-daemon technique is workable (I know of at least one
project already using it), but I'm not sure it's the easiest option.
Using Jinja2 on the server and nunjucks on the client with shared
templates works very well, is quite easy, and doesn't require Node.js on
the server. I've been using this combination for a year and a half on
several different projects and am quite happy with it.

The primary discipline involved is ensuring that you only pass
JSON-serializable objects to your templates (this is required for any
template-sharing technique). In practice, this just means you need a
full set of serializers and to use them consistently. The same
serializers should be used in your server-side views and in your API, so
the objects passed to your templates on the server and client side are
the same. (I think using serializers and avoiding passing model
instances/querysets directly into template contexts is a good practice
anyway.)

The main problem is that if you want to extend the template language
with custom tags/filters, you have to write these extensions twice. We
tend to accommodate this by just writing many fewer template language
extensions, doing more display-preparation work in serializers instead,
and relying on Jinja's built-in expressive power (e.g. macros) instead
of template language extensions.

Carl

-- 
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/556DE287.7050808%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature


Re: Feature: Support Server-Sent Events

2015-06-02 Thread Emil Stenström
Hi,

On Tuesday, 2 June 2015 11:25:14 UTC+2, Andrew Godwin wrote:
>
> Hi Emil,
>
> I agree that there perhaps needs to be a more "pull" here than just making 
> a third party app, but I feel I can speak from a good place when I say 
> third party apps can absolutely prove core Django features in a way that 
> gives them much faster release cycles and freedom from things like LTS 
> commitments initially, so they can be rapidly improved upon before being 
> deemed worth merging. The alternative is either merging something into core 
> that's not ready, dooming it to a slow release cycle and perhaps community 
> pushback, or developing it as a parallel branch which is not something 
> that's going to be long-term sustainable.
>

With "pull" I mean someone saying "I think this is something that would fit 
well with Django, given that it's implemented in a way that satisfied X, Y 
and Z". I'm of course not saying "merge my code now" when there is no code 
:) So this should definitely be a third party app first.

I also see how you must have great trust in the model that South was 
developed under. You built something great, *everyone* started using it, 
you put down months of work into rewriting it for Django, and it's now part 
of the handful (?) of third party projects that made it into core. So it is 
possible, but just not very likely.
 

> This problem has been something I've been wanting to tackle for a while 
> now - I've always felt that the next step for Django is to start moving 
> away from being so married to the request-response cycle of traditional 
> HTTP - and I've been formulating a plan over the last few months about how 
> to tackle it. It's relatively ambitious, but I think entirely achievable 
> and would be almost completely backwards-compatible. Unfortunately, it's 
> taken a while to get over the 1.7 release cycle and migrations work being 
> slightly overwhelming, or it would have been sooner.
>

Hearing that you are interested in working on the "async problem" makes me 
very happy. And solving async "generally" would of course satisfy the same 
problem I'm hoping to solve with my parallel process approach. Really 
looking forward to this.
 

> I'm sounding out some of the ideas here at DjangoCon Europe, and hopefully 
> come to the list with an initial proposal or implementation soon - I think 
> the best way to approach this is to sit down and design the API and core 
> code architecture, start proving it's possible, and then present that, 
> because in my experience having code examples can really make a proposal a 
> lot easier to understand. Of course, I'm also fully prepared for people to 
> shoot down my ideas - being a core team member doesn't give me some magical 
> ability to push through changes.
>

 I'll take the code example lesson with me for next time :) Looking forward 
to read you proposal.

-- 
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/c9117ec9-de61-4480-a09a-8d648e7ecbc8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2015-06-02 Thread Aymeric Augustin
2015-06-02 12:54 GMT+01:00 Aymeric Augustin <
aymeric.augus...@polytechnique.org>:

> implement a template engine that hands over data to a Node.js process,
> lets it render the template, gets the HTML back, and returns it.


If someone wants to try this, https://github.com/markfinger/python-react
may me a good starting point.

-- 
Aymeric.

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


Re: URL namespaces

2015-06-02 Thread Marten Kenbeek
The admin proves problematic. Looking at the uses of `AdminSite.name`, it's 
not easily replaced. There are quite a few places that use the name to 
reverse urls, but don't have access to the request and the current 
namespace. I think the best solution for now is to document that you should 
pass `admin.site.urls` directly to `url()`. `include()` does a bunch of 
stuff, but none of it is needed in the case of the admin urls. This allows 
the new `include()` API to be as intended, but it doesn't put an 
unnecessary burden of providing the "correct" namespace for an admin 
instance on the end-developer. 

In time I'd like to see a method on the AdminSite that returns an actual 
resolver object, using the new API. The default URLconf template would 
simply look something like this:

urlpatterns = [
admin.site.get_resolver('^admin/'),  # or 
get_resolver(RegexPattern('^admin/')) to be more explicit
]

This would solve the namespace issue for the admin, but it would still 
allow for only obvious way to set the instance namespace, and keep the 
`include()` API clean.

Op zaterdag 30 mei 2015 14:28:22 UTC+2 schreef Tai Lee:
>
> 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.
>

Not providing an option in the API itself is the best we can do to disallow 
it. But yes, always setting the current_app would avoid a lot of 
problems. https://code.djangoproject.com/ticket/24127 proposes just that. 

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

I don't think it's necessary to introduce another global state. At the 
moment there are a few places in the admin that use the name but don't have 
access to the request, this works fine as it is, and if need be these can 
be reworked so that the current app is passed down to these methods too. 
The other place where this would help is `get_absolute_url()`. This only 
adds to the list of why I don't like that method, and I personally don't 
find it a compelling argument for introducing a global state for the 
current app.

I think setting the current_app on request by default is a better solution 
that works in most cases. The only apparent issue is backwards 
compatibility, I'm still looking for the best way to solve this. 

-- 
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/648e907a-6d58-44a4-b854-a7a8cba860ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2015-06-02 Thread Aymeric Augustin
Hello Emil,

2015-05-30 17:52 GMT+01:00 Emil Stenström :

> 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 a javascript template language on the server

2015-06-02 Thread Andrew Ingram
Based on my own experiences building isomorphic JavaScript apps with
Django, I haven't had any issues where I felt Django was getting in my way.
I've tackled the problem in two different ways, both of which worked
without any great difficulty:

1. The primary web-app is actually a node process. Everything you'd
consider a view is handled by React and React-Router, data requirements are
handled by making an HTTP request to Django REST Framework. This isn't
especially efficient, since the base response times aren't great when
you're depending on HTTP for data (this can obviously be improved by
getting the data via other channels).
2. Use node purely as a rendering engine. I actually created an alternative
to TemplateResponseMixin that communicated with a node process via zerorpc
(chosen for the sake of simplicity) rather than rendering a template from
disk. This abstraction could be made neater by packaging it up as a custom
template engine that takes care of converting the data into a format that
zerorpc accepts (ie no querysets or rich objects). This approach was
significantly faster with base response times of about 8ms for a simple
page with no data dependencies, but I felt I was implementing my routing
logic twice (once in Django, once in node).

The second approach is easier to get running at acceptable performance
levels quickly, but is quite clunky to implement. Going forward I'm
probably going to favour the first approach, which essentially means
turning my Django projects into nothing more than a data layer, which is
fine for me because I've found that once you're using React (or similar)
heavily, you're not using much else from Django anyway.

Andy



On 2 June 2015 at 07:43, Emil Stenström  wrote:

> On Tuesday, 2 June 2015 05:19:43 UTC+2, Bobby Mozumder wrote:
>>
>> At this point it’s probably easiest for Django to provide templates only
>> for Javascript front-end, and for Django to only serve API endpoints.
>>
>> We really don’t need Django to serve HTML pages anymore, except for the
>> initial page-load.
>>
>
> In 2012, Twitter posted in their engineering blog about their conclusions
> of trying to move all rendering to the client. It was just too slow. The
> answer, and what is considered "best practice" now, is to render everything
> on the server the first load, and render all subsequent page loads to the
> client. This also means you get a nice fallback for clients that don't
> support javascript.
>
> --
> 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/783577b2-79f4-4445-81de-3208a16037a4%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/CAOA51CX1Or0XDbtpEpN%2BZmwE3ExDG5c5nihfwR0vnWG4_CkLQw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Feature: Support Server-Sent Events

2015-06-02 Thread Andrew Godwin
Hi Emil,

I agree that there perhaps needs to be a more "pull" here than just making
a third party app, but I feel I can speak from a good place when I say
third party apps can absolutely prove core Django features in a way that
gives them much faster release cycles and freedom from things like LTS
commitments initially, so they can be rapidly improved upon before being
deemed worth merging. The alternative is either merging something into core
that's not ready, dooming it to a slow release cycle and perhaps community
pushback, or developing it as a parallel branch which is not something
that's going to be long-term sustainable.

This problem has been something I've been wanting to tackle for a while now
- I've always felt that the next step for Django is to start moving away
from being so married to the request-response cycle of traditional HTTP -
and I've been formulating a plan over the last few months about how to
tackle it. It's relatively ambitious, but I think entirely achievable and
would be almost completely backwards-compatible. Unfortunately, it's taken
a while to get over the 1.7 release cycle and migrations work being
slightly overwhelming, or it would have been sooner.

I'm sounding out some of the ideas here at DjangoCon Europe, and hopefully
come to the list with an initial proposal or implementation soon - I think
the best way to approach this is to sit down and design the API and core
code architecture, start proving it's possible, and then present that,
because in my experience having code examples can really make a proposal a
lot easier to understand. Of course, I'm also fully prepared for people to
shoot down my ideas - being a core team member doesn't give me some magical
ability to push through changes.

Andrew

On Mon, Jun 1, 2015 at 11:11 PM, Emil Stenström  wrote:

> Thanks for you reply Andrew,
>
> On Monday, 1 June 2015 13:05:34 UTC+2, Andrew Godwin wrote:
>>
>> Just to chime in here - I've long been in favour of some kind of support
>> for event-driven stuff inside Django, but as Curtis is saying, there's
>> nothing here that couldn't be done in a third party app first and then
>> proven there before any possible merge into core.
>>
>
> That seems to be the argument for all my three suggestions: Build it as a
> third party app, and if you get everyone using your three apps we might
> consider adding them to Django. I was hoping for a more "product driven"
> approach, where we look at the world around us, see that Django is lagging
> behind in a major area for modern apps, and start playing around with
> different ways of tackling the problem. Given that there are people that
> agree this is a problem for Django, I was hoping for more of a "pull" from
> the community. "We want something that solves this problem, this way,
> without doing this".
>
> I also don't think that this proposal goes far enough, in a way - any push
>> for a system that allows asychronous calling like this should be available
>> to the request-response cycle as well as websocket/push clients (I want the
>> ability to make my database calls in parallel with my external API calls,
>> perhaps). I have some ideas down this path, but even those are the sort of
>> thing that need a couple of changes to Django to make things work smoothly
>> but the bulk can be implemented outside.
>>
>
> I agree that this would be great, but given that Django won't be rewritten
> to support async everything any time soon I think this will be a far to big
> first step. In my experience, starting small and iterating is a much better
> way to get great things going. And my subset of server->client message
> passing is just that.
>
> If there's specific things Django needs changed to support this properly,
>> I'm all ears, but I'm not sure we should just lump a certain pattern of
>> socket worker in core straight away.
>>
>
> "Lumping something in" is not something in is not something I've
> suggested. I'm fully prepared that this will take time and effort.
>
> --
> 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/4bbf9e68-b1b8-4701-bca7-eb062626e94b%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 

Re: Idea: Better support for javascript heavy sites

2015-06-02 Thread Emil Stenström
My conclusions to all the feedback in the three different threads are this:

   - You don't agree about the general need to support heavier javascript 
   apps "out of the box" in Django
   - You are open to discussion about specific features being added...
   - ... but to be considered here they first need to be extremely popular 
   in the community (see South)
   
I will still start working on these features as third party apps, we'll see 
where this goes.

On Saturday, 30 May 2015 18:55:54 UTC+2, Emil Stenström wrote:
>
>
> 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/4b80aac2-a809-487a-8070-b38620303e77%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Feature: Template Components

2015-06-02 Thread Emil Stenström
On Monday, 1 June 2015 19:12:36 UTC+2, Sam Solomon wrote:
>
> So a former co-worker with some help/guidance from me developed a 
> component system on top of Django that sounds sorta like what you are all 
> talking about. It's very complicated and I'm still not sure whether it was 
> ultimately a good idea to use or not, but it does make some things very 
> simple (and we have no plans to move away from it at this point after ~2 
> years of use). I'll post some snippets from our internal docs on it now and 
> if people are interested, I can explain more and possibly open source it 
> 
>

Interesting! I would definitely want to see some code examples here. Could 
you show me how me more about how it works? 

-- 
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/5e562720-9484-4e4f-9507-129d55a4cfce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Feature: Template Components

2015-06-02 Thread Emil Stenström
On Monday, 1 June 2015 03:32:26 UTC+2, Rotund wrote:
>
> 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.
>

Thanks! And I definitely think this should be developed as a separate 
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).
>

I've been in the community a long while, so I know how things usually work. 
My hope for this is that there would be a strong need in the community to 
solve these kinds of problems. This doesn't mean that the process will be 
any different, or take less time.
 

> 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.
>
 
This is a neat idea and I would really want to read those blog posts. Maybe 
that's the way to go.

I don't see my set of ideas to be THAT opinionated. None of them force you 
to change your existing sites. I see them as tools, that someone that needs 
heavier javascript features will definitely need. 

-- 
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/d6499ef5-b0d3-4ffb-9deb-77148e9386a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2015-06-02 Thread Emil Stenström
On Tuesday, 2 June 2015 05:19:43 UTC+2, Bobby Mozumder wrote:
>
> At this point it’s probably easiest for Django to provide templates only 
> for Javascript front-end, and for Django to only serve API endpoints. 
>
> We really don’t need Django to serve HTML pages anymore, except for the 
> initial page-load. 
>

In 2012, Twitter posted in their engineering blog about their conclusions 
of trying to move all rendering to the client. It was just too slow. The 
answer, and what is considered "best practice" now, is to render everything 
on the server the first load, and render all subsequent page loads to the 
client. This also means you get a nice fallback for clients that don't 
support javascript.

-- 
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/783577b2-79f4-4445-81de-3208a16037a4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2015-06-02 Thread Emil Stenström
On Monday, 1 June 2015 18:09:00 UTC+2, Javier Guerra wrote:
>
> I think that Enrique means that having "the same" template language is 
> a non-goal.  the "cognitive burden" of two languages is not so heavy; 
>

I really don't agree with this. Think of beginners learning how to build a 
modern website. Either they learn both Django templates and handlebars.js, 
or just ONE language. Of course the cognitive burden is much heavier than 
learning only one language.
 

> and since these two environments are so different, there would be 
> different considerations that make some features unpractical on one 
> side or the other; or maybe some choice could be "the best" on one and 
> too awkward or badly supported on the other. 
>

I don't think the environments are so different. Unless you are breaking 
best practices and doing ORM calls in your custom template tags the point 
of both languages are the same: Take a dictionary and turn it into HTML by 
looping and including subtemplates. It's a very similar problem.
 

> personally, i mostly agree: i do use templating on JS, and it doesn't 
> look at all like Django templates.  That means sometimes i render some 
> things in the server, other things in the front end, and a few things 
> (very few) on both, leading to mostly duplicate code.  would it be 
> nice to have some code that works equally well on either side? yes, 
> but it's a relatively small gain. 
>
 
Having one language would make things like this much easier. And as with 
must easy to use things, you would likely use it more often, leading to 
sites that are more responsive and easier to use.

if "using the same language" was so important, we would all be using 
> node.js... 
>
 
Did you see Geoff Schmids presentation on Meteor.js on DjangoCon 2012? 
https://www.youtube.com/watch?v=34_oKFx43O4

People are switching to JS just because of "isomorphism", being able to 
avoid duplicate code.

-- 
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/52c26579-dc75-4089-b1f2-d38a09300875%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.