Re: Additional Fields in Core

On Mon, 2008-12-15 at 14:07 -0800, David Cramer wrote: > I'd like to propose the addition of some useful (and common) fields in > the django core. Things like a JSONFied, YAMLField, HTMLField?, > UUIDField, etc. > > A lot of these seem like common things people use, and while many > examples

Re: Additional Fields in Core

On Tue, Dec 16, 2008 at 7:07 AM, David Cramer wrote: > > I'd like to propose the addition of some useful (and common) fields in > the django core. Things like a JSONFied, YAMLField, HTMLField?, > UUIDField, etc. > > A lot of these seem like common things people use, and while

Re: Additional Fields in Core

Make app. Post on Google Code (or other site) Profit! :) These shouldn't need to be in core to be used. -- Collin Grady --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this

Re: CSRF / SafeForm

On Wed, Dec 3, 2008 at 8:14 AM, Luke Plant wrote: > == Conclusion == > > At the moment, once you've factored everything in, I think 'view > middleware' + template tag is the way to go, with some more custom > solution for login CSRF. The SafeForm ends up having an

Re: Non-standard SQL generated in column definition for nullable columns in create table DDL

On Mon, Dec 15, 2008 at 4:23 AM, Ambrish Bhargava wrote: > Hi, > > While working on the new backend support for DB2, I found that in > CREATE TABLE DDL generation, it contains some non-standard SQL syntax. > > Here is one example of model. > > class

Re: Additional Fields in Core

Ya core/contrib (same thing to me). My biggest issue with custom fields at the moment is the fact that the hooks aren't really the best. JSONField/etc have to use ugly signals to allow any data-type to be used. On Dec 15, 4:12 pm, "Mike Axiak" wrote: > I'd much rather see a

Re: Additional Fields in Core

I'd much rather see a contrib app for these. E.g.:: from django.contrib.datafields import fields as datafields class MyModel(models.Model): my_yaml = datafields.YAMLField() ... and any refactoring that's necessary to facilitate this cleaning should be dealt with. (And I

Additional Fields in Core

I'd like to propose the addition of some useful (and common) fields in the django core. Things like a JSONFied, YAMLField, HTMLField?, UUIDField, etc. A lot of these seem like common things people use, and while many examples are out there, it'd be nice to simply include these in core so there's

Re: Default manager

I like the `objects` convention as well as explict default manager declarations. I proposed both in http://groups.google.at/group/django-developers/browse_thread/thread/3e1a668ac84328b6/ce36cbe46276d807 . Advertisement: My radical "solution" is to never modify the initial

Re: Validation Warnings

Well the reason passing in self is more work is because when someone does add_warning() they have to know what the name of the field is in form, while this isn't a problem for clean_ methods, it is for clean() methods on the fields themselves, while this could be worked around by an attribute on

Re: Default manager

On Mon, 2008-12-15 at 09:12 -0500, Karen Tracey wrote: > I'd think it unlikely at this point a change would be made that would > prohibit having a field named 'objects'; the time for such a > backwards-incompatible change was pre 1.0, if ever. If no one pre-1.0 > found the exisitng behavior

Re: Default manager

On Mon, Dec 15, 2008 at 3:12 PM, Karen Tracey wrote: > On Mon, Dec 15, 2008 at 5:51 AM, Alex Rades wrote: >> >> Hi, >> my understanding about custom managers is that if you want to define a >> custom manager, you also HAVE to remember to define the

Re: Default manager

On Mon, Dec 15, 2008 at 5:51 AM, Alex Rades wrote: > > Hi, > my understanding about custom managers is that if you want to define a > custom manager, you also HAVE to remember to define the "objects" > manager first, otherwise some parts of django (eg. admin) will not > work.

Re: Default manager

See also http://code.djangoproject.com/ticket/9676 On Dec 15, 12:51 pm, "Alex Rades" wrote: > Hi, > my understanding about custom managers is that if you want to define a > custom manager, you also HAVE to remember to define the "objects" > manager first, otherwise some

Non-standard SQL generated in column definition for nullable columns in create table DDL

Hi, While working on the new backend support for DB2, I found that in CREATE TABLE DDL generation, it contains some non-standard SQL syntax. Here is one example of model. class User(models.Model): first_name = models.CharField(max_length=20, null=False) last_name =

Default manager

Hi, my understanding about custom managers is that if you want to define a custom manager, you also HAVE to remember to define the "objects" manager first, otherwise some parts of django (eg. admin) will not work. I find this suboptimal. I think that "objects" should always be the default