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

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.

Re: Feature: Support Server-Sent Events

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

Re: Feature: Support Server-Sent Events

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"

Re: Feature: Template Components

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

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

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 >

Re: Fate of sql* management commands

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

Re: 1.9 release planning

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

Re: 1.9 release planning

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

Re: 1.9 release planning

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

Re: 1.9 release planning

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

Re: 1.9 release planning

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

Re: Django banking packages

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

Re: Django banking packages

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

Re: Fate of sql* management commands

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

Django banking packages

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

Re: Feature: Support Server-Sent Events

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

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

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 >

Re: Fate of sql* management commands

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

Re: Feature: Template Components

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