Re: Template-based widget rendering

Hey Curtis, I think you're asking how this patch will help with form and field layouts? If so, not that much. It only addresses moving the widget HTML that currently is hardcoded in Python into templates. For example, compare:

Re: URL dispatching framework: feedback requested

Can we expect this to be merged on 1.10 alpha? after that the minor imporvements could be take place. Thanks On Monday, December 28, 2015 at 10:23:19 PM UTC+6, Marten Kenbeek wrote: > > Hi everyone, > > This past week I've made some great progress in rewriting the URL > dispatcher framework

Re: Process DEP for "official" non-core projects

On 05/10/2016 08:58 PM, Andrew Godwin wrote: > Following my decision to move Channels away from a 1.10 merge and > towards an existence as a separate app for a bit while it matures, I > would like to write up a process DEP for how we achieve this - > specifically, what it takes to be adopted as a

Re: GitHub Issues for DEP repository?

Hi Kevin, On 05/10/2016 11:24 PM, Kevin Christopher Henry wrote: > With all the talk of DEPs flying around I thought I'd finally take a > look at one in detail. > > I wanted to make a suggestion about it and realized that there wasn't > really a good place to do so. The issue was too minor for a

Re: re-thinking middleware

On 05/10/2016 03:37 PM, Carl Meyer wrote: > I've > updated the DEP with a couple minor changes to reflect the latest > learnings from the implementation; you can see the latest changes at > https://github.com/django/deps/compare/763530e1a9...master Better version of this link (to exclude more

Re: URL dispatching framework: feedback requested

I'm not targeting this for 1.10. The patch hasn't been under review and is likely too much to review in a couple days. Also documentation remains outstanding. On Wednesday, May 11, 2016 at 12:52:33 PM UTC-4, Asif Saifuddin wrote: > > Can we expect this to be merged on 1.10 alpha? after that the

Re: Template-based widget rendering

I'm not sure about how common the need for custom widget templates are. Speaking for djangoproject.com and a few other small projects I maintain, I don't think these projects would make use of them but maybe if the feature is there, I might realize it would help in some places. What's your

Re: Template-based widget rendering

On 05/11/2016 11:30 AM, Tim Graham wrote: > I'm not sure about how common the need for custom widget templates are. > Speaking for djangoproject.com and a few other small projects I > maintain, I don't think these projects would make use of them but maybe > if the feature is there, I might realize

Re: Process DEP for "official" non-core projects

I like this, and +1 on your rough outline. There is one missing thing here though: I think we need to consider the process/policy for removing things if they're no longer maintained. Without clear maintainership forks happen, which is bad for pretty much everyone. So I think we should have a plan

Re: Template-based widget rendering

On 05/11/2016 11:52 AM, Carl Meyer wrote: > On 05/11/2016 11:30 AM, Tim Graham wrote: >> What's your proposal for changing the default TEMPLATES? Using Jinja2 or >> DTL? > > At some point maybe we can adopt Jinja2 as a required dependency. Until > then, the default startproject template can't use

Re: Process DEP for "official" non-core projects

On Wed, May 11, 2016 at 10:06 AM, Carl Meyer wrote: > > I'm not quite sure what this means. By "major release" here, you mean > "major release of the adopted project," not "major release of Django"? > So this means that security fixes for the adopted project will be > provided

Re: Process DEP for "official" non-core projects

On Wed, May 11, 2016 at 11:00 AM, Jacob Kaplan-Moss wrote: > I like this, and +1 on your rough outline. > > There is one missing thing here though: I think we need to consider the > process/policy for removing things if they're no longer maintained. Without > clear

Re: Process DEP for "official" non-core projects

On Wed, May 11, 2016 at 2:29 PM, Andrew Godwin wrote: > I would be inclined to merely mark it as deprecated and not drop it from > e.g. the GitHub org, though, as where would we move it *to*? > Sure, that's fine with me too. The key point is just that we're not (implicitly

Re: GitHub Issues for DEP repository?

On Wed, May 11, 2016 at 1:11 PM, Carl Meyer wrote: > So I'd personally be > fine with a PR to amend this section to remove mention of private > contact. Jacob, I think you wrote this (or adapted it from PEP 1) -- any > thoughts? > I don't recall why that's in there; I'm

Re: Process DEP for "official" non-core projects

Just wanted to thank you so much for your hard work. The documentation is really well written! On Wednesday, May 11, 2016, at 1:29:34 PM UTC-5, Andrew Godwin wrote: > > > > On Wed, May 11, 2016 at 11:00 AM, Jacob Kaplan-Moss > wrote: > >> I like this, and +1 on your rough