I just wanted to add that I'm really excited for this change.
On PyCon Sweden 2015 I held a "Why Django Sucks"-presentation where I
talked about where the web is heading, and why django is lagging behind.
The main point was lack of support for async. After the presentation lots
of people came
John: Awesome! Do you need anything to get started or is Sjoerd's review
comments and todolist enough?
On Friday, 28 July 2017 15:03:12 UTC+2, John Griebel wrote:
>
> Hi Sjoerd,
> I too would love to see this feature in Django 2.0; in fact, I've been
> following its progress quite closely. I wou
On Monday, 1 May 2017 13:27:10 UTC+2, Tom Christie wrote:
>
> > I'm trusting that they ask for help if there's something the community
> can do.
>
> Personally I've got other priorities at the moment, so it's not something
> I'm working on or looking at.
> I do think it's a really nice bit of low
ve reception, it's not yet clear if we'll reach a consensus on
> inclusion in core.
>
> Personally I'm very firmly +1 on this, as I feel that the existing syntax
> is a rather glaring and unnecessary pain point.
>
> Thanks to everyone who's started to kick this off
there's been
> some positive reception, it's not yet clear if we'll reach a consensus on
> inclusion in core.
>
> Personally I'm very firmly +1 on this, as I feel that the existing syntax
> is a rather glaring and unnecessary pain point.
>
> Thanks to everyon
o an int.
Although I'm not really sure if I find it logical that it gets cast.
I don't really have that much time to work on it, but I'm hoping to
add the `setup.py` either later today or shortly after the weekend.
Kind regards,
Sjoerd Job
On Thursday, Sept
On 2016-09-16 09:30, Curtis Maloney wrote:
On 15/09/16 16:37, Curtis Maloney wrote:
Somewhere I have code to provide a "parse" based URL router.
Will dig it up now 1.10 has has shipped
Ah, found it...
So, here is a gist of a sample of using parse
(https://pypi.org/project/parse/) instead of
On Tuesday, 13 September 2016 21:54:49 UTC+2, ludovic coues wrote:
>
> There is third party module providing third party url function. Surlex
> [1] have been mentionned. But any third party solution will need to
> provide function compatible with django.conf.urls.url.
> Line 64 of django/urls/
gt; "pluggable URLs" which could use any syntax). If not, then let's accept
>> a
>> > patch to Django to support it. Over time, if there's some strong
>> consensus
>> > about a particular third-party package, then we could bring it in to
>&g
me strong consensus
>> about a particular third-party package, then we could bring it in to core.
>> I think this approach is less controversial then Django adopting some new,
>> untested syntax right now.
>>
>> On Tuesday, September 13, 2016 at 3:33:25 PM UTC-4,
ome new,
> untested syntax right now.
>
> On Tuesday, September 13, 2016 at 3:33:25 PM UTC-4, Emil Stenström wrote:
>>
>> So it looks to me that the consensus is that this IS in fact a good idea,
>> to supply a simpler, regex-free method to define URL:s.
>>
>>
So it looks to me that the consensus is that this IS in fact a good idea,
to supply a simpler, regex-free method to define URL:s.
It also seems that the best liked version is something that's similar to
what flask uses: /articles///.
I've never written a DEP before, but it sounds like a fun ch
/ares-ou
>
> Ares Ou
>
> On Mon, Sep 12, 2016 at 10:20 PM, Constantine Covtushenko <
> constantine...@gmail.com > wrote:
>
>> Hi Emil,
>>
>> It is a very interesting idea.
>>
>> +1 from me
>>
>> On Mon, Sep 12, 2016 at 11:32 PM, Emil
Hi Djangonauts,
I'm just back from my second year of teaching Django to absolute beginners.
The course is a combination of HTML, CSS, Python, and Django, and after
five days of coding they have a real live website that they can show to
friends. It's always such a great experience to see the loo
I finally found your proposal yesterday and I REALLY think this is the
right step forward for Django. Implementing this mindset for one of my
current projects I can already see how I could more easily add realtime
stuff, and rewrite much of the signaling to make the code easier to reason
about.
On Wednesday, 10 June 2015 02:55:46 UTC+2, Curtis Maloney wrote:
>
> This sounds a bit like combining django-sniplates with django-amn, and
> going a bit further...
>
> Fragments of templates, list of JS/CSS dependencies, and a way to collect
> it all together and ensure your page has everything
On Tuesday, 9 June 2015 13:21:27 UTC+2, Yoong Kang Lim wrote:
>
> This seems like a huge change. If you were to include this feature in
> Django, would it be straightforward for users to migrate from previous
> versions?
>
What I'm suggesting is not a huge change. I'm just saying that Django
sh
On Saturday, 30 May 2015 18:51:33 UTC+2, Emil Stenström wrote:
>
> A couple of weeks ago I held a presentation on PyCon Sweden 2015 with
> the title "Why Django Sucks". The idea was to follow in the footsteps of
> great conference talks like these:
> https://www.
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
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 c
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
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
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
dered 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:3
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
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.
>
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
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 webs
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
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" solu
On Sunday, 31 May 2015 18:49:07 UTC+2, Enrique Paredes wrote:
>
> IMHO, this can be easily solved with nunjucks.js and jinja which are both
> interchangeable, but in my experience it's better to had 2 template
> languages. Using only one tpl gives you the need to implement the same in
> the dja
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 D
On Sunday, 31 May 2015 16:52:50 UTC+2, Rotund wrote:
>
> The fact that you keep describing your idea as another process/thread that
> has back and forth communication with the actual Django instance seems to
> indicate to me that it's another program.
>
Yes, I was not clear about the distinctio
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 pr
On Sunday, 31 May 2015 11:16:17 UTC+2, Javier Guerra wrote:
>
> On Sun, May 31, 2015 at 3:52 AM, Emil Stenström >
> wrote:
> > Could you help me understand why this have to be done inside a web
> server
> > container?
>
> AFAICT, it doesn't have to be d
On Sunday, 31 May 2015 11:15:28 UTC+2, Federico Capoano wrote:
>
> On Sunday, May 31, 2015 at 10:52:26 AM UTC+2, Emil Stenström wrote:
> ...
>
>> Also, I don't think you would need to mix redis (or any other persistent
>> storage) into this. The connected clients
Hi,
On Sunday, 31 May 2015 10:27:24 UTC+2, riccardo.magliocchetti wrote:
>
> Hi,
>
> Il 30/05/2015 18:52, Emil Stenström ha scritto:
> > Hi,
> >
> > This is the first feature proposal as part of my general drive for
> getting
> > Django to work bette
Could you help me understand why this have to be done inside a web server
container?
When I've previously read about reasons for that they tend to be things
like "handling slow clients", something that an event loop is excellent at
automatically. To me, this means that this process could run ou
s,
> Florian
>
> On Saturday, May 30, 2015 at 5:52:36 PM UTC+1, Emil Stenström wrote:
>>
>> Hi,
>>
>> This is the third feature proposal as part of my general drive for
>> getting Django to work better for javascript heavy sites.
>>
>> Suppo
I just wanted to add that this looks GREAT. Maintaining the old colors was
a smart move, as this makes things familiar but still new. This work was
long overdue!
/E
On Saturday, 23 May 2015 14:00:18 UTC+2, elky wrote:
>
> HI Andy,
>
> Yes, this thread is actual for discussing this theme.
>
> Cu
to scale this across multiple machines?
>
> Thanks,
> Collin
>
>
> On Saturday, May 30, 2015 at 12:51:33 PM UTC-4, Emil Stenström wrote:
>>
>> Hi!
>>
>> A couple of weeks ago I held a presentation on PyCon Sweden 2015 with
>> the title "Why D
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-devel
t;building apps quickly and with
less code" mantra.
Thoughts? Ideas?
(And yes, this idea would work great together with the js template
rendering. Pushing database updates from the server to the client, and
they instantly updating the template accordingly)
Regards,
Emil Stenström
T
Hi,
This is the first feature proposal as part of my general drive for
getting Django to work better for javascript heavy sites.
Template Components
---
React.js popularized the notion that in front-end development, code
organization should be based on interface components, n
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
sted, if these are features that the core
team would be interested in.
But first I would like to see if you:
1. Agree on the main point that Django should do more for javascript
heavy sites.
2. Agree that one or more of the specific features that I'm proposing
would be a good fit for
Carl Meyer skrev 2013-05-17 5:03 PM:
Hi Emil,
On May 16, 2013, at 5:21 PM, Emil Stenström wrote:
Any feedback on how I was thinking? Does it make sense?
Based on the feedback so far I gather that changing the block tag
is a bad idea. I'd love to continue working on this, because I&#x
r
of tags, maybe "layout" and "content". But before going further I would
love some thoughts on the area, and if you think it's a worthwhile problem
to solve.
/Emil
On Wednesday, 17 April 2013 23:56:40 UTC+2, Emil Stenström wrote:
>
> Jacob Kaplan-Moss skrev 2013-04-
Carl Meyer skrev 2013-04-18 00:09:
Hi Emil,
On 04/17/2013 04:00 PM, Emil Stenström wrote:
Carl Meyer skrev 2013-04-17 18:37:
Why not instead add a new block to base.html? So you'd change base.html
to have:
{% block outer-content %}
{% block content %}{% endblock content %}
{% endblock
Andrew Ingram skrev 2013-04-17 18:08:
I've been wanting this exact feature for years. I've always struggled to
explain the problem, but I've had numerous cases where this would have
made for a vastly simpler template structure.
Big +1 from me.
Since there are a couple of -1:s on this. Would yo
Carl Meyer skrev 2013-04-17 18:37:
Why not instead add a new block to base.html? So you'd change base.html
to have:
{% block outer-content %}
{% block content %}{% endblock content %}
{% endblock outer-content %}
And base_with_warning.html:
{% extends "base.html" %}
{% block outer-content %}
Jacob Kaplan-Moss skrev 2013-04-17 18:36:
On Wed, Apr 17, 2013 at 10:50 AM, Emil Stenström wrote:
{% extends "base.html" %}
{% block content %}
Be careful when changing these settings!
{% block content %}{% endblock %}
{% endblock %}
I find this intensely confusing -- I c
Hi,
Proposal:
Make it possible to use the same template block name twice, if the second
one is nested within the first one. Inheriting from the template fills in
the innermost block.
--
Background (why is this useful?):
Say you have one base.html template defining a {% bloc
On Monday, 4 February 2013 15:06:18 UTC+1, Aymeric Augustin wrote:
>
> Hi Luke,
>
> This sounds like a good compromise between security and usability.
>
I just want to add another voice of support for Option 3 to this thread.
I'm one of the developers for a large site, with ~40 apps, that has g
On Monday, 2 June 2008 02:45:07 UTC+2, Ludvig Ericson wrote:
>
> I'd rather see this be leaved as-is, since I haven't seen a single
>
> report on these broken pipe 'issues'.
>
Here's a report:
I'm using PhantomJS (headless webkit browser) to test for javascript errors
on my site. Using the Live
I just thinking out loud here but: what if another thread does something to
the previously loaded object? I'm not sure if Django has concurrency tests
build into the test suite, but if it hasn't it could explain why the code
is written as it is.
On Friday, 30 November 2012 19:53:32 UTC+1, Anssi
On Thursday, 22 December 2011 03:49:44 UTC+1, Russell Keith-Magee wrote:
> ... there isn't a single solution that will work
> everywhere, which one of the reasons that the docs are silent on the
> issue.
>
Just for the record: The docs are actually telling you to put your signals
in models.py, a
On Thursday, December 8, 2011 10:31:39 PM UTC+1, jo...@lophus.org wrote:
>
> 1.) I didn't write the code, I'm just submitting the patches in their
> current state
>
Jonas: Do you have information on who wrote the code that you submitted? I
guess a good way forward would be to find those people,
ndle.
The patch is small (~30 lines of code) and solves a common annoyance for
people in countries with non-ascii characters in their alphabet.
I've never contributed to Django before, but if you find any issues, I'm
willing to help to fix them.
Thanks for your hard
--
from django.test.simple import run_tests as default_run_tests
from django.conf import settings
def run_tests(test_labels, *args, **kwargs):
return default_run_tests(settings.OUR_APPS, *args, **kwargs)
To run the tests:
-----
manage.py test
Feels like a pretty good solutio
60 matches
Mail list logo
