Re: Fixtures won't load twice in same testcase
Hi Rich, Regarding a couple of things you mentioned on Django-developers: On Thursday, 5 May 2016 19:20:16 UTC+1, Rich Rauenzahn wrote: > > > Thanks, Tim. > > Unfortunately I can't move past Django 1.7 yet -- dependencies. I've been > marching my way up one revision at a time hopefully up to 1.9 as a way to > keep the scope of what breaks under control as I move through each major > revision and stabilize my project. Then I attack replacing dependencies. > > I really think I've found a bug here ... which I hope to suggest a patch > for and submit, hence the post to the developers channel, but I can go back > to the users group for now... My recent experience with that list doesn't > bode well, however, and I don't have high hopes with anyone there able to > respond at the internals level I may need to track down the issue. I've > almost rewritten my tests to just load raw sql, but if there is a bug here > I'd like to help find it rather than work around/ignore it. > Fixture loading was changed in Django 1.8 [1], so even if you have found a bug in Django 1.7, there's a good chance that behaviour will be different in Django 1.8 and later. > But In this particular run I'm currently tracing, rich is already in the > db (as the only entry) as pk=5 (via fixture loading process). For one, > this tells me the sequence generators aren't always resetting between > fixture loads/tests. > > Sequences *are not* reset between test cases by default [2]. Perhaps you need to change your code so that it doesn't assume that the user has pk=1, or set reset_sequences = True. It's difficult to offer any more advice, because you haven't posted any code that can reproduce the problem. It doesn't need to be the actual code, in fact the simpler the example is the better. Cheers, Alasdair [1]: https://docs.djangoproject.com/en/1.9/releases/1.8/#testcase-data-setup [2]: https://docs.djangoproject.com/en/1.9/topics/testing/advanced/#django.test.TransactionTestCase.reset_sequences -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/d877ef6b-75d2-4197-85ab-9c0901e7ad95%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: django1.7, python3.4 and MySQL
Hi eduardo, Have you tried the following? pip install mysqlclient Usually, you should use the package name, you don't need to specify the specific wheel you want to install. Cheers, Alasdair On 20/05/15 16:03, eduardo.canaljun...@gmail.com wrote: Hi, sorry but I tryed to install mysqlclient-1.3.6-cp34-none-win_amd64.whl using pip (pip install mysqlclient-1.3.6-cp34-none-win_amd64.whl) and I can't, the pip launch de exceptio UnsupportedWheel, I have installed Python3.4.2 in Windows8.1 and I don't know if the error happens by a version problem. I really need some help. Thanks ERROR LOG REPORT: C:\Python34\Scripts\pip run on 05/20/15 10:50:28 mysqlclient-1.3.6-cp34-none-win_amd64.whl is not a supported wheel on this platform. Exception information: Traceback (most recent call last): File "C:\Python34\lib\site-packages\pip\basecommand.py", line 122, in main status = self.run(options, args) File "C:\Python34\lib\site-packages\pip\commands\install.py", line 257, in run InstallRequirement.from_line(name, None)) File "C:\Python34\lib\site-packages\pip\req.py", line 167, in from_line raise UnsupportedWheel("%s is not a supported wheel on this platform." % wheel.filename) pip.exceptions.UnsupportedWheel: mysqlclient-1.3.6-cp34-none-win_amd64.whl is not a supported wheel on this platform. -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. Building 87, Dunsfold Park, Stovolds Hill, Cranleigh, Surrey, GU6 8TB, UK -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/555CB581.50005%40memset.com. For more options, visit https://groups.google.com/d/optout.
Re: Django 1.8 tutorial-Chapter4: ValueError at /polls/1/vote/
On 14/05/15 02:50, charito.romeo wrote: | | The problem is that there is a new line in the middle of "{{ choice.id }}". Change it to: value="{{ choice.id }}"/> Cheers, Alasdair -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. Building 87, Dunsfold Park, Stovolds Hill, Cranleigh, Surrey, GU6 8TB, UK -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/55548D93.3000701%40memset.com. For more options, visit https://groups.google.com/d/optout.
Re: Django 1.8 ImportError: No module named formtools
On 11/03/15 14:22, Neto wrote: Hi Simon, pip install django-formtools doesn't work. Could not find any downloads that satisfy the requirement django-formtools It looks like it hasn't been django-formtools hasn't been released on PyPi yet. There's an issue [1] on the github repository to make a PyPi release. Django 1.8 is in beta at the moment, hopefully django-formtools will be on PyPi by the time Django 1.8 is released. In the meantime, you can install django-formtools from github with: pip install git+ssh://g...@github.com/django/django-formtools Cheers, Alasdair [1]: https://github.com/django/django-formtools/issues/5 Em quarta-feira, 11 de março de 2015 03:12:06 UTC-3, Simon Charette escreveu: Hi Neto, Here's an excerpt from the Django 1.8 release note <https://docs.djangoproject.com/en/dev/releases/1.8/#removal-of-django-contrib-formtools>: The formtools contrib app has been moved into a separate package. *django.contrib.formtools* itself has been removed. The docs provide migration instructions <https://docs.djangoproject.com/en/dev/ref/contrib/formtools/#formtools-how-to-migrate>. The new package is available on Github <https://github.com/django/django-formtools/> and on PyPI. TLDR; pip install django-formtoolsand replace all your references to *django.contrib.formtools* to *formtools*. Simon Le mercredi 11 mars 2015 00:33:29 UTC-4, Neto a écrit : I'm trying to use form wizard but when I put 'django.contrib.formtools', in INSTALLED_APPS appear on my terminal 'ImportError: No module named formtools' -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com <mailto:django-users+unsubscr...@googlegroups.com>. To post to this group, send email to django-users@googlegroups.com <mailto:django-users@googlegroups.com>. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/4bc1d119-292b-4514-bce3-b2a0e9176e7e%40googlegroups.com <https://groups.google.com/d/msgid/django-users/4bc1d119-292b-4514-bce3-b2a0e9176e7e%40googlegroups.com?utm_medium=email&utm_source=footer>. For more options, visit https://groups.google.com/d/optout. -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. Building 87, Dunsfold Park, Stovolds Hill, Cranleigh, Surrey, GU6 8TB, UK -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/55005756.50306%40memset.com. For more options, visit https://groups.google.com/d/optout.
Re: TemplateSyntaxError with {% cycle "Hello, how are you?" "Fine!" %}
On 05/03/15 17:23, Carsten Fuchs wrote: If you use single quotes and render the template, it outputs 'Hello', not 'Hello, how are you?' as expected. As expected? Why please? Docs say that with single or double quotes, the values are treated as string literals. Sorry, I wasn't clear. By 'as expected', I meant that you want the cycle tag to return "Hello, how are you". Switching to single quotes isn't a fix, because it only returns 'Hello'. Cheers, Alasdair -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. Building 87, Dunsfold Park, Stovolds Hill, Cranleigh, Surrey, GU6 8TB, UK -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/54F97C30.5050303%40memset.com. For more options, visit https://groups.google.com/d/optout.
Re: TemplateSyntaxError with {% cycle "Hello, how are you?" "Fine!" %}
Hi Carsten, Vijay On 05/03/15 16:24, Carsten Fuchs wrote: > Dear Django fellows, > > using Django 1.7.5, I have a problem with commas in string literals in > the cycle tag, e.g. with > > {% cycle "Hello, how are you?" "Fine!" %}. I can reproduce the problem with your sample code. I think the reason is that the cycle tag supports an older syntax for backwards compatibility reasons. {% cycle row1,row2,row3 %} It looks like this prevents you from using commas in strings when using the new syntax. > This happens with or without {% load cycle from future %} The future version of the cycle tag applies HTML escaping to its variables. So using it or not using it shouldn't have any affect on your issue. A work around would be to assign "Hello, how are you" to a variable. {% with hello="Hello, how are you?" {% cycle hello "Fine!" %}. {% endwith %} On 05/03/15 16:48, Vijay Khemlani wrote: > Changing the double quotes for single quotes seems to do the trick, but I don't know why it works If you use single quotes and render the template, it outputs 'Hello', not 'Hello, how are you?' as expected. Cheers, Alasdair [1] https://docs.djangoproject.com/en/1.7/ref/templates/builtins/#cycle -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. Building 87, Dunsfold Park, Stovolds Hill, Cranleigh, Surrey, GU6 8TB, UK -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/54F889F2.9040107%40memset.com. For more options, visit https://groups.google.com/d/optout.
Re: TemplateSyntaxError with {% cycle "Hello, how are you?" "Fine!" %}
On 05/03/15 16:53, Alasdair Nicol wrote: {% with hello="Hello, how are you?" {% cycle hello "Fine!" %}. {% endwith %} Oops, that should have read: {% with hello="Hello, how are you?" %} {% cycle hello "Fine!" %}. {% endwith %} -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. Building 87, Dunsfold Park, Stovolds Hill, Cranleigh, Surrey, GU6 8TB, UK -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/54F88A38.6020906%40memset.com. For more options, visit https://groups.google.com/d/optout.
Re: malicious requests?
Hi Alex, There is no security implication adding 'example.com.' (with trailing dot) to your ALLOWED_HOSTS setting. There is some more information in the ALLOWED_HOSTS setting docs. From https://docs.djangoproject.com/en/1.7/ref/settings/#allowed-hosts In previous [<= 1.6.X] versions of Django, if you wanted to also > allow the fully qualified domain name (FQDN), which some browsers can send inthe Host header, you had to explicitly add another > ALLOWED_HOSTS entry that included a trailing period. > In Django 1.7, the trailing dot is stripped when performing host > validation, thus an entry with a trailing dot isn’t required. cheers, Alasdair On 22/12/14 12:05, Alex Haylock wrote: Thanks Markus. So, as per the RFC, are 'example.com' and 'example.com.' considered to be the same domain, or two separate domains? Are there any security implications if I add 'example.com.' to ALLOWED_HOSTS to cater for these requests? Thanks, Alex. On 22/12/14 11:52, Markus Holtermann wrote: Hey Alex, a trailing . in the host header is valid per RFC 3986: http://tools.ietf.org/html/rfc3986#section-3.2.2: The rightmost domain label of a fully qualified domain name in DNS may be followed by a single "." /Markus On Monday, December 22, 2014 12:44:25 PM UTC+1, Alex Haylock wrote: Are there any known attack vectors that involve appending a period/ full-stop to a sites domain name? My Django application throws a handful of errors in production every day: ERROR: Invalid HTTP_HOST header: 'www.example.com.'. You may need to add u'www.example.com <http://www.example.com>.' to ALLOWED_HOSTS. (note the trailing period) Is this malicious behaviour, or just users mistyping the URL? Also, browsers are clearly treating the final '.' as part of the path (as these requests are reaching my application), but Django is treating the '.' as part of the hostname. Which is right? -- Regards, Alex -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. Building 87, Dunsfold Park, Stovolds Hill, Cranleigh, Surrey, GU6 8TB, UK -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/54982391.6050604%40memset.com. For more options, visit https://groups.google.com/d/optout.
Re: Replacing usage of form._errors in Django 1.7
Hi Collin, On 17/11/14 21:19, Collin Anderson wrote: Hi Alasdair, I'm upgrading to Django 1.7, and updating my forms to use the new form.add_errors() method. I have one remaining pattern which uses form._errors. class MyForm(forms.Form): ... def clean(): cleaned_data = super(MyForm, self).clean() if not self._errors: do_something() I only want to call do_something() if no errors have been found during the validation so far. I'd rather not use self._errors, since it is now a private API according to the release notes [1]. What's the recommended way to replace self._errors here? Is it ok to use self.errors instead? Looking at the source code [2], errors is a property, not an attribute. By the time the clean() method is called, self._errors should have been created, so I think that accessing self.errors should be safe. The doc says it's ok. "Since the field validation methods have been run by the time clean() is called, you also have access to the form’s errors attribute which contains all the errors raised by cleaning of individual fields." https://docs.djangoproject.com/en/dev/ref/forms/validation/#form-subclasses-and-modifying-field-errors Thanks for your reply, and your link to the docs. I can go ahead and replace my occurrences of self._errors with self.errors with confidence :) Cheers, Alasdair -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. Building 87, Dunsfold Park, Stovolds Hill, Cranleigh, Surrey, GU6 8TB, UK -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/546E0B87.7050001%40memset.com. For more options, visit https://groups.google.com/d/optout.
Replacing usage of form._errors in Django 1.7
Hi, I'm upgrading to Django 1.7, and updating my forms to use the new form.add_errors() method. I have one remaining pattern which uses form._errors. class MyForm(forms.Form): ... def clean(): cleaned_data = super(MyForm, self).clean() if not self._errors: do_something() I only want to call do_something() if no errors have been found during the validation so far. I'd rather not use self._errors, since it is now a private API according to the release notes [1]. What's the recommended way to replace self._errors here? Is it ok to use self.errors instead? Looking at the source code [2], errors is a property, not an attribute. By the time the clean() method is called, self._errors should have been created, so I think that accessing self.errors should be safe. cheers, Alasdair [1]: https://docs.djangoproject.com/en/dev/releases/1.7/#form-add-error [2]: https://github.com/django/django/blob/1.7.1/django/forms/forms.py#L150 -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. Building 87, Dunsfold Park, Stovolds Hill, Cranleigh, Surrey, GU6 8TB, UK -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/5465E3AC.2040804%40memset.com. For more options, visit https://groups.google.com/d/optout.
Re: Did Ubuntu 14.04 or Linux Mint 17 break your Django project files?
Hi, On 16/07/14 21:53, Pepsodent Cola wrote: Hi, I have been learning and developing my first Django project in Linux Mint 14 for about 2 years. This month I moved my Django project files to Linux Mint 17. When I run my unit tests then I get this error, which I don't remember having when I was testing code in Linux Mint 14. *IntegrityError: NOT NULL constraint failed:* userprofile_userprofile.likes_cheese NOT NULL constraint failed I try to change the old code from this. class UserProfile(models.Model): user = models.OneToOneField(User) likes_cheese = models.*BooleanField()* favourite_hamster_name = models.CharField(max_length=50) It sounds looks like your operating system upgrade has upgraded Django to 1.6. In Django 1.6 you need to explicitly set default=False on your boolean fields, otherwise they default to None > likes_cheese = models.BooleanField(default=False) For more info see the release notes [1]. It would be worth going through them to see if there are any other changes you should or need to make. [1]: https://docs.djangoproject.com/en/dev/releases/1.6/#booleanfield-no-longer-defaults-to-false Cheers, Alasdair -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. Building 87, Dunsfold Park, Stovolds Hill, Cranleigh, Surrey, GU6 8TB, UK -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/53C6EF99.5050205%40memset.com. For more options, visit https://groups.google.com/d/optout.
Re: Writing your first Django app, part 1 (1.6)
Hi, The Django tutorial has changed between 1.6 and the current development version. Because your error references the Choices.question field, it sounds as if you may have been following the development version in places. Make sure that you follow the Django 1.6 tutorial throughout. If you retry and follow the instructions, it should work. You can select the version of the tutorial using the selector in the bottom-right corner of the screen. Cheers, Alasdair On 10/12/13 22:19, Suhendri wrote: Hi, I'm new in Django, I'm excited with Django so I have to following the existing tutorial to knew how to create a program with Django. I started with tutorial 1, Writing your first Django app, part1. I used Django 1.6 and SQLite I followed the instructions from the starting of the tutorial, until the line of *# Create three choices* I got an error. When I typed p.choice_set.create(choice_text='Not much', votes=0), I got an error: *AttributeError: Traceback (most recent call last):* *...* *AttributeError: 'Choice' object has no attribute 'question'* I followed the tutorial exactly as it shown on web, but I got an error on that line. Did I missed something in the tutorial ? Could you help me, to solve this problem so i can continue learn the tutorial. -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. Building 87, Dunsfold Park, Stovolds Hill, Cranleigh, Surrey, GU6 8TB, UK -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/52A839AB.1070607%40memset.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Long url parameter in GET request locks python
On 30/01/13 16:38, Shawn H wrote: I posted this question yesterdat at stack overflow <http://stackoverflow.com/questions/14589244/why-would-django-get-request-with-long-url-lock-python>, but I'm wondering if this is a bug. I have a url that accepts one text parameter, allows spaces, and calls a very simple view that checks if there are objects with a project name that matches the text parameter value. The view returns a simple json string indicating whether there's a project with that name already in the database. It works great, repeatedly, with short parameter values. It locks up python on certain long string values. I've tested up to 50 characters, and just length doesn't trigger it. What does seem to repeatedly trigger it are long strings with multiple spaces. I've tested my url regex matching and those long strings match just fine; my concern is that for some reason inside the view that long string is causing problems. I'm using Django 1.4 with the built in webserver for testing. Any help that can be provided will be greatly appreciated. -- Hi Shawn, I've answered your question on Stack Overflow, but I'll post it here as well: Since you are going to check whether `aProjectName` already exists in the database, there's no need for you to make the regex so complicated. I suggest you simplify the regex to url(r'^chargeback/checkDuplicateProject/(?P[\w+\s-]*)/$', 'chargeback.views.isProjectDuplicate'), For a further explanation, see the question "url regex keeps django busy/crashing" [1] from the django-users group. [1]: https://groups.google.com/d/msg/django-users/Bxq9i0mttSc/DEz7S7M8lxAJ Cheers, Alasdair -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, Surrey, GU2 7YD, UK. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: A question about Model.full_clean
On 01/06/12 14:47, David Markey wrote: Hi All, Say I have this model class TestModel(models.Model): my_test = models.CharField(max_length=512, blank=True) And I try this: In [1]: from core.base.models import TestModel In [2]: test_model = TestModel() In [3]: test_model.my_test =*""* In [4]: test_model.full_clean() In [5]: test_model.save() *Ok cool, this is expected.* * * *How about:* In [6]: test_model2 = TestModel() In [7]: test_model2.my_test =*None* In [8]: test_model2.full_clean() In [9]: test_model2.save() ##*IntegrityError raised* Is there a way for full_clean() to catch that the "my_test" field is Null when it shouldn't be, when blank=True? If I have blank=False, it wont validate when my_test="". I think the behaviour is explained by the clean_fields method called by full_clean: for f in self._meta.fields: if f.name in exclude: continue *# Skip validation for empty fields with blank=True. The developer # is responsible for making sure they have a valid value. *raw_value = getattr(self, f.attname) if f.blank and raw_value in validators.EMPTY_VALUES: continue https://github.com/django/django/blob/master/django/db/models/base.py#L851 I can't think of a way for you to avoid checking for whether test_model2.my_test is None. Can you change the code that is assigning test_model2.my_test = None? The default value for the CharField is the empty string, which as you show in your first example, doesn't cause a problem. Cheers, Alasdair -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, Surrey, GU2 7YD, UK. -- 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: Possible bug in the Django documentation
Hi Joseph, On 14/05/12 14:26, Joseph Mornin wrote: Hi, I noticed a possible bug in the Django documentation. The authentication docs (at https://docs.djangoproject.com/en/dev/topics/auth/) include this sample code for registration/login.html: http://dpaste.com/747993/ Running this code gives me this error: ### TemplateSyntaxError at /login Caught NoReverseMatch while rendering: Reverse for ''django.contrib.auth.views.login'' with arguments '()' and keyword arguments '{}' not found. ### I was able to fix this by removing the quotes around the url parameter on line 9 (with help from this StackOverflow question: http://stackoverflow.com/questions/4578685/noreversematch-while-rendering-reverse-for-django-contrib-auth-views-login). Hope this is useful. Cheers, J. In earlier versions of Django, the url tag did not use quotes. Starting in Django 1.3, this was gradually changed so that the url tag was consistent with other tags. The change is described in the release notes for Django 1.3 [1] The url you link to is for the development version of Django. If you look at the same page for Django 1.4 [2], you'll see that the template includes the following statement. {% load url from future %} If you don't include this, then the alternative is to remove the quotes, as you found. Hope that explains things. Cheers, Alasdair https://docs.djangoproject.com/en/dev/releases/1.3/#changes-to-url-and-ssi https://docs.djangoproject.com/en/1.4/topics/auth/ -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, Surrey, GU2 7YD, UK. -- 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: Problems with {% url %} in templates
Hi Jamie, On 29/03/12 20:49, Jamie Lawrence wrote: I'm very confused… this has worked fine in the past. Django 1.3.1 In myproject/urls.py: urlpatterns = patterns('', (r'^d/events/(.*)$', include('myproject.events.urls')), […] Don't include the (.*)$ in the regex for the include. The documented pattern [1] for the include is (r'^d/events/', include('myproject.events.urls')), Regards, Alasdair [1]: https://docs.djangoproject.com/en/dev/topics/http/urls/#including-other-urlconfs -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, Surrey, GU2 7YD, UK. -- 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: Trouble setting up website with mysql as backend
On 17/03/12 20:49, Swaroop Shankar V wrote: Hello All, I was developing a website and the development was all done using sqlite database. Now the development is almost complete so i need to test the site using mysql. When i did a syncdb on a fresh database i got the following error: Traceback (most recent call last): File "./manage.py", line 19, in execute_manager(settings) File "/usr/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 438, in execute_manager utility.execute() File "/usr/local/lib/python2.7/site-packages/django/contrib/auth/management/__init__.py", line 51, in create_permissions content_type=ctype File "/usr/lib64/python2.7/site-packages/MySQLdb/cursors.py", line 92, in _warning_check warn(w[-1], self.Warning, 3) _mysql_exceptions.Warning: Data truncated for column 'name' at row 1 When you run syncdb for the django auth app, it creates permissions for your models [1]. It looks like it's trying to insert a permission with a name longer than 50 characters, so it's getting truncated. Perhaps you have: * defined a custom permission with a really long name, or * defined a model with a really long name so that "Can view " is longer than 50 characters. Regards, Alasdair Nicol [1]: https://docs.djangoproject.com/en/dev/topics/auth/#default-permissions -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, Surrey, GU2 7YD, UK. -- 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: Help on forms.py
Hi Stanwin, On 16/02/12 17:43, Stanwin Siow wrote: Hello, I'm trying to modify the default registration forms.py by adding in more fields. Currently it's like that: = *keyword_info = {* *"queryset" : Keyword.objects.all(),* *}* class RegistrationForm(forms.Form): *keywords = forms.ChoiceField(choices=keyword_info)* *label=_(u'keyword'))* You're using a ChoiceField, which requires a list of 2-tuples, for example: choices = [('keyword1', 'keyword1'), ('keyword1', 'keyword1')] What you probably want is a ModelChoiceField [1], which takes a queryset argument. keywords = forms.ModelChoiceField(queryset=Keyword.objects.all()) [1]: https://docs.djangoproject.com/en/dev/ref/forms/fields/#modelchoicefield cheers, Alasdair -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, Surrey, GU2 7YD, UK. -- 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: Model.delete() was not called.
Hi, On 16/02/12 10:53, SomeoneToIgnore wrote: Hello. I'm using Django 1.3.1. I've got some strange behaviour while deleting an object in admin panel. Here's the code from models.py: class Poll(models.Model): question = models.CharField(max_length=200) pub_date = models.DateTimeField('date published') def was_published_today(self): return self.pub_date.date() == datetime.date.today() was_published_today.short_description = 'Published today?' def __unicode__(self): return self.question def delete(self, using=None): print "Deleted" super(Poll, self).delete(using) It is just the code from django tutorial with delete() method overriden. There was an issue: https://code.djangoproject.com/ticket/11022 If I open the object's properties page and delete an object using Delete button on that page everything works fine and message displays in the console. But if I check the object's checkoxes (insted of opening their property list pages), select "Delete selected polls" action and press the Go button, the Delete multiple objects page opens. Then I press "Yes, I'm sure button" and objects are successfully deleted. But their delete() method are not triggered so i don't get the message "Deleted" in the console. It does not matter if I choose one or multiply objects - the message still does not appear in the console. Should I consider this behaviour as a bug or I am doing something wrong? The delete select action uses the queryset's delete method [1], which means the model's delete method is not called. It's not a bug, the behaviour is documented on the admin actions page. [2] Cheers, Alasdair [1]: https://docs.djangoproject.com/en/dev/topics/db/queries/#deleting-objects [2]: https://docs.djangoproject.com/en/dev/ref/contrib/admin/actions/#admin-actions -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, Surrey, GU2 7YD, UK. -- 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: MySQL limit sub-query problem
Hi RJ, On 26/01/12 20:10, rahul jain wrote: All, I have a query. Its working fine on sqlite server but not working fine on mysql server. This is the error message on mysql server: "This version of MySQL doesn't yet support 'LIMIT& IN/ALL/ANY/SOME subquery" This is the query: inner_q = obj_unassigned.values_list('pk', flat=True)[:diff] total_objects = (obj_assigned | obj_class.objects.filter(pk__in=inner_q)) Any help appreciated on how to fix this. Thanks. RJ You can prevent the error by using `list()` to fetch the inner queryset in a separate query: total_objects = (obj_assigned | obj_class.objects.filter(pk__in=list(inner_q))) Alasdair -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, Surrey, GU2 7YD, UK. -- 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: change min_length in form __init__?
On 13/01/12 10:47, bruno desthuilliers wrote: On Jan 11, 12:15 pm, galgal wrote: Is there any way, to change the field's *min_length* argument inside form constructor? That doesn't work: def __init__(self, *args, **kwargs): super(CreateTeamForm, self).__init__(*args, **kwargs) self.fields['primary_color'].min_length = 4 Assuming primary_color is a CharField, this should theoretically JustWork AFAICT. What is the result ? ("doesn't work" is not really descriptive...) Hi Bruno, I answered this question on Stack Overflow earlier this week [1]. When a field with min_length is initialised, a MinLengthValidator is added to the its validators. So if you set the min_length attribute after calling parent classes __init__ method, it is 'too late' for it to have any effect. The solution is to change the field's validators in the __init__ method instead, Cheers, Alasdair [1]: http://stackoverflow.com/questions/8818261/django-change-min-length-in-form-init/ -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, Surrey, GU2 7YD, UK. -- 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: Class-Based Generic Views (CreateView) - field exclusions and defaults
On 11/01/12 20:54, Juergen Schackmann wrote: if is use this code, as proposed by russ: def form_valid(self, form): self.object.user = ... (something meaningful.. e.g., self.request.user) return super(CreateCampaignView, self).form_valid(form) i get the error 'NoneType' object has no attribute 'user'. and actually, by looking at the source code, that is exactly what is supposed to happen in a create view: self.object is set to None, as you can see in BaseCreateView def post(self, request, *args, **kwargs): self.object = None return super(BaseCreateView, self).post(request, *args, **kwargs) am i the only one having this problem? any help is highly appreciated. thanks juergen -- I agree that it looks like self.object is None, so you can't set self.object.user as Russ wrote. How about the following: def form_valid(self, form): form.instance.user = request.user return super(CreateCampaignView, self).form_valid(form) I haven't had a chance to test the code. I hope that it works, or at least leads you in the right direction! Regards, Alasdair -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, Surrey, GU2 7YD, UK. -- 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: clean function for field that may be blank
On 16/11/11 14:32, Jaroslav Dobrek wrote: Hello, I have got a class Person: class Person(models.Model): given_names = models.CharField(max_length=200) family_names = models.CharField(max_length=200) date_of_birth = models.DateField(blank=True) and a class PersonForm: class PersonForm(forms.ModelForm): def clean_date_of_birth(self): try: date_of_birth = self.cleaned_data['date_of_birth'] if date_of_birth.year< 1890: raise forms.ValidationError(u"It is very improbable for a person to be this old.") return date_of_birth except KeyError: pass The code works as expected if I leave out "blank=True" in the field date_of_birth of the class Person. But it doesn't work with blank=True. How does clean_date_of_birth have to look like, if date_of_birth is optional? Jaroslav Hi Jaroslav, When blank=True, you need to check that the user has entered a date_of_birth before you try to access its year. def clean_date_of_birth(self): date_of_birth = self.cleaned_data.get('date_of_birth') if date_of_birth: if date_of_birth.year < 1890: raise forms.ValidationError(u"It is very improbable...") return date_of_birth Regards, Alasdair -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, Surrey, GU2 7YD, UK. -- 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: Strange traceback: DoesNotExist not callable
Hi João and Torsten, On 20/10/11 18:53, João Pedro Francese wrote: I've just stumbled upon the same problem in my code. I have no clue on why it happened either. Did you ever get any progress on investigating this issue? Regards, Joao On Oct 7, 12:31 pm, Torsten Bronger wrote: Hall chen! I examine a traceback that ends with ... File "/usr/lib/python2.6/dist-packages/django/db/models/query.py", line 351, in get % (self.model._meta.object_name, num, kwargs)) TypeError: 'DoesNotExist'objectisnotcallable The error-triggering source code in query.py says def get(self, *args, **kwargs): """ Performs the query and returns a singleobjectmatching the given keyword arguments. """ clone = self.filter(*args, **kwargs) if self.query.can_filter(): clone = clone.order_by() num = len(clone) if num == 1: return clone._result_cache[0] ifnotnum: raise self.model.DoesNotExist("%s matching query doesnotexist." % self.model._meta.object_name) raise self.model.MultipleObjectsReturned("get() returned more than one %s -- it returned %s! Lookup parameters were %s" % (self.model._meta.object_name, num, kwargs)) The last line triggers the error. This is strange for two reasons: First,DoesNotExistshould becallablefor all models. And secondly, there is noDoesNotExistin the last line but a MultipleObjectsReturned. My source code that is responsible for the error is: try: sample = self.samples.get() # Here, the TypeError occurs except (Sample.DoesNotExist, Sample.MultipleObjectsReturned): pass I've been caught out by this error before. In my case it was because I was not catching exceptions correctly *elsewhere* in my code. In another view, I had something like try: sample = self.samples.get() # Here, the TypeError occurs except Sample.DoesNotExist, Sample.MultipleObjectsReturned: pass Without the parenthesis, it's equivalent to the following in Python 2.6+ except Sample.DoesNotExist as Sample.MultipleObjectsReturned: The instance of the DoesNotExist exception overwrites Sample.MultipleObjectsReturned! When the same process is handles a different request later on, you get the type error because your code is trying to call the DoesNotExist instance which has replaced Sample.MultipleObjectsReturned. tschüss, Alasdair -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, Surrey, GU2 7YD, UK. -- 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: Filtering html for django comments
To protect against injection, you *do* want to want to use the safe argument. If you don't use the safe parameter, then the markdown filter will not escape any html in the input. http://freewisdom.org/projects/python-markdown/Django If you're not convinced, try including the following {{ text|markdown }} with and without the safe parameter! text = """ alert(boo!); **This is bold** """ Regards, Alasdair On 07/10/11 15:04, arkai...@gmail.com wrote: Hi, I am aware that Markdown is a formatting language like textile or any other. It is just that i've seen other projects using {{var|markdown:"safe"}} to protect against injected html and I don't know if that is the same, better or worse that just {{var}} without disabling autoescape. Thanks -- Arkaitz On Fri, Oct 7, 2011 at 2:50 PM, Tom Evans <mailto:tevans...@googlemail.com>> wrote: On Fri, Oct 7, 2011 at 9:00 AM, arkai...@gmail.com <mailto:arkai...@gmail.com> mailto:arkai...@gmail.com>> wrote: > Hi all, > I'm working on a comments addon for my app and I'm checking the alternatives > for urlizing and securing what users write in comments. > I thought that just using Djangos default autoescape( not doing anything) > plus the |urlize filter like " {{comment|urlize}}" would be enough, but I've > seen examples in the web using "{{comment|markdown:'safe'}}" so I was > wondering if autoescape is not enough or people are using "markdown:'safe'" > for other reasons? > > Should I be concerned if I don't use markdown:"safe" ? > > Thanks Markdown is a formatting language. People using that syntax enter their comments in markdown, and use that to turn them into HTML. Cheers Tom -- 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 <mailto:django-users@googlegroups.com>. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com <mailto:django-users%2bunsubscr...@googlegroups.com>. For more options, visit this group at http://groups.google.com/group/django-users?hl=en. -- 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. -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, Surrey, GU2 7YD, UK. -- 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: ORM only/defer calls do not work on cross-table relations
Hi John, Use select_related [1] to tell Django to 'follow' the foreign key. Try the following: testmodels = models.ATestModel.objects.all().select_related('other').only('other__name') print testmodels[0].other.name Regards, Alasdair [1]: https://docs.djangoproject.com/en/dev/ref/models/querysets/#select-related On 27/09/11 21:49, John wrote: Hey, I'm trying to improve the performance of a Django app, and noticed that you can't seem to properly defer fields when making lookups with joins. To demonstrate, I set up a test project with the following models: class ATestModel(models.Model): other = models.ForeignKey('OtherModel') class OtherModel(models.Model): name = models.CharField(max_length=32) then, in the Django shell, I set up 10 'ATestModel's and two 'OtherModel's properly linked up, and ran the following: from testmodule import models testmodels = models.ATestModel.objects.all().only('other__name') print testmodels[0].other.name Test One from django.db import connection print '\n\n'.join([x['sql'] for x in connection.queries]) SELECT "testmodule_atestmodel"."id", "testmodule_atestmodel"."other_id" FROM "testmodule_atestmodel" LIMIT 1 SELECT "testmodule_othermodel"."id", "testmodule_othermodel"."name" FROM "testmodule_othermodel" WHERE "testmodule_othermodel"."id" = 1 I also re-ran that without the 'only' call: testmodels = models.ATestModel.objects.all() print testmodels[0].other.name Test One print '\n\n'.join([x['sql'] for x in connection.queries[2:]]) SELECT "testmodule_atestmodel"."id", "testmodule_atestmodel"."other_id" FROM "testmodule_atestmodel" LIMIT 1 SELECT "testmodule_othermodel"."id", "testmodule_othermodel"."name" FROM "testmodule_othermodel" WHERE "testmodule_othermodel"."id" = 1 The 'only' call does nothing, and two queries are made when one would have sufficed (SELECT testmodule_othermodel.name FROM testmodule_atestmodel LEFT JOIN testmodule_othermodel ON testmodule_atestmodel.id = testmodule_othermodule.id). This raises a huge performance penalty for highly normalized schemas and I would even go so far as to say it in fact makes it impossible to optimize queries with a decently normalized schema. My apologies if someone has brought this up before - I was unable to see anything about it in the django tickets or mailing lists. -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, Surrey, GU2 7YD, UK. -- 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: AssertEquals __unicode__
On 25/08/11 11:34, Torsten wrote: Hi How do I do that right ? I have a class like: class Invoice ... def __unicode__(self): return unicode(str(self.created_at.year)+'/'+str(self.id)) and an test here: def test_invoice_number(self): invoice = Invoice.objects.create(created_at="2011-07-28", customer_id=1, payable_at='2012-12-12') invoice.save() self.assertEqual("Invoice: 2011/1", invoice) with the follwoing result: File "/Users/torsten/PycharmProjects/invoiz/invoice/tests.py", line 22, in test_invoice_number self.assertEqual("2011/1", invoice) AssertionError: '2011/1' != Thanks for help Torsten You want to compare the unicode string for the object, so use the unicode function. The following should work: self.assertEqual("Invoice: 2011/1", unicode(invoice)) Regards, Alasdair -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, Surrey, GU2 7YD, UK. -- 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: [ANN]: FeinCMS v1.4.0.rc1
On 08/08/11 09:09, Matthias Kestenholz wrote: Hello everyone The first release candidate of FeinCMS v1.4 hit the streets yesterday and is available at the usual places. Please note that the official repository has been moved to the feincms organization on github and does not live in my personal account anymore. Great news Matthias! We're looking forward to using 1.4, especially the django-reversion support. Regards, Alasdair -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, Surrey, GU2 7YD, UK. -- 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: url names
On 19/07/11 11:08, NISA BALAKRISHNAN wrote: how to add url names to the following entry in urls.py. ( r'^all/synchro/download/file/', "get_all_data_download" ) Use the url function [1] url( r'^all/synchro/download/file/', "get_all_data_download", name="get_all_data_download" ) Alasdair [1] https://docs.djangoproject.com/en/dev/topics/http/urls/#url -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, Surrey, GU2 7YD, UK. -- 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: Linking to Django Admin from 1.3
From the django docs on url namespaces [1] Namespaced URLs are specified using the : operator. For example, the main index page of the admin application is referenced using admin:index. This indicates a namespace of admin, and a named URL of index. So you link to the admin index in your template using: {% url admin:index %} For Django 1.3, the documented way [2] to include the admin site is: *url(r'^admin/', include(admin.site.urls)),* Regards, Alasdair Nicol [1] https://docs.djangoproject.com/en/dev/topics/http/urls/#url-namespaces [2] https://docs.djangoproject.com/en/1.3/intro/tutorial02/ On 14/07/11 15:35, eric.frederich wrote: Hello, I am moving from 1.0.2 to 1.3 and am having problems linking to the admin site from within a template. I used to have this in my template... Django Admin And I used to have this in my urls.py url(r'^admin/(.*)' , admin.site.root, name='the-django- admin'), I'm sure this was hacky even back in 1.0.2 How should I link to the admin site's index from within a template? I cannot hard code it to /admin because while this would work on development, on production it needs to be /apps/admin So I need to use the URL resoving mechanism so that the prefix gets picked up based on which environment it is on. So... simple question. How do I link to the Django admin site from within a template? Thanks, ~Eric -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, Surrey, GU2 7YD, UK. -- 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: Multiple forms into one form/trouble accessing form fields
https://docs.djangoproject.com/en/dev/ref/forms/api/#prefixes-for-forms Regards, Alasdair On 15/06/11 14:09, Thomas Weholt wrote: I got several forms I need to display in one page and post to one site. Actually, what I want to do is take all the fields from all the forms and display them as one form and post all input to one view. To avoid collision between the form fields I want to prefix the fields somehow. Say I got three forms: class UserInputForm1(forms.Form): username = forms.CharField() password = forms.CharField() class UserInputForm2(forms.Form): comment = forms.CharField() class UserInputForm3(forms.Form): like = forms.BooleanField() I want to put all fields, from all three forms, into one new form and prefix each field so I know what form the field came from. How can I do that? When I access the fields after creation it appears to be a string. An alternative to this is a FormWizard, but that makes the user click thru a bunch of steps, which could be avoided if I could get all the fields into one new form. -- Alasdair Nicol Developer, MEMSET mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, Surrey, GU2 7YD, UK. -- 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: VERY cheap django hosting?
I have used djangohosting.ch before and recommend them. As BR says it's very easy to deploy, and I thought their support was super. Alasdair On 08/06/11 22:13, Tiago Almeida wrote: I use http://djangohosting.ch/ for a small company website and haven't experienced any issues on the last 4 months. It is a shared hosting account but the machine is quite beefy and always idle :) you pay 12€ every 3 months. It is very easy to deploy django project there, unlike vps where you have to configure everything. BR, On Jun 8, 7:30 am, raj wrote: Hey guys, Just wondering if you could give me some hosts that are very cheap for django hosting? Is hostgator any good? I really don't know what to look for in a host. A lot of people are recommending web faction, but its around $9 bucks a month. I was looking in the $5 bucks a month range. Any ideas? Thank you. -Raj -- Alasdair Nicol Developer, MEMSET Dedicated Hosting mail: alasd...@memset.com web: http://www.memset.com/ Memset Ltd., registration number 4504980. 25 Frederick Sanger Road, Guildford, Surrey, GU2 7YD, UK. -- 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: login -->then on success--> my custom page
If you only need to change the success url, then use the LOGIN_REDIRECT_URL setting [1]. You won't need to customise the login page. Alasdair [1] http://docs.djangoproject.com/en/dev/ref/settings/#login-redirect-url On 05/04/11 10:14, GOUTAM KUMAR RANA wrote: please help me to make or inherit a login page which on success goes to my custom page -- 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.