Re: Feature: Template Components

[Unai Zalakain]

Finally someone expressed my own feelings about it perfectly :D

On Sun, May 31, 2015 at 08:32:18PM -0500, Joe Tennies 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.

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 unsubscribe from this group and stop rece

Re: Fate of sql* management commands

[Marcin Nowak]

On Sunday, May 31, 2015 at 1:47:32 AM UTC+2, Tim Graham wrote:
>
> They were dropped as part of the removal of the old code that supported 
> syncing apps without migrations.
>

But you removed a feature, not just old code. 
In v1.8 (1.7 maybe?) this feature was broken (issue #24876) and it was 
completely removed in master (issue #24481).
This is not good.
 

>
> By the way, I suspect this could be implemented as a third-party app if 
> there is opposition to including it in Django itself. 
>
 
I know I can reimplement it myself, but core feature should be nearest to 
core source code, because it highly depends on internals.
This can be provided as a contrib app, for example. 

Why contrib.gis is supported for years? This app is used rarely. In 
contrast to gis - we generate/create SQLs every day. 
I don't know what you're doing with Django, but latests changes looks 
fearfull.. :(

/BR
Marcin

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

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

[Tom Evans]

On Sat, May 30, 2015 at 5: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.

ISTM that django already provides all these "options" (you are clearly
slanting the view that "options" 1 and 2 are rubbish and only option 3
is a the valid choice..). Pluggable template engines landed in 1.8,
read here for extensive details:

https://myks.org/en/multiple-template-engines-for-django/

With pluggable template engines, is there anything else required in
Django core to plug in whatever template language your project
requires?

Cheers

Tom

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

Re: Feature: Support Server-Sent Events

[Andrew Godwin]

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.

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.

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.

Andrew

On Mon, Jun 1, 2015 at 12:42 AM, Curtis Maloney 
wrote:

> 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 (Contri

Django banking packages

[Swapnil Bhadade]

Which are Django packages for full stack development of an e-banking web 
app  Any resources / frameworks would be of help.
Best

-- 
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/146810a4-c45c-4664-9193-15ed9961080b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fate of sql* management commands

[Tim Graham]

As far as justification for dropping the old commands:

1. Andrew said earlier in the thread, "the sqlmigrate command will still 
get you SQL from migrations, though it sadly lacks the ability to take a 
range of migrations, optimise them down, and output the SQL for _that_ - 
that's probably the best thing for us to aim towards, and will almost 
entirely recreate the functionality of sqlall without actually being wrong 
(sqlall doesn't understand things like data migrations or custom SQL 
sections of migrations, and so will sadly be wrong in if you have anything 
like a moderately complex migration set)."

2. The sql* commands that were removed relied on SQL generation code in 
django/db/backends/base/creation.py and has been superseded by similar 
functionality in schema.py (and removed in 1.9). Django shouldn't maintain 
two ways of generating SQL for models.

We welcome your contribution if you can form a consensus on a proposal.

On Monday, June 1, 2015 at 4:00:14 AM UTC-4, Marcin Nowak wrote:
>
>
> On Sunday, May 31, 2015 at 1:47:32 AM UTC+2, Tim Graham wrote:
>>
>> They were dropped as part of the removal of the old code that supported 
>> syncing apps without migrations.
>>
>
> But you removed a feature, not just old code. 
> In v1.8 (1.7 maybe?) this feature was broken (issue #24876) and it was 
> completely removed in master (issue #24481).
> This is not good.
>  
>
>>
>> By the way, I suspect this could be implemented as a third-party app if 
>> there is opposition to including it in Django itself. 
>>
>  
> I know I can reimplement it myself, but core feature should be nearest to 
> core source code, because it highly depends on internals.
> This can be provided as a contrib app, for example. 
>
> Why contrib.gis is supported for years? This app is used rarely. In 
> contrast to gis - we generate/create SQLs every day. 
> I don't know what you're doing with Django, but latests changes looks 
> fearfull.. :(
>
> /BR
> Marcin
>

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

Re: Django banking packages

[Michael Manfre]

This group is for the discussion of developing the Django framework.
Discussions and questions related to using Django should take place on the
django-users group.

Regards,
Michael Manfre

On Mon, Jun 1, 2015, 7:11 AM Swapnil Bhadade 
wrote:

> Which are Django packages for full stack development of an e-banking web
> app  Any resources / frameworks would be of help.
> Best
>
> --
> 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/146810a4-c45c-4664-9193-15ed9961080b%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/CAGdCwBuBbhtnSztv_fPys%2BLoUBbzM7h0PdmNedC_FTQWRb7UBg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Django banking packages

[Tim Graham]

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

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

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

On Monday, June 1, 2015 at 7:11:04 AM UTC-4, Swapnil Bhadade wrote:
>
> Which are Django packages for full stack development of an e-banking web 
> app  Any resources / frameworks would be of help.
> Best
>

-- 
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/95548392-479e-4fc3-a296-7cd7a139cefb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Tim Graham]

I put together a draft proposal in the form of a potential 
djangoproject.com blog post. I've enabled commenting in case you have minor 
cosmetic comments, but please keep discussion about the content of the 
proposal itself on this mailing list. Also, please let me know of any 
additional questions or complaints that you'd like to see addressed in the 
last section.

The overview is:
* New major release every 8 months
* New long-term support release every 2 years. LTS releases continue to be 
supported with security updates for 3 years.
* Adjust the deprecation policy to make it easier for third-party apps to 
support all versions back to the last LTS.

https://docs.google.com/document/d/1bC6A8qc4skCmlagOnp8U7ddgyC-1XxXCBTlgrW690i0/edit?usp=sharing

On Tuesday, April 7, 2015 at 3:20:55 PM UTC-4, Collin Anderson wrote:
>
> On Tuesday, April 7, 2015 at 2:31:08 PM UTC-4, Asif Saifuddin wrote:
>>
>> How about
>>
>> a 8 month release cycle and having a LTS in every two years and 
>> supporting the old LTS atleast 3 years from the release date? there will be 
>> 3 version between two LTS.
>>
>
> Interesting. I like the idea of having predictable release dates.
>

-- 
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/5e38433f-f499-483c-88aa-0d2744fad9cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Asif Saifuddin]

thats great!!!

On Mon, Jun 1, 2015 at 7:20 PM, Tim Graham  wrote:

> I put together a draft proposal in the form of a potential
> djangoproject.com blog post. I've enabled commenting in case you have
> minor cosmetic comments, but please keep discussion about the content of
> the proposal itself on this mailing list. Also, please let me know of any
> additional questions or complaints that you'd like to see addressed in the
> last section.
>
> The overview is:
> * New major release every 8 months
> * New long-term support release every 2 years. LTS releases continue to be
> supported with security updates for 3 years.
> * Adjust the deprecation policy to make it easier for third-party apps to
> support all versions back to the last LTS.
>
>
> https://docs.google.com/document/d/1bC6A8qc4skCmlagOnp8U7ddgyC-1XxXCBTlgrW690i0/edit?usp=sharing
>
> On Tuesday, April 7, 2015 at 3:20:55 PM UTC-4, Collin Anderson wrote:
>>
>> On Tuesday, April 7, 2015 at 2:31:08 PM UTC-4, Asif Saifuddin wrote:
>>>
>>> How about
>>>
>>> a 8 month release cycle and having a LTS in every two years and
>>> supporting the old LTS atleast 3 years from the release date? there will be
>>> 3 version between two LTS.
>>>
>>
>> Interesting. I like the idea of having predictable release dates.
>>
>  --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/MTvOPDNQXLI/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/5e38433f-f499-483c-88aa-0d2744fad9cb%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/CAKAqTgqNARxgzJ48W_tcY5Frk0Z01TzXJEjg6W3QtnCuAHkj4g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Collin Anderson]

1.8 - April 2015 (LTS): Dropped features deprecated in 1.6 [1.6 no longer 
supported].
1.9 - Dec. 2015: Drop features deprecated in 1.7 [1.7 no longer supported].
2.0 - Aug. 2016: No features dropped.
2.1 - April 2017 (LTS): Drop features deprecated in 1.8, 1.9 [1.9 no longer 
supported, third party apps can update to support 2.0 as a minimum version; 
1.8 users should use an old version of the third-party app for the ~1 year 
until 1.8 is unsupported].
2.2 - Dec. 2017: Drop features deprecated in 2.0 [2.0 no longer supported].

This is awesome.

So why not to have 2.0 drop features features deprecated in 1.8? If the 
replacement pattern/feature is available in 1.8, the 3rd party app should 
be able to use the new feature to stay compatible, right? If anything I'd 
like to see us hold off on dropping features deprecated in 1.9 until after 
the LTS to help people migrate between LTSs.

Thanks,
Collin


On Monday, June 1, 2015 at 9:20:07 AM UTC-4, Tim Graham wrote:
>
> I put together a draft proposal in the form of a potential 
> djangoproject.com blog post. I've enabled commenting in case you have 
> minor cosmetic comments, but please keep discussion about the content of 
> the proposal itself on this mailing list. Also, please let me know of any 
> additional questions or complaints that you'd like to see addressed in the 
> last section.
>
> The overview is:
> * New major release every 8 months
> * New long-term support release every 2 years. LTS releases continue to be 
> supported with security updates for 3 years.
> * Adjust the deprecation policy to make it easier for third-party apps to 
> support all versions back to the last LTS.
>
>
> https://docs.google.com/document/d/1bC6A8qc4skCmlagOnp8U7ddgyC-1XxXCBTlgrW690i0/edit?usp=sharing
>
> On Tuesday, April 7, 2015 at 3:20:55 PM UTC-4, Collin Anderson wrote:
>>
>> On Tuesday, April 7, 2015 at 2:31:08 PM UTC-4, Asif Saifuddin wrote:
>>>
>>> How about
>>>
>>> a 8 month release cycle and having a LTS in every two years and 
>>> supporting the old LTS atleast 3 years from the release date? there will be 
>>> 3 version between two LTS.
>>>
>>
>> Interesting. I like the idea of having predictable release dates.
>>
>

-- 
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/74456b73-2405-4484-8182-6f880f998752%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Tim Graham]

If we dropped 1.8 deprecated features in 2.0, then it would require 
libraries to add conditional code to support both the old and new ways of 
doing something. The idea is that a third-party app wouldn't need to make 
any updates (except those needed to accommodate for backwards incompatible 
changes) until the next LTS release.

The idea is *not* to suggest apps should try to support two LTS releases. 
Making that easy on Django's end would require keeping deprecated features 
in Django significantly longer than this proposal. See Carl's post in the 
thread where we discussed the deprecation cycle changes: 
https://groups.google.com/d/msg/django-developers/qCjfOu-FPxQ/hccAcVChHMkJ

On Monday, June 1, 2015 at 10:20:13 AM UTC-4, Collin Anderson wrote:
>
> 1.8 - April 2015 (LTS): Dropped features deprecated in 1.6 [1.6 no longer 
> supported].
> 1.9 - Dec. 2015: Drop features deprecated in 1.7 [1.7 no longer supported].
> 2.0 - Aug. 2016: No features dropped.
> 2.1 - April 2017 (LTS): Drop features deprecated in 1.8, 1.9 [1.9 no 
> longer supported, third party apps can update to support 2.0 as a minimum 
> version; 1.8 users should use an old version of the third-party app for the 
> ~1 year until 1.8 is unsupported].
> 2.2 - Dec. 2017: Drop features deprecated in 2.0 [2.0 no longer supported].
>
> This is awesome.
>
> So why not to have 2.0 drop features features deprecated in 1.8? If the 
> replacement pattern/feature is available in 1.8, the 3rd party app should 
> be able to use the new feature to stay compatible, right? If anything I'd 
> like to see us hold off on dropping features deprecated in 1.9 until after 
> the LTS to help people migrate between LTSs.
>
> Thanks,
> Collin
>
>
> On Monday, June 1, 2015 at 9:20:07 AM UTC-4, Tim Graham wrote:
>>
>> I put together a draft proposal in the form of a potential 
>> djangoproject.com blog post. I've enabled commenting in case you have 
>> minor cosmetic comments, but please keep discussion about the content of 
>> the proposal itself on this mailing list. Also, please let me know of any 
>> additional questions or complaints that you'd like to see addressed in the 
>> last section.
>>
>> The overview is:
>> * New major release every 8 months
>> * New long-term support release every 2 years. LTS releases continue to 
>> be supported with security updates for 3 years.
>> * Adjust the deprecation policy to make it easier for third-party apps to 
>> support all versions back to the last LTS.
>>
>>
>> https://docs.google.com/document/d/1bC6A8qc4skCmlagOnp8U7ddgyC-1XxXCBTlgrW690i0/edit?usp=sharing
>>
>> On Tuesday, April 7, 2015 at 3:20:55 PM UTC-4, Collin Anderson wrote:
>>>
>>> On Tuesday, April 7, 2015 at 2:31:08 PM UTC-4, Asif Saifuddin wrote:

 How about

 a 8 month release cycle and having a LTS in every two years and 
 supporting the old LTS atleast 3 years from the release date? there will 
 be 
 3 version between two LTS.

>>>
>>> Interesting. I like the idea of having predictable release dates.
>>>
>>

-- 
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/acf37866-7a8c-4077-a399-0627acddd885%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 1.9 release planning

[Collin Anderson]

I see. I missed the "first upgrade Django to the last release before the 
next 
LTS (e.g. upgrade 1.8->1.9->2.0), then upgrade your dependencies to the 
newer version that supports both 2.0 and 2.1, and then finally upgrade 
to 2.1." part.

Thanks,
Collin

On Monday, June 1, 2015 at 11:02:01 AM UTC-4, Tim Graham wrote:
>
> If we dropped 1.8 deprecated features in 2.0, then it would require 
> libraries to add conditional code to support both the old and new ways of 
> doing something. The idea is that a third-party app wouldn't need to make 
> any updates (except those needed to accommodate for backwards incompatible 
> changes) until the next LTS release.
>
> The idea is *not* to suggest apps should try to support two LTS releases. 
> Making that easy on Django's end would require keeping deprecated features 
> in Django significantly longer than this proposal. See Carl's post in the 
> thread where we discussed the deprecation cycle changes: 
> https://groups.google.com/d/msg/django-developers/qCjfOu-FPxQ/hccAcVChHMkJ
>
> On Monday, June 1, 2015 at 10:20:13 AM UTC-4, Collin Anderson wrote:
>>
>> 1.8 - April 2015 (LTS): Dropped features deprecated in 1.6 [1.6 no longer 
>> supported].
>> 1.9 - Dec. 2015: Drop features deprecated in 1.7 [1.7 no longer 
>> supported].
>> 2.0 - Aug. 2016: No features dropped.
>> 2.1 - April 2017 (LTS): Drop features deprecated in 1.8, 1.9 [1.9 no 
>> longer supported, third party apps can update to support 2.0 as a minimum 
>> version; 1.8 users should use an old version of the third-party app for the 
>> ~1 year until 1.8 is unsupported].
>> 2.2 - Dec. 2017: Drop features deprecated in 2.0 [2.0 no longer 
>> supported].
>>
>> This is awesome.
>>
>> So why not to have 2.0 drop features features deprecated in 1.8? If the 
>> replacement pattern/feature is available in 1.8, the 3rd party app should 
>> be able to use the new feature to stay compatible, right? If anything I'd 
>> like to see us hold off on dropping features deprecated in 1.9 until after 
>> the LTS to help people migrate between LTSs.
>>
>> Thanks,
>> Collin
>>
>>
>> On Monday, June 1, 2015 at 9:20:07 AM UTC-4, Tim Graham wrote:
>>>
>>> I put together a draft proposal in the form of a potential 
>>> djangoproject.com blog post. I've enabled commenting in case you have 
>>> minor cosmetic comments, but please keep discussion about the content of 
>>> the proposal itself on this mailing list. Also, please let me know of any 
>>> additional questions or complaints that you'd like to see addressed in the 
>>> last section.
>>>
>>> The overview is:
>>> * New major release every 8 months
>>> * New long-term support release every 2 years. LTS releases continue to 
>>> be supported with security updates for 3 years.
>>> * Adjust the deprecation policy to make it easier for third-party apps 
>>> to support all versions back to the last LTS.
>>>
>>>
>>> https://docs.google.com/document/d/1bC6A8qc4skCmlagOnp8U7ddgyC-1XxXCBTlgrW690i0/edit?usp=sharing
>>>
>>> On Tuesday, April 7, 2015 at 3:20:55 PM UTC-4, Collin Anderson wrote:

 On Tuesday, April 7, 2015 at 2:31:08 PM UTC-4, Asif Saifuddin wrote:
>
> How about
>
> a 8 month release cycle and having a LTS in every two years and 
> supporting the old LTS atleast 3 years from the release date? there will 
> be 
> 3 version between two LTS.
>

 Interesting. I like the idea of having predictable release dates.

>>>

-- 
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/2c2a867b-c9fd-4bb0-98fd-e2f740a76f9f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Fate of sql* management commands

[Andrew Godwin]

OK, so I've just gone ahead and done the initial work on this:
https://github.com/django/django/pull/4729

I'd appreciate testing by people to see how well that new sql command
works; it's fine for me in dev here against a simple project but there's
probably some edge cases. Nevertheless, it seems to prove the idea and is
also the way we can handle test database setup potentially, too.

On Mon, Jun 1, 2015 at 1:41 PM, Tim Graham  wrote:

> As far as justification for dropping the old commands:
>
> 1. Andrew said earlier in the thread, "the sqlmigrate command will still
> get you SQL from migrations, though it sadly lacks the ability to take a
> range of migrations, optimise them down, and output the SQL for _that_ -
> that's probably the best thing for us to aim towards, and will almost
> entirely recreate the functionality of sqlall without actually being wrong
> (sqlall doesn't understand things like data migrations or custom SQL
> sections of migrations, and so will sadly be wrong in if you have anything
> like a moderately complex migration set)."
>
> 2. The sql* commands that were removed relied on SQL generation code in
> django/db/backends/base/creation.py and has been superseded by similar
> functionality in schema.py (and removed in 1.9). Django shouldn't maintain
> two ways of generating SQL for models.
>
> We welcome your contribution if you can form a consensus on a proposal.
>
>
> On Monday, June 1, 2015 at 4:00:14 AM UTC-4, Marcin Nowak wrote:
>>
>>
>> On Sunday, May 31, 2015 at 1:47:32 AM UTC+2, Tim Graham wrote:
>>>
>>> They were dropped as part of the removal of the old code that supported
>>> syncing apps without migrations.
>>>
>>
>> But you removed a feature, not just old code.
>> In v1.8 (1.7 maybe?) this feature was broken (issue #24876) and it was
>> completely removed in master (issue #24481).
>> This is not good.
>>
>>
>>>
>>> By the way, I suspect this could be implemented as a third-party app if
>>> there is opposition to including it in Django itself.
>>>
>>
>> I know I can reimplement it myself, but core feature should be nearest to
>> core source code, because it highly depends on internals.
>> This can be provided as a contrib app, for example.
>>
>> Why contrib.gis is supported for years? This app is used rarely. In
>> contrast to gis - we generate/create SQLs every day.
>> I don't know what you're doing with Django, but latests changes looks
>> fearfull.. :(
>>
>> /BR
>> Marcin
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/ac575d9c-eeb4-473b-a0ca-fcc73051b903%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/CAFwN1urVVW3hOkuT2vdAbm5EVv4pVs7MEvM9ejBEejSorYCrAQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Javier Guerra Giraldez]

On Sun, May 31, 2015 at 5:21 PM, Emil Stenström  wrote:
> 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.


first advice when discussing things on the internet:  don't take it personal.

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

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.

if "using the same language" was so important, we would all be using node.js...

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

Re: Feature: Template Components

[Sam Solomon]

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:
Background: What?

Specialized class based views and sub-views, that facilitate:

   - Split page template into components, each of which can be POSTed to 
   and/or updated via ajax.
   - View code and templates for full page view and ajax update is the same 
   code. (DRY, though more data over the wire than some of the newer 
   javascript frameworks)
   - Updating multiple parts of the page with a single request (example: 
   POSTing to one component can cause dependent components to also be updated 
   in the same request)
   - Built-in compatibility to handle no-js in most situations
   - Deferred loading of components, for performance

Background:
 
Why?
   
   - Complex site with lots of logged in user interactions where content 
   should be easy to change dynamically
   - Slow connections overseas (minimize round trips and limit full page 
   loads without sacrificing dev time too much)
   - Some may not even have JS? (Though we don't really cater to them that 
   much anymore, this was a consideration originally and still mostly 
   supported by default outside of where we use d3 and things like that for 
   rendering certain things.)


On Monday, June 1, 2015 at 12:55:08 AM UTC-7, Unai Zalakain wrote:
>
> Finally someone expressed my own feelings about it perfectly :D 
>
> On Sun, May 31, 2015 at 08:32:18PM -0500, Joe Tennies 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. 
> > 
> >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 
>

Re: Feature: Support Server-Sent Events

[Emil Stenström]

On Monday, 1 June 2015 01:42:38 UTC+2, Curtis Maloney wrote:
>
> I think the real questions are:
>
> 1. What is stopping a 3rd party product from providing the features you 
> want?
>

Nothing as far as I see it. Will develop as a third part  
 

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

There are basically two ways of getting out of the request-response cycle: 
websockets and SSE. Websockets are complicated, and SSEs are easy, with a 
protocol that is similar to what Django already has. So SSEs are clearly a 
better fit with Django. Given that we want to give people a way to do async 
in Django (open for debate, I think so), I think it makes sense to talk 
about the technical implementation.

I would love to see your code, especially if I can compare the two 
versions, and maybe ever write one using the model I'm proposing.

-- 
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/d465a072-c3de-4258-bf79-cc3e858d4af2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Feature: Support Server-Sent Events

[Emil Stenström]

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.

Re: User.username max_length 254

[Ryan Floyd]

I solved this in a very hacky way, without touching any django code. I'll 
probably break the forms

1. Create an empty migration (python manage.py makemigrations --name 
extend_username_field --empty [app_name])
2. Inside the migration, add:
```
operations = [
migrations.RunSQL('ALTER TABLE auth_user ALTER COLUMN username TYPE 
varchar(254);')
]
```

Works so far, but haven't really tested it extensively

-Ryan

On Wednesday, April 22, 2015 at 10:26:31 AM UTC-5, Micah Hausler wrote:
>
> I actually migrated my site to 1.7 and added a custom user model very 
> easily. Here's a gist with the code, 
> https://gist.github.com/micahhausler/63636f26cc87bb966218, but 
> essentially all I had to do was add a new user app, copy the Django 
> AbstractUser code, and set the db_table to 'auth_user'.
>
>
> class User(AbstractBaseUser, PermissionsMixin):
>  
> objects = UserManager()
>  
> class Meta:
> db_table = 'auth_user'
>
>
>
> Does anyone think this method could be worth adding to the Django 
> documentation? I'd be happy to open a ticket/write the docs. The only side 
> effect would be that if someone were using content-types for auth_user 
> objects, that would need to be migrated.
>  
> Micah Hausler
>
>
> On Friday, February 6, 2015 at 8:10:02 PM UTC-5, Collin Anderson wrote:
>>
>> Hi All,
>>
>> I was reminded by:
>> Allow shadowing of abstract fields 
>> https://groups.google.com/d/msg/django-developers/6zUfnElOIks/8uwXji559EsJ
>> and https://code.djangoproject.com/ticket/24288 (Custom User Models for 
>> small tweaks).
>>
>> Could we reopen https://code.djangoproject.com/ticket/20846 and increase 
>> User.username max_length to 254?
>>
>> Personally, that's the only thing I've ever needed to change about my 
>> User class. I just need it long enough to hold email addresses. I've seen 
>> many other people wanting the same thing.
>>
>> In 1.8 we migrated the length of EmailField from 75 to 254, so it should 
>> be almost™ as easy to change the username field.
>>
>> If needed, we could keep the 30-character limit on UserCreationForm and 
>> UserChangeForm for backwards compatibility. The limit in the database is 
>> the real killer :) Though, consistency is also nice.
>>
>> Thanks,
>> Collin
>>
>>

-- 
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/7ee05c12-2295-42ce-999a-1a997cb17cab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Bobby Mozumder]

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.

I believe this is where the web is headed for the long-term.

It may be possible to develop a Python syntax that analogous to HTML templates, 
with Django translating that for Javascript templating.

Now, whether Django serves these templates in Angular/Ember/React/whatever or 
develop some new framework (or even new HTML standards that operates on APIs 
directly...), is another question.  

-bobby

> On Jun 1, 2015, at 12:08 PM, Javier Guerra Giraldez  
> wrote:
> 
> On Sun, May 31, 2015 at 5:21 PM, Emil Stenström  wrote:
>> 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.
> 
> 
> first advice when discussing things on the internet:  don't take it personal.
> 
> 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;
> 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.
> 
> 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.
> 
> if "using the same language" was so important, we would all be using 
> node.js...
> 
> -- 
> 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/CAFkDaoSOYOoyX0w_m0ERzhiJmVPXWGr6pB29AongesG43gOw1w%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

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

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

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

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

[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: Template Components

[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: Template Components

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