Re: Disabling middleware for tests

[stryderjzw]

Ah yeah, of course I can put a print statement. Thanks Malcolm. Your
many posts have helped me greatly in the past.

Looks like it works with a new Django project. I am using Pinax and
they alter the manage.py file slightly.

Can't see why it's not working though. I guess I'll have to dig in
deeper into the Django code.



On Feb 16, 6:42 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
> On Mon, 2009-02-16 at 18:36 -0800, stryderjzw wrote:
>
> [...]
>
> > However, I'm running into the problem that I have no clue if manage.py
> > ever read my settings file correctly.
>
> The settings file is executable (well, importable) Python code, so put a
> print statement in there that will display something when the file is
> imported. You could do something like printing the value of
> MIDDLEWARE_CLASSES.
>
> Regards,
> Malcolm
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Disabling middleware for tests

[stryderjzw]

Well, looking at Ticket 9172 (http://code.djangoproject.com/ticket/
9172), we're supposed to be turning off the CSRF middleware during
tests.

I believe we can do that by writing another settings file, disabling
the Csrf Middleware and using that settings file to run our tests, as
per this thread.

However, I'm running into the problem that I have no clue if manage.py
ever read my settings file correctly. I'm assuming it didn't because I
still get the Cross Site Request Forgery error. I can import my
test_settings fine in the shell, so it's not the file that is
incorrect.

I'll dig into this more tonight.

Cheers,
Justin


On Feb 16, 4:12 pm, felix <crucialfe...@gmail.com> wrote:
> ah ha.
>
> yes, I've wasted several hours over this issue.  it took me a while to
> figure out that it was the CSRF middleware that was breaking the tests.
> both auth tests and actually every single one that tests the posting of
> forms.
>
> I didn't see it mention of this issue in either the CSRF docs or the unit
> test docs, but those are both places that we would first look to diagnose.
> a docs request ticket should be filed.  I couldn't find one existing.
>
> I thought it was something to do with self.client.login failing (because I
> would get 403)
>
> I couldn't figure this out: is there a way to tell that we are running as a
> test ?
>
>      felix :    crucial-systems.com
>
> On Mon, Feb 16, 2009 at 9:33 PM, stryderjzw <stryder...@gmail.com> wrote:
>
> > > from settings import *
>
> > > #CSRFMiddleware breaks authtests
> > > MIDDLEWARE_CLASSES = list(MIDDLEWARE_CLASSES)
> > > MIDDLEWARE_CLASSES.remove
> > > ('django.contrib.csrf.middleware.CsrfMiddleware')
>
> > > # Turn this off to allowteststhat look at http status to pass
> > > PREPEND_WWW = False
>
> sorry, I don't get this.  what fails ?  response.status_code == 200 ?
>
>
>
> > > I then run the test suite using this command:
> > > python manage.py test --settings=mysite.settings-test.py
>
> > > Best,
> > > Dave
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Disabling middleware for tests

[stryderjzw]

This doesn't seem to be working for me.

I created my own test_settings.py in the project root directory.

I ran
python manage.py test --settings=test_settings

It runs as usual and CSRF still fails when I run tests.

Anyone know what I might be doing wrong here? How can I tell that
python manage.py has accepted my test_settings?

On Jan 26, 10:16 am, davenaff  wrote:
> Malcolm,
>
> Thanks a lot for the pointer.  For anyone else interested, here is
> what my settings-test.py looks like:
>
> from settings import *
>
> #CSRFMiddleware breaks authtests
> MIDDLEWARE_CLASSES = list(MIDDLEWARE_CLASSES)
> MIDDLEWARE_CLASSES.remove
> ('django.contrib.csrf.middleware.CsrfMiddleware')
>
> # Turn this off to allowteststhat look at http status to pass
> PREPEND_WWW = False
>
> I then run the test suite using this command:
> python manage.py test --settings=mysite.settings-test.py
>
> Best,
> Dave
>
> On Jan 22, 4:50 pm, Malcolm Tredinnick 
> wrote:
>
> > On Thu, 2009-01-22 at 15:17 -0800,davenaffwrote:
> > > What is the best way to disable a specific middleware when running
> > > djangotests?
>
> > > This ticket was designated wontfix, so I get test failures on the auth
> > >testsevery time I run our test suite:
> > >http://code.djangoproject.com/ticket/9172#comment:12
>
> > > I'd prefer not to have to edit settings.py every time I run ourtests,
> > > and of course I don't liketeststhat fail...
>
> > Create a settings file for your testing purposes. It imports your
> > standard settings file and then modifies any settings that are specific
> > for thetests(e.g. altering the MIDDLEWARE_CLASSES tuple).
>
> > Regards,
> > Malcolm
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: User Profiles and Fixtures

[stryderjzw]

Well, it looks like I was able to solve this particular problem.

In the fixtures, I changed the order when loading the data. I now load
the Profile first, and then the User. That works.

I guess writing the problem down helped me think of potential
solutions.  :P

Still, I'm going to have to alter dumpdata manually everytime.


On Feb 1, 12:22 am, stryderjzw <stryder...@gmail.com> wrote:
> Hi!
>
> I did some searching, but I felt it's going nowhere, so here's the
> question.
>
> I'm using Django 1.1 r9756, the one where tests are using
> transactions.
>
> I have a user profile automatically created with signals, as below:
>
> def create_player(sender, instance=None, **kwargs):
>         if instance is None:
>                 return
>         player, created = Player.objects.get_or_create(user=instance)
> post_save.connect(create_player, sender=User)
>
> When I run multiple tests together, it gives me IntegrityError:
>
> IntegrityError: duplicate key value violates unique constraint
> "agent_player_user_id_key"
>
> It seems like it's trying to create the player again, but can't
> because its' already created.
>
> Anyone else run into this problem?
>
> Thanks!
> Justin
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

User Profiles and Fixtures

[stryderjzw]

Hi!

I did some searching, but I felt it's going nowhere, so here's the
question.

I'm using Django 1.1 r9756, the one where tests are using
transactions.

I have a user profile automatically created with signals, as below:

def create_player(sender, instance=None, **kwargs):
if instance is None:
return
player, created = Player.objects.get_or_create(user=instance)
post_save.connect(create_player, sender=User)


When I run multiple tests together, it gives me IntegrityError:

IntegrityError: duplicate key value violates unique constraint
"agent_player_user_id_key"


It seems like it's trying to create the player again, but can't
because its' already created.

Anyone else run into this problem?

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

POST still occurs after HttpResponseRedirect

[stryderjzw]

Hi,

Here's part of my code:

class NewAssignmentFormPreview(FormPreview):

def done(self, request, form):
assignment = form.save(commit=False)
assignment.save()

...

return HttpResponseRedirect(assignment.get_absolute_url())


I do an HttpResponseRedirect to go to the assignment page after it's
been created.

However, when I do a refresh on that page, it still asks me if I want
to submit POST data and an additional assignment is created. I thought
HttpResponseRedirect is suppose to prevent that.

Any ideas?

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

Re: Python package names

[stryderjzw]

Ah, I've been busy past couple of days.. but there's some interesting
ideas here.

Thanks!
Justin


On Nov 3, 6:35 am, "Valts Mazurs" <[EMAIL PROTECTED]> wrote:
> Sure, I also keep django apps outside site-packages directory but it is not
> really the same level of convenience :)
>
> Valts.
>
> On Mon, Nov 3, 2008 at 4:07 PM, Jonathan Buchanan <
>
> [EMAIL PROTECTED]> wrote:
>
> > On Mon, Nov 3, 2008 at 1:59 PM, Valts Mazurs <[EMAIL PROTECTED]> wrote:
> > > Usually Django applications are specific to Django and are not really
> > usable
> > > outside Django. That's why seeing "tagging" in my site-packages directory
> > > might confuse me as I could think that this package supports some general
> > > tagging.
>
> > > Valts.
>
> > You can put any directory on your PYTHONPATH - it doesn't necessarily
> > have to be in site-packages.
>
> > Personally, I have django_apps and django_projects directories on my
> > PYTHONPATH for obvious purposes, which are nowhere near my
> > site-packages.
>
> > Jonathan.
>
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---

Re: Python package names

[stryderjzw]

Hmm, I tried django_tagging, but it still gives me ImportErrors.  I
think it's because, for django-tagging project, they internally look
for tagging as the package name.



On Nov 2, 11:44 pm, Daniel Roseman <[EMAIL PROTECTED]>
wrote:
> On Nov 3, 4:58 am, stryderjzw <[EMAIL PROTECTED]> wrote:
>
>
>
> > HI,
>
> > This is semi-off topic, but it is a python question.
>
> > I'm trying to use some of the generic django applications, like django-
> > tagging. Taking django-tagging, for example, it requires me to symlink
> > the source folder to "site-packages/tagging". However, I want to keep
> > site-packages structured and keep all the django packages named the
> > same, so I want to name the folder "site-packages/django-tagging".
> > This gives me all sorts of ImportErrors.
>
> > Am I stuck with what the package requires me to name the folder? Is
> > there some way of aliasing packages or renaming them?
>
> > Cheers!
> > Justin
>
> Package names must be valid Python identifiers - so they can't contain
> hyphens ('-'). django_tagging would be OK.
> --
> DR.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---

[OT] Python package names

[stryderjzw]

HI,

This is semi-off topic, but it is a python question.

I'm trying to use some of the generic django applications, like django-
tagging. Taking django-tagging, for example, it requires me to symlink
the source folder to "site-packages/tagging". However, I want to keep
site-packages structured and keep all the django packages named the
same, so I want to name the folder "site-packages/django-tagging".
This gives me all sorts of ImportErrors.

Am I stuck with what the package requires me to name the folder? Is
there some way of aliasing packages or renaming them?

Cheers!
Justin
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---

Re: superuser has no rights with newforms admin

[stryderjzw]

Strange, I'm getting the message "You don't have permission to edit
anything." on the admin homepage. I've done admin.autodiscover() on
the project urls page, I've created admin.py files for my models and
registered the classes with admin.site.register().

Any clues?

Cheers!
Justin


On Jul 19, 10:43 am, Brian Rosner <[EMAIL PROTECTED]> wrote:
> On Jul 19, 2008, at 10:36 AM, Eric Abrahamsen wrote:
>
> > Short answer: register all your models with admin.site.register(), and
> > use admin.autodiscover() too.
>
> This is correct. admin.autodiscover() simply imports admin.py modules  
> in your INSTALLED_APPS. Previously, in the days of the branch, there  
> was a time when there was no convention and people all relied on  
> importing the admin module in their __init__.py which worked well for  
> many, but others had really bad failures.
>
> One thing to keep in mind that really isn't described as well as it  
> could in the docs is that admin.autodiscover() is really there for  
> convenience. Most of the timeyouwill only ever need to register your  
> models with the default AdminSite instance which is located at  
> django.contrib.admin.site. However, ifyouneed tohavemore than one  
> admin site or would like to modify which models are displayed on a  
> single admin thenyouwill likely be creating your own AdminSite class  
> and registering models to that instead of the default. In which case  
> the admin.autodiscover() is not needed and app admin.py module merely  
> become a place for storing ModelAdmin classes and if its a reusable  
> appyouwould also keep around register calls for the default  
> AdminSite instance for the user common case.
>
> Brian Rosnerhttp://oebfare.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---

Re: Templates with multiple repeating blocks

[stryderjzw]

Thanks, everyone.

I like this idea.  That really helped. I hope this gets considered.

Cheers,
Justin

On Jan 3, 1:16 pm, AmanKow <[EMAIL PROTECTED]> wrote:
> I posted a diff on dpaste:  http://dpaste.com/hold/29777/
>
> This is for a change to django/template/loader_tags.py
>
> This change would add an explicit reuse_block tag.
>
> {% block menu %} ... {% endblock %}
>
> ...
>
> {% reuse_block menu %}
>
> This change will actually reuse the parsed block.  It does not create
> a new block, getting around issues of multiple block definitions.
>
> This change could be considered for 1.0, it has minimal invasiveness
> and is backwards compatible.
>
> Thoughts?  Comments?
> Wayne
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---

Templates with multiple repeating blocks

[stryderjzw]

Hi,

I have the same situation as a thread (http://groups.google.com/group/
django-users/browse_thread/thread/2dbb2b7f01951a2/efbeb1f74be6e454?
lnk=gst=multiple+template+block) started in 2005. The idea is that
in my template, I want to use the same template block for both the
 and  tags.

I didn't seem to find any solutions for this. Has this been considered
since 2005? If not, what's a good solution to solve this problem? I'm
just duplicating this right now in my template.

Thanks,

Justin

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---

edit_inline fields does not save

[stryderjzw]

Hi,

I'm having a similar problem to this thread below:
http://groups.google.com/group/django-users/browse_thread/thread/608554256525c37e/6c944a02a622ba53?lnk=gst=edit_inline+does+not+save=1#6c944a02a622ba53

For my problem, I'm creating a GroupProfile, similar to the well known
UserProfile. I want GroupProfile to be editable in the admin with
Group, so I use edit_inline. Below is the snippet of my code:

from django.contrib.auth.models import Group

class GroupProfile(models.Model):
group = models.ForeignKey(Group, unique=True,
  edit_inline=True, num_in_admin=1,
core=True)
secret_key = models.CharField(maxlength=8, blank=True, null=True,
core=True)
creation_date = models.DateField(auto_now_add=True, core=True)
expiry_date = models.DateField(blank=True, null=True, core=True)

def __unicode__(self):
return "Group Profile for %s" % self.group.name

Whenever I edit any field in GroupProfile, for example secret_key,
GroupProfile does not get saved.

I'm using the current SVN version of Django, revision 5758. Does
anyone have any suggestions?  Can someone reproduce this?

Thanks!
Justin


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---

Re: problem to save..

[stryderjzw]

http://www.djangoproject.com/documentation/authentication/

This should be a good start!  Also check out chapter 12 of django book
at www.djangobook.com.

Justin

On Jul 26, 12:08 am, "Marco A." <[EMAIL PROTECTED]> wrote:
> I am a newbie !
>
> I doesnt have esperience whit django and web developing.. so I have some
> problem to make the thing running good :|
>
> There are an example of User Build-in model usage ?
>
> Thanks
>
> MA.
>
> 2007/7/25, De Rowe <[EMAIL PROTECTED]>:
>
>
>
> > On Wed, 25 Jul 2007 15:33:19 +0200, Horst Gutmann <[EMAIL PROTECTED]>
> > wrote:
>
> > > Marco A. wrote:
> > >> HI !
> > >> In model I have :
>
> > >> from django.db import models
>
> > >> # Create your models here.
> > >> class User(models.Model):
> > >> User = models.CharField(maxlength=200)
> > >> Pasw = models.CharField(maxlength=16)
> > >> def __unicode__(self):
> > >> return self.question
> > >> def was_published_today(self):
> > >> return self.User
> > >> class Admin:
> > >>pass
>
> > > Have you sync'd the database? Btw.: why do you give fields uppercase
> > > names?
>
> > > - Horst
>
> > Lastly, why not use the built-in User model that comes with Django?  Using
> > it allows your users to be seen by all apps under your project.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@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-users?hl=en
-~--~~~~--~~--~--~---