Re: on type-specific input fields

Hi Erik, I think a more elegant solution than rolling back to TextInput would be to promote/document the use of the "novalidate" attribute. In a nutshell, '' disables client-side validation, letting users submit forms regardless of the client validation logic while still taking advantage of the

Re: An argument against mark_safe.

On Thu, Oct 17, 2013 at 10:06 AM, Daniele Procida wrote: > On Wed, Oct 16, 2013, Jonathan Slenders wrote: > >>Some people still have javascript in their templates and they use template >>tags inside their javascript. :( > > I am not sure if you're

Proposal: ModelForm API improvements

Hello, There was some discussion on the current limitations of the ModelForm API in the past couple of days on IRC, I'd like to make a proposal to address some of them. I wrote django-floppyforms, a library that lets you render forms using templates instead of python code. It behaves exactly

Re: dumpdata with custom auth model

Hello, On Sat, Nov 24, 2012 at 7:43 AM, Russell Keith-Magee wrote: > Hi Benoit, > > Like I said in my last response, I'm *not* seeing the problem. Saying "I'm > seeing the problem" doesn't help me. Saying "I've got a custom User" doesn't > help me either -- I've got a

Re: proposal: post-collectstatic signal

On Sun, Nov 11, 2012 at 5:09 PM, Justin Holmes wrote: > My sense is that there are a growing number of use cases, but the one that I > currently have in mind is for django-coldbrew. I want to be able to > compile all the coffeescript in a project during the

Re: Custom user models don't like non integer primary keys.

On Wed, Nov 7, 2012 at 12:06 AM, Russell Keith-Magee wrote: > Hi Eric, > > Although the full stack trace would confirm it, I think I can guess what the > problem is here -- it's the mechanism for generating reset tokens. > > If you dig into the token generation (and

Re: django people: impossible to sign up ?

Hi Michael, On Thu, Aug 2, 2012 at 9:16 PM, Michael wrote: > Hi, > > Since Django People is hosted on the djangoproject.com website: > https://people.djangoproject.com/signup/, I thought it would be a good place > to ask my question. If not, sorry for that. > I have

Re: Glad site is being brought back.

On Wed, May 30, 2012 at 10:30 PM, Daniel Sokolowski wrote: > Please disregard this message, it was meant as a reply to a thread not a new > thread. > > -Original Message- From: Daniel Sokolowski > Sent: Wednesday, May 30, 2012 12:35 PM > To: Django

Re: Djangopeople.net status

On Sat, May 19, 2012 at 3:46 PM, Will Hardy wrote: > Seeing as we have to deal with a stale data issue anyway, I thought I > would throw an idea into the mix. > > I think it'd be nice to have something where the data is a little more > open, allowing anyone to create an

Re: django.contrib.auth.models.get_hexdigest missing in 1.4

Hi, On Sun, May 13, 2012 at 3:08 PM, Shai Berger wrote: > Hi, > > In the process of upgrading to Django 1.4, I've run into a little problem: one > of our files uses django.contrib.auth.models.get_hexdigest, which is no longer > present. > > I searched, and could find no

Re: Djangopeople.net status

On Thu, May 10, 2012 at 8:04 AM, Russell Keith-Magee wrote: > On Thu, May 10, 2012 at 9:19 AM, Aaron C. de Bruyn wrote: >> On Wed, May 9, 2012 at 1:37 PM, Alex Sosnovskiy wrote:

Re: auth.user refactor: the profile aproach

Hi Jacob, Thanks for taking the time to tackle this issue! On Tue, Apr 3, 2012 at 2:35 AM, Jacob Kaplan-Moss wrote: > Hi folks -- > > I've written up a proposal for how *I* would like to address refactoring > auth.user: https://gist.github.com/2245327. > > In essence, this

Re: Addition of failed login signal

On Sun, Jan 15, 2012 at 7:06 AM, Darren Spruell wrote: > Greetings, > > As an enhancement to the existing collection of signals I wanted to > propose the addition of a signal for the event of an unsuccessful > login. Currently django.contrib.auth supports user_logged_in and

Re: Djangopeople.net status

On Fri, Jul 15, 2011 at 1:22 PM, Subhranath Chunder wrote: > Hi, > I'm very much interested to help. Please tell me, from where and how to get > started. > Thanks, > Subhranath Chunder. Hi Subhranath, I've been contacted by a couple of people so I'll post publicly here

Re: Djangopeople.net status

On Wed, Jul 13, 2011 at 5:49 PM, Yonsy Manuel Solis Ponce wrote: > well, i am interested to help > we need to fork in github from https://github.com/brutasse/djangopeople.net > ? Yes, the fork tree is slightly confusing but this repo contains all the work that's been done

Djangopeople.net status

Hi fellow Django devs, I'd like to talk about a site that all of you probably know: djangopeople.net. The site has originally been developed by Simon Willison and Natalie Downe and is a very useful part of the different sites connecting the Django community. Recently, however, Simon and Natalie

Re: Form Rendering API Proposal

Hi all, On Fri, Jun 24, 2011 at 12:38 PM, Gregor Müllegger wrote: > Hi Jacob, > > 2011/6/23 Jacob Kaplan-Moss : >> Hi Idan et al. -- >> >> Thanks for putting this all together! >> >> In general, I like this a lot, and I'm always going to defer to the >>

Re: RFC: Templatetag API for form rendering

Hi, I like the API and I'm looking forward to this. Just a small comment on the {% widget %} tag: On Sun, May 22, 2011 at 10:21 PM, Gregor Müllegger wrote: > (You can read this RFC online if you prefer: >

Re: Read-only forms and DataBrowse

On Thu, Apr 7, 2011 at 3:23 PM, akaariai wrote: > About the read-only forms part of the proposal: read-only forms will > be easy to implement if the template widget rendering idea will be > included in core. > > For example for SelectMultiple widget the base template is

Re: Proposal: template-based widget rendering

Hi Carl, On Tue, Mar 15, 2011 at 6:59 AM, Carl Meyer wrote: > > As we've already discussed here at PyCon, I'm +1 on this change. It > makes forms far more flexible and usable by template authors, and I > think that will benefit almost all Django users. It's more consistent >

Proposal: template-based widget rendering

Hi django devs, Although Django 1.3 is not released yet I'd like to take advantage of the pycon sprints to discuss a proposal for 1.4: render form widgets using Django templates instead of python code. This approach is implemented in django-floppyforms [0] (I'm the author): each widget gets a