Re: Testing: making it easier to create mock Request objects

[Simon Willison]

On Sep 7, 10:03 pm, akaihola <[EMAIL PROTECTED]> wrote:
> I couldn't find a ticket for this issue yet. Simon, mind if I create a
> ticket and dump your description of the issue there?

Go for it!

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Testing: making it easier to create mock Request objects

[akaihola]

I couldn't find a ticket for this issue yet. Simon, mind if I create a
ticket and dump your description of the issue there?

-Antti
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: contrib.auth tests

[Devin]

> > There is a middle ground here, which is that those auth-app templates
> > get moved to the Django's main test directory so that they're available
> > only to runtests. That doesn't feel particularly self-contained and
> > again, for me, violates the intuitive meaning of the word unittest, but
> > it's the way we've gone with the new comment tests and the admin tests,
> > for example. Might be a trend to follow.
>
> To my mind, moving the templates to the django test directory is the
> right solution in this case. The Django system tests need to validate
> that the auth system works when the right templates are available, so
> it needs to provide those templates.
>
> Unfortunately, this means that the auth tests will fail for users that
> aren't providing auth templates. I realize that this isn't an ideal
> outcome, but my gut feeling is that the benefit to users knowing their
> installs are busted is greater than the pain for those users that will
> have known test failures due to not deploying some views and
> templates.

In my opinion this leads to the correct solution.

We essentially want to do two tests. Like you said (1) test the auth
app given a valid template and (2) test that the view is used
correctly by the project using the app.

(1) is a Django test. To ensure that contrib.auth is working if given
a correct template. This should live in runtests and use a known good
template.
(2) is of the use of that view. This should live in contrib.auth and
be skipped if that view isn't being used. Of course this depends on
the patch I've written in #4788. (And in fact, I've taken that
approach with those tests in that patch.)

If this approach is taken. We also need to add a test to runtests that
will essentially do the same thing, but provide a known good template.

Cheers,
Devin
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Porting from Django 0.96 to 1.0 doc improvement

[Ramiro Morales]

On Sun, Sep 7, 2008 at 1:10 PM, olive <[EMAIL PROTECTED]> wrote:
>
> Hello,
>
> I had hard time to find that I need to add primary_key=True to my
> OneToOneFields to make it work as with 0,96.
>
> I still don't understand why I need add that for 1.0.
>
> Could you please add some lines about this in the doc ?
>

This is already described in the last paragraph of this
documentation section:

http://docs.djangoproject.com/en/dev/topics/db/models/#one-to-one-relationships

Your suggestion to add something about the topic to the porting guide
is a good idea, though.

Regards,

-- 
 Ramiro Morales

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Porting from Django 0.96 to 1.0 doc improvement

[olive]

Hello,

I had hard time to find that I need to add primary_key=True to my
OneToOneFields to make it work as with 0,96.

I still don't understand why I need add that for 1.0.

Could you please add some lines about this in the doc ?

Thanks again for Django 1.0,

Olivier.
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Reviews Best Price : Kodak Digital Camera

[IFMore]

Kodak EasyShare C713
7MP...
PRODUCT FEATURES:7.0 MP for stunning prints up to 20 ? 30 in. (50 ? 76
cm)More m .

Re: Forms and edition of an object : non-pythonic default behaviour

[Denis Frère]

On Sep 7, 10:02 am, Tai Lee <[EMAIL PROTECTED]> wrote:
> In your hypothetical, how would you handle boolean fields with a
> checkbox widget? When they are unticked, they are not included in the
> QueryDict.

You are quite right. That's a very good reason.

Perhaps that HTML should consider a unchecked checkbox successful with
a value=False, but since this is not the case, Django does the right
thing.

> [...] just to avoid having to `exclude` a field you don't want to
> update with your form.

I'm red of confusion... Yes, I'm s lazy. ;-)

Thanks for your answer and again : great job !
I'm almost as excited discovering Django as I was when discovering
Python years ago.

Denis





>
> On Sep 7, 10:10 am, Denis Frère <[EMAIL PROTECTED]> wrote:
>
> > On Sep 6, 9:43 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
>
> > > On Sat, Sep 6, 2008 at 8:40 AM, Denis Frère <[EMAIL PROTECTED]> wrote:
> > > > Why LinkForm(request.POST, instance=link) doesn't behaves like
> > > > link.update(request.POST) ?
>
> > > it doesn't behave that way because it'd make no sense to behave that
> > > way; if there's a field in a form and it gets no data, then the form
> > > has _no data_ for that field. Not "keep the existing data", not "make
> > > a guess about what this means", just "I have no data for this field".
> > > And the only thing to do with no data is to blank the field.
>
> > I completely agree with you in the case I use a field in a html form
> > and let the field blank.
> > But when I don't use a field in the html form, whether that field
> > exists in the Django form or not, then that field doesn't exist in the
> > QueryDict.
> > It's not a question of "no data for a field", it's a question of
> > "missing field" in the request.POST dict. It doesn't mean "I have no
> > data for this field", it means "that field has been left untouched".
>
> > Let's say that I see it that way because I have a "html-form-point-of-
> > view" and you seem to have a "Django-form-point-of-view".
>
> > Anyway, that's not a big problem since I can write a Django form
> > whitch excludes that field. You're the boss and you set the rules and
> > I'm happy to use Django even if I disagree on some small points. You
> > made a great job, it's really a very nice framework !
>
> > Thanks for your answer.
>
> > Denis
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Forms and edition of an object : non-pythonic default behaviour

[Tai Lee]

In your hypothetical, how would you handle boolean fields with a
checkbox widget? When they are unticked, they are not included in the
QueryDict. It could get confusing if we start special casing fields
like these in order to support "no data" as a different case to "empty
data", just to avoid having to `exclude` a field you don't want to
update with your form.


On Sep 7, 10:10 am, Denis Frère <[EMAIL PROTECTED]> wrote:
> On Sep 6, 9:43 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
>
> > On Sat, Sep 6, 2008 at 8:40 AM, Denis Frère <[EMAIL PROTECTED]> wrote:
> > > Why LinkForm(request.POST, instance=link) doesn't behaves like
> > > link.update(request.POST) ?
>
> > it doesn't behave that way because it'd make no sense to behave that
> > way; if there's a field in a form and it gets no data, then the form
> > has _no data_ for that field. Not "keep the existing data", not "make
> > a guess about what this means", just "I have no data for this field".
> > And the only thing to do with no data is to blank the field.
>
> I completely agree with you in the case I use a field in a html form
> and let the field blank.
> But when I don't use a field in the html form, whether that field
> exists in the Django form or not, then that field doesn't exist in the
> QueryDict.
> It's not a question of "no data for a field", it's a question of
> "missing field" in the request.POST dict. It doesn't mean "I have no
> data for this field", it means "that field has been left untouched".
>
> Let's say that I see it that way because I have a "html-form-point-of-
> view" and you seem to have a "Django-form-point-of-view".
>
> Anyway, that's not a big problem since I can write a Django form
> whitch excludes that field. You're the boss and you set the rules and
> I'm happy to use Django even if I disagree on some small points. You
> made a great job, it's really a very nice framework !
>
> Thanks for your answer.
>
> Denis
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---