Re: User Authentication without password

2009-02-23 Thread Alex Koshelev
And of course this topic is for django-users@ not developers. On Tue, Feb 24, 2009 at 10:33 AM, Alex Koshelev wrote: > You have to write your own authentication backend [1] with any credentials > you need. > > [1]: > http://docs.djangoproject.com/en/dev/topics/auth/#writing-an-authentication-bac

Re: User Authentication without password

2009-02-23 Thread Alex Koshelev
You have to write your own authentication backend [1] with any credentials you need. [1]: http://docs.djangoproject.com/en/dev/topics/auth/#writing-an-authentication-backend On Tue, Feb 24, 2009 at 6:52 AM, dannyr wrote: > > > Is there a way to force authentication for a user without a password

Re: MarkupField

2009-02-23 Thread James Bennett
OK, so, time to step back a bit and think big-picture. How to specify the markup type == Yes, you and your co-workers like having an internal app where everybody chooses their own markup format every time they post something. But if something's going to go into Djang

Re: MarkupField

2009-02-23 Thread James Turk
I certainly wasn't trying to come off as against any suggested improvements and apologize if I seemed so. I originally thought that the suggestion was to drop the option of selecting a markup type in favor of a callable or perhaps just saw the two as incompatible for some reason. I wonder if perh

User Authentication without password

2009-02-23 Thread dannyr
Is there a way to force authentication for a user without a password (= authenticate(username=test...))? I'm developing an app that allows a user to login either via Facebook Connect or the normal login. Thanks. --~--~-~--~~~---~--~~ You received this message be

Re: Creating "lazy" foreign keys

2009-02-23 Thread Jerome Leclanche
Sounds like that wouldn't work. Django fails on __init__ with invalid foreignkeys. On Tue, Feb 24, 2009 at 3:24 AM, join.toget...@gmail.com wrote: > > On Feb 22, 10:30 pm, Adys wrote: >> Not sure I follow you. You mean overriding the set property of a >> ForeignKey/IntegerField? >> >> On Feb 23

Django 1.1 alpha 1 released

2009-02-23 Thread James Bennett
As we run up to Django 1.1 (due in April), we've started the process of alpha and beta preview packages with Django 1.1 alpha 1, released tonight. As always, alpha and beta packages are *not* for production use, but if you'd like to try out the new features or go bug-hunting in a safe environment,

Re: Creating "lazy" foreign keys

2009-02-23 Thread join.toget...@gmail.com
On Feb 22, 10:30 pm, Adys wrote: > Not sure I follow you. You mean overriding the set property of a > ForeignKey/IntegerField? > > On Feb 23, 6:23 am, "join.toget...@gmail.com" > > wrote: > > What about something like a property()? The set method would act like > > normal, but the get method wou

Re: MarkupField

2009-02-23 Thread Waylan Limberg
On Mon, Feb 23, 2009 at 7:09 PM, dc wrote: > >> * it removes the ability to provide multiple markup_types on a given field > > No if properly implemented. Again, see FileField upload_to for > example. Or see the django-template-utils app [1]. It provides a nice wrapper so that all the formatters

Re: MarkupField

2009-02-23 Thread dc
> * it removes the ability to provide multiple markup_types on a given field No if properly implemented. Again, see FileField upload_to for example. > * what is unpythonic about taking in two extra parameters to customize the > field? All markup functions take different arguments. Also differen

Re: MarkupField

2009-02-23 Thread David Larlet
Le 23 févr. 09 à 23:27, James Turk a écrit : > To me there are a few big problems with the markup_func proposal as > I see it: > > * it removes the ability to provide multiple markup_types on a given > field > * what is unpythonic about taking in two extra parameters to > customize the fie

Re: MarkupField

2009-02-23 Thread James Turk
To me there are a few big problems with the markup_func proposal as I see it: * it removes the ability to provide multiple markup_types on a given field * what is unpythonic about taking in two extra parameters to customize the field? My goal here isn't to provide a generic "accepts-any-markup" f

Accounting for protocol in building fully-qualified URLs

2009-02-23 Thread dchandek
Since some of my Django sites are behind https and others are not, I have been a bit frustrated by the lack of accounting for this in django.contrib.sites.models and/or Django project settings. I've seen the proposal to overhaul get_absolute_url() at http://code.djangoproject.com/wiki/ReplacingGe

Re: MarkupField

2009-02-23 Thread dc
I think you are trying to do too many things in one place. Better concern on storing and retrieving formatted data but not on loading and configuring markup functions. Accept markup_func as argument and call it when saving. User will load markup function that he wants, and will configure it as he

Re: Localflavor "US state" field choices

2009-02-23 Thread Alex Gaynor
On Mon, Feb 23, 2009 at 4:35 PM, Eugene Lazutkin wrote: > > Let's not dabble in the international politics, but support practical > choices. There is an official table provided by U.S.P.S. listing states, > possessions, and military "states" recognized as valid abbreviations: > http://www.usps.com

Re: Localflavor "US state" field choices

2009-02-23 Thread Eugene Lazutkin
Let's not dabble in the international politics, but support practical choices. There is an official table provided by U.S.P.S. listing states, possessions, and military "states" recognized as valid abbreviations: http://www.usps.com/ncsc/lookups/abbr_state.txt If somebody doesn't like it --- w

Re: Ticket 7539: Add ON DELETE and ON UPDATE support to Django

2009-02-23 Thread Michael Glassford
Russell Keith-Magee wrote: > On Fri, Feb 20, 2009 at 1:49 AM, Michael Glassford > wrote: >> Just yesterday I updated the patch attached to >> http://code.djangoproject.com/ticket/7539 so that it will apply against >> the current version of Django (the previous patch required Django 0.96). >> Wha

Re: Ticket 7539: Add ON DELETE and ON UPDATE support to Django

2009-02-23 Thread Russell Keith-Magee
On Fri, Feb 20, 2009 at 1:49 AM, Michael Glassford wrote: > > Just yesterday I updated the patch attached to > http://code.djangoproject.com/ticket/7539 so that it will apply against > the current version of Django (the previous patch required Django 0.96). > What are the chances of some form of