Re: ModelForms and the Rails input handling vulnerability

[Gary Reynolds]

On 13 June 2012 09:16, Luke Plant  wrote:

> = Option 2: Deprecate Meta.exclude, but still allow a missing
> Meta.fields attribute to indicate that all fields should be editable.
>
> The policy here is essentially this: if any fields the model are
> sensitive, assume all are potentially, and require whitelisting, not
> blacklisting.
>

+1 for option 2 as I've always felt like Meta.exclude was the wrong way to
do go building a ModelForm which was supposed to have a subset of fields.

Given that the underlying Model definition may change, it would be easy to
all of a sudden expose a newly added field. This would be particularly bad
when in your template you use {{ form.as_p }} or similar. I never use
Meta.exclude for this reason, always giving a whitelist anyway.

+0 for option 3 as I think the convenience of a missing Meta.fields is
worthwhile, but I could live without it.

Another option could be to split ModelForm such that you could mix and
match the functionality you require. Moving forward the ModelForm class
could provide option 3 behaviour, and a newly introduced class could
provide the option 2 behaviour. The only difference would be the alias to
Meta.fields not existing results in all model fields, but this would be an
explicit step.

Gary

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Make "required=True" on forms.fields.NullBooleanField do something useful?

[Gary Reynolds]

Sorry this is quite late on this thread, but I hadn't noticed any answer for
it.

How about:

from django import forms

class MyNullBooleanField(forms.NullBooleanField):
def clean(self, value):
if value is None:
raise forms.ValidationError('Choose either Yes or No.')
return super(MyNullBooleanField, self).clean(value)

class YourForm(forms.Form):
whatever_field_name = MyNullBooleanField()

You could also subclass the django.db.models.fields.NullBooleanField and
overload the formfield method if you want this for free on a ModelForm, but
I suspect we're heading into django-users territory already.

Cheers,
Gary

On Thu, Jun 17, 2010 at 10:39 AM, Matt Hoskins wrote:

> My use case is that I want to have a BooleanField on the model and on
> the form want to have the choices of "Unknown", "Yes" and "No" in a
> select list and give a "this field is required" error if the user
> leaves it set to "Unknown" (i.e. require them to actively choose "Yes"
> or "No", rather than defaulting to either of them). I thought I'd just
> be able to use NullBooleanField with "required=True" set, but
> NullBooleanField just ignores the "required" argument. To my mind it
> would be a sensible use of "required" for NullBooleanField, but before
> raising a ticket I thought I'd ask if it was a deliberate oversight or
> if what I'm suggesting isn't sensible for some reason :).
>
> Looking at the code for forms.fields.BooleanField and
> forms.fields.NullBooleanField I guess the change would be in to_python
> in the latter to check in the case where it would return None if
> self.required is true and raise the validation error if that's the
> case (i.e. similar to what BooleanField.to_python does for values of
> False).
>
> Matt
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-develop...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com
> .
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Re: Default ordering on User model

[Gary Reynolds]

You could always use a proxy model instead of monkey patching.

class MyUser(User):
  class Meta:
proxy = True
ordering = ('first_name', 'last_name')
  def __unicode__(self):
return self.get_full_name()

Then in any models you define a FK to User, just FK to MyUser instead.

On Fri, May 21, 2010 at 2:18 PM,  wrote:

> My favourite workaround for this is to register a small dummy apps
> overriding default properties:
>
> from django.conf import settings
>
> if "django.contrib.auth" in settings.INSTALLED_APPS:
> # modify User model properties only if contrib.auth is installed
> from django.contrib.auth.models import User
> # display full name instead of user name where string representation is
> required:
> User.__unicode__ = lambda self: self.get_full_name()
> # set default ordering by first name and last name:
> User._meta.ordering = ['first_name', 'last_name']
>
> This will globally modify default sorting (and unicode representation) for
> User model. It is usually the first thing I put into my project.
>
> This is a bit of hard coded to cater to my specific requirements (in many
> cases I do have first and last names). A more flexible workaround could
> involve special settings, e.g.:
> AUTH_DEFAULT_ORDERING = ( 'first_name', 'last_name' )

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: dbsettings, and user configurable app settings

[Gary Reynolds]

I really don't see how your YAML file is any more maintainable than Django's
settings.py approach? If anything, I would argue that it is less
maintainable, as you would have to maintain not only your YAML files moving
forward, but also the code which transposes it into a settings.py.

On Wed, Mar 10, 2010 at 2:16 PM, Joan Miller  wrote:

> It's a disaster from the maintenance view point. If it were not so,
> then people would not be proposing to refactor the settings as has
> been made in Pinax, or from multiple posts so many times.
>
> This is nothing new. Many people dislikes that kind of configuration,
> of the same that many people hates java by its fu**ing XML config.
> files.
>
> On 10 mar, 13:49, Russell Keith-Magee  wrote:
> > On Wed, Mar 10, 2010 at 6:18 PM, Joan Miller  wrote:
> > > Whatever configuration system using variables of a language is a
> > > disaster and it's going not maintainable as has been showed in Django.
> >
> > That's a pretty wild assertion to make without any evidence, and it's
> > completely contrary to my personal experience. Care to back it up? In
> > what way has Django demonstrated that using a programming language for
> > configuration files is a disaster?
> >
> > Yours,
> > Russ Magee %-)
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django documentation for newer users

[Gary Reynolds]

That's interesting, I'm of the other belief... I find the Django
documentation to be thorough and organised very well.

One of the main reasons I (and I am sure countless others) even started
using Django was because of it's excellent documentation.

As the project has matured from version 0.96 onwards I believe that this has
not only continued to hold true, but has even improved over time. The strong
emphasis on provided good documentation with any patch has definitely
fostered this.

I think the old addage "if it ain't broke, don't fix it" best describes this
- for many people the documentation works not just fine, but damn well... if
you think it needs an overhaul, I'd like to first of all know what you
intend to change/add it to make it better.

On Fri, Mar 5, 2010 at 4:20 PM, stherrien  wrote:

> Exactly my point docs need to be more organization to be constructive
> for django users.
>
> On Mar 5, 11:05 am, Jared Forsyth  wrote:
> > To be honest I am quicker to just go to django's source code rather than
> the
> > docs, as often I can find what I need there, and the docs aren't (imo)
> > organized enough to provide much of an advantage.
> >
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Serialization of single object instead of only querysets.

[Gary Reynolds]

There is already a ticket for this (and possibly others).

http://code.djangoproject.com/ticket/11244#comment:4

It has been closed and marked wontfix, see the comments for why.


On 15 Feb 2010, at 21:53, orokusaki  wrote:


Please visit the following URL, and when you do, put your focus into
the search form after "seri" and type the letter "a". You'll notice
the top search for anything related to Django serialization is "Single
Object". This is because people want to have this feature. Serializing
a single object can be accomplished right now but you have to make
pass it in a list like this: [my_object]. This isn't a huge problem.
The problem comes when you're writing your outside code (JavaScript,
et all) against the API you've now built. You need something like
user[0].first_name instead of just user.first_name. It's not a huge
coding difference. It just seems broken and confusing, especially to
newcomers.

Here's the URL: 
http://www.google.com/#hl=en=django+seri=f=g10=django+seri

--  
You received this message because you are subscribed to the Google  
Groups "Django developers" group.
To post to this group, send email to django-developers@googlegroups.com 
.
To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com 
.
For more options, visit this group at http://groups.google.com/group/django-developers?hl=en 
.




--
You received this message because you are subscribed to the Google Groups "Django 
developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: #12801 : Allow empty non-nullable ForeignKey fields until save()

[Gary Reynolds]

>
> The correct exception is risen when you try to save it:
>
>  >>> t.save()
>  Traceback (most recent call last):
>  ...
>  IntegrityError: 20100212_thing.owner_id may not be NULL
>
> How can you not understand that the DoesNotExist exception above is
> risen too early? It is a bug!
>

Are you saying that the correct behaviour is to throw an IntegrityError as
opposed to a DoesNotExist on accessing the field?

If so, why would accessing a value on an unsaved instance (which by
definition isn't in the database yet) be an IntegrityError rather than a
DoesNotExist as a result of a lookup?

It's clearly a design decision. You are free to disagree with that decision,
but it's not a bug - it's behaving as designed (and documented).

Gary

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: user_passes_test decorator changes in 1.2

[Gary Reynolds]

>
> Yes, that definitely falls into the category of relying on an
> implementation detail, rather than something that should be mentioned
> as a backwards incompatibility.  At the level of inspecting code
> objects (which is essentially what your code was doing), almost any
> change is backwards incompatible.  'view_func' is not only not
> documented, it is a member of a class which is private and marked as
> such - _CheckLogin.
>

Yeah, I expected that. At the time I wrote it (a while back now) I was a bit
worried it could/should have been done better by me; lesson learned.

Personally, I'd use this as an opportunity to find a more robust way
> of getting that information to the template tag :-)
>

Fair call! I'll plug away at that and if I have any more questions I'll move
my questioning over to django-users.

Thanks,
Gary
-- 

You received this message because you are subscribed to the Google Groups "Django developers" group.

To post to this group, send email to django-develop...@googlegroups.com.

To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.