Re: Mysql Quires using raw()
> Nowhere. Output is correct and as documented - you get back *RawQuerySet*. Not
> a single value.
>
> So you have to do something like:
>
> maxid = Client.objects.raw('SELECT MAX(job_no) as max_job_no FROM
> CLIENT').values_list('max_job_no', flat=True)[0]
facing this error
AttributeError: 'RawQuerySet' object has no attribute 'values_list'
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@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] Django 1.3 alpha 1 released
On Thu, Nov 11, 2010 at 01:34:43AM -0600, James Bennett wrote: > The first alpha preview package for Django 1.3 is now available. Great! > * Release notes: http://docs.djangoproject.com/en/dev/releases/1.3-alpha-1/ Is the first paragraph under "Class-based views" incomplete? With kind regards, -- Baurzhan Ismagulov http://www.kz-easy.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-us...@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 Quires using raw()
now I also try another method to get max(id)
from django.db import connection
cursor = connection.cursor()
cursor.execute('SELECT max(id) FROM automation_client')
maxid = cursor.fetchone()
output is :
(2L,)
but i want only 2 not any other character.
Is any other method to get max(id) from database tables?
Please help.
Thanks
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@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] Django 1.3 alpha 1 released
On Thu, Nov 11, 2010 at 4:15 PM, Baurzhan Ismagulov wrote: > On Thu, Nov 11, 2010 at 01:34:43AM -0600, James Bennett wrote: >> The first alpha preview package for Django 1.3 is now available. > > Great! > > >> * Release notes: http://docs.djangoproject.com/en/dev/releases/1.3-alpha-1/ > > Is the first paragraph under "Class-based views" incomplete? Somehow that one managed to slip past both myself and James during final review. It's been fixed in the repository now, but we won't do a re-release of the alpha. Well spotted, and apologies for the confusion. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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 Quires using raw()
On Tuesday 09 November 2010 12:25:30 Jagdeep Singh Malhi wrote:
> hi
> I am facing problem with raw() mysql quiers
> for example :
> maxid = Client.objects.raw('SELECT Max(id) FROM client')
>
> print maxid
>
> output is :-
>
>
> I am using Django 1.2 version.
> where I am wrong?
Nowhere. Output is correct and as documented - you get back *RawQuerySet*. Not
a single value.
So you have to do something like:
maxid = Client.objects.raw('SELECT MAX(job_no) as max_job_no FROM
CLIENT').values_list('max_job_no', flat=True)[0]
--
Jani Tiainen
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@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 Quires using raw()
On 11 November 2010 09:17, Jagdeep Singh Malhi wrote:
>
> now I also try another method to get max(id)
>
> from django.db import connection
> cursor = connection.cursor()
> cursor.execute('SELECT max(id) FROM automation_client')
> maxid = cursor.fetchone()
>
> output is :
> (2L,)
>
> but i want only 2 not any other character.
You have a 1 element tuple with a number. Ig you know anything about
Python, it shouldn't be hard to get that value from the tuple.
>
> Is any other method to get max(id) from database tables?
Starting from version 1.1 Django supports aggregation[1], so you can just write:
>>> from django.db.models import Max
>>> Client.objects.aggregate(maxid=Max('id'))
{'maxid': 2L}
And you'll get a dictionary with the value you want as a result.
[1]: http://docs.djangoproject.com/en/1.1/topics/db/aggregation/
--
Łukasz Rekucki
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@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.
'django-admin.py' is not recognized as an internal or external command
when i creating project on comand promt it says 'django-admin.py' is not recognized as an internal or external command operable program & bach file pls giv me solution i m new for django -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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: Creating A Model For Existing DB Table
no missing parenthesis ? class ept_inv(models.Model): part_num = models.CharField(max_length=20) ept_type = models.SmallIntegerField() inv_id = models.IntegerField() load_date = models.DateField() On 10 nov, 18:23, octopusgrabbus wrote: > I have an existing MySQL table. It's fairly straightforward: > > part_num char(20) > ept_type smallint (default 0) not null > inv_id integer (default 0) not null > load_date date > > columns 2 and 3 (ept_type and inv_id) form a unique key. An example of > a unique key is 43 and 80581770. > > I've tried to create a model > > from django.db import models > > # Create your models here. > class ept_inv(models.Model): > part_num = models.CharField(max_length=20) > ept_type = models.SmallIntegerField > inv_id = models.IntegerField > load_date = models.DateField > > but am getting errors on syncdb > class ept_inv(models.Model): > File "/usr/local/lib/python2.6/site-packages/django/db/models/ > base.py", line 9 > 2, in __new__ > new_class.add_to_class(obj_name, obj) > File "/usr/local/lib/python2.6/site-packages/django/db/models/ > base.py", line 2 > 12, in add_to_class > value.contribute_to_class(cls, name) > TypeError: Error when calling the metaclass bases > unbound method contribute_to_class() must be called with > SmallIntegerField i > nstance as first argument (got ModelBase instance instead) > > What should I be doing? > Thank you. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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: 'django-admin.py' is not recognized as an internal or external command
Looks like django is not on your sytem path. Have you used python much in Windows and are familiar with Environmental variables? Look like this problem has been addresses on the django forums http://thedjangoforum.com/board/thread/4/django-admin-py-error-when-installing-dj/ and here is a link from the main python site explaining python path. http://docs.python.org/using/windows.html Other than that chances are you havnt installed django right, make sure that it is sitting in the right folder inside your python directory. Dont use django and windows much, Think its c:/python/lib/sitepackages... Rob -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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: Generic Views - do you use them?
On Wed, Nov 10, 2010 at 4:35 AM, derek wrote: > I have not really understood when and why they are needed; I would be > interested to see an alternative also because it might improve my > understanding. > I've never used them before, and always avoided looking into them because I thought they were some dumbed-down way for newbies to avoid writing views. Also, the views in my company's application tend to be fairly complex and I was certain that they'd be too limiting. However, I was just reading the 1.3 alpha release notes and followed this link: http://docs.djangoproject.com/en/dev/topics/class-based-views/ It seems that they could be really useful in nearly any application (at least the ListView), even for experienced Django developers. In any case, it's an interesting read and I recommend having a look. Shawn -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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 Quires using raw()
> >>> from django.db.models import Max
> >>> Client.objects.aggregate(maxid=Max('id'))
>
> {'maxid': 2L}
>
> And you'll get a dictionary with the value you want as a result.
>
> [1]:http://docs.djangoproject.com/en/1.1/topics/db/aggregation/
Thanks for link, problem solve.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@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.
django with pinax.
Hi guys just trying to get the admin section of a pinax site working and i am getting the following error when i try and load the admin section. TemplateDoesNotExist at /admin/ admin/login.htmlRequest Method: GET Request URL: http://ourislandgeorgia.net/admin/ Django Version: 1.2.3 Exception Type: TemplateDoesNotExist Exception Value: admin/login.html Exception Location: /home/ourianet/public_html/virtfs/lib/python2.6/ site-packages/django/template/loader.py in find_template, line 138 Python Executable: /usr/bin/python Python Version: 2.6.0 Python Path: ['/home/ourianet/public_html/testpinax/apps', '/home/ ourianet/public_html/testpinax', '/home/ourianet/public_html/virtfs/ lib/python2.6', '/home/ourianet/public_html/virtfs/lib/python2.6/site- packages', '/home/ourianet/public_html', '/home/ourianet', '/usr/local/ lib/python2.6/site-packages/psycopg2-2.2.2-py2.6-linux-i686.egg', '/ usr/local/lib/python26.zip', '/usr/local/lib/python2.6', '/usr/local/ lib/python2.6/plat-linux2', '/usr/local/lib/python2.6/lib-tk', '/usr/ local/lib/python2.6/lib-old', '/usr/local/lib/python2.6/lib-dynload', '/usr/local/lib/python2.6/site-packages', '/usr/local/lib/python2.6/ site-packages/PIL', '/root/public_html/virtfs/lib/python2.6', '/home/ ourianet/public_html/virtfs/usr/share/django/contrib'] Server time: Thu, 11 Nov 2010 11:15:37 -0500 The rest of the debug info can be viewed straight from the domain. . http://ourislandgeorgia.net/admin/ Thasnks in advance for any help. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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.
Unit test failing when testing post of a comment
Hi,
I have a unit test that tests that a comment can be posted on an entry
in a Django blog. Posting a comment myself in the browser works fine,
but the test always fails with this error:
"TemplateSyntaxError: Caught VariableDoesNotExist while rendering:
Failed lookup for key [request] in u'[{}]'"
Which suggests the use of the 'request' variable in a template isn't
working. I guess it's a ContextProcessor problem, but I'm stuck as to
why it fails in the test. Here's the test:
from django.test.client import Client
from django.test import TestCase
import datetime, time
from weblog.models import Entry
from django.contrib.comments.forms import CommentSecurityForm
class WeblogBaseTestCase(TestCase):
fixtures = ['../../aggregator/fixtures/test_data.json', ]
class CommentTestCase(WeblogBaseTestCase):
def post_comment(self, entry_id=1):
form = CommentSecurityForm( Entry.live.get(pk=entry_id) )
timestamp = int(time.time())
security_hash = form.initial_security_hash(timestamp)
c = Client()
response = c.post('/cmnt/post/', {
'name': 'Bobby',
'email': 'bo...@example.com',
'url': '',
'comment': 'Hello',
'content_type': 'weblog.entry',
'timestamp': timestamp,
'object_pk': entry_id,
'security_hash': security_hash,
},follow=True)
self.failUnlessEqual(response.status_code, 200)
I'm stumped as to why this error is generated in the test, but not on
the site, and I'm not sure how to poke around to see where it's going
wrong. Any thoughts?
Thanks.
--
http://www.gyford.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-us...@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.
Problem with custom tags
My project is in folder: webinterface/
I have defined a custom "webinterface_tags.py" inside my project:
webinterface/templatetags/webinterface_tags.py
My webinterface/settings.py says:
INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'django.templatetags', # done 11 nov
)
I have included a {% load webinterface_tags %}statement in a
template/search.html file. But while running this application on
django on apache server, django is not able to find webinterface_tags
file. Response is:
'webinterface_tags' is not a valid tag library: Could not load
template library from django.templatetags.webinterface_tags, No module
named webinterface_tags
Am i missing any of the settings which I need to do for webinterface/
templatetags directory ?
I checked online, but there is not any concrete example. Kindly help!
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@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: Django 1.3 alpha 1 released
What about having an official 1.3 feedback thread at django-developers list? ;) I'm liking the pack of small improvements coming in this release, and timing is very good, well done. I must say I'm less than happy with the view classes though. Is the API on it frozen already? On 11 nov, 05:34, James Bennett wrote: > The first alpha preview package for Django 1.3 is now available. > > * Release notes:http://docs.djangoproject.com/en/dev/releases/1.3-alpha-1/ > > * Download instructions:http://www.djangoproject.com/download/ > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of correct." -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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: Django 1.3 alpha 1 released
On 12 November 2010 01:16, hcarvalhoalves wrote: > What about having an official 1.3 feedback thread at django-developers > list? ;) > > I'm liking the pack of small improvements coming in this release, and > timing is very good, well done. I must say I'm less than happy with > the view classes though. Is the API on it frozen already? IMHO no, but it reached a point where the only way to make it better was to have it released to the wild and see how people use it. I'm personally interested in all and any feedback on the class based views. There's a few thing I would like to improve myself, but just didn't have the time to sit down and do the work. > > On 11 nov, 05:34, James Bennett wrote: >> The first alpha preview package for Django 1.3 is now available. >> >> * Release notes:http://docs.djangoproject.com/en/dev/releases/1.3-alpha-1/ >> >> * Download instructions:http://www.djangoproject.com/download/ >> >> -- >> "Bureaucrat Conrad, you are technically correct -- the best kind of correct." > -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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: Django 1.3 alpha 1 released
2010/11/12 Łukasz Rekucki > On 12 November 2010 01:16, hcarvalhoalves > wrote: > > What about having an official 1.3 feedback thread at django-developers > > list? ;) > > > > I'm liking the pack of small improvements coming in this release, and > > timing is very good, well done. I must say I'm less than happy with > > the view classes though. Is the API on it frozen already? > > IMHO no, but it reached a point where the only way to make it better > was to have it released to the wild and see how people use it. I'm > personally interested in all and any feedback on the class based > views. There's a few thing I would like to improve myself, but just > didn't have the time to sit down and do the work. I'm not sure what is meant by improve and or what you would like to improve specifically but, it was my impression that this conversation had been played out and that the API was pretty much decided. -- Ian http://www.ianlewis.org/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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: Django 1.3 alpha 1 released
On Fri, Nov 12, 2010 at 8:16 AM, hcarvalhoalves wrote: > What about having an official 1.3 feedback thread at django-developers > list? ;) Why is a single catch-all thread needed? Those sorts of threads rapidly descend into an unmaintainable mess. It's better to open a new thread for any issue you want to discuss. > I'm liking the pack of small improvements coming in this release, and > timing is very good, well done. I must say I'm less than happy with > the view classes though. Is the API on it frozen already? It won't be 100% frozen until the final release, but it's certainly getting slushy. If you want to make API changes, you'd better come armed with a very good set of reasons (that doesn't rehash discussions we've already been over) and preferably a patch that implements the changes you'd like to see. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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: Django 1.3 alpha 1 released
To be fair, I only had one small pet peeve with the current views API after trying the alpha: the use of self.args / self.kwargs. There's added value on being able to see which parameters a view expects by seeing it's method signature: def publisher(request, publisher_name): publisher = get_object_or_404(Publisher, name__iexact=publisher_name) ... As opposed to (from the release notes): class PublisherBookListView(ListView): ... def get_queryset(self): publisher = get_object_or_404(Publisher, name__iexact=self.args[0]) ... Using keyword arguments help a little more, so you don't pass values around blindly based on indexes only. Still, the keyword will be lost somewhere in the middle of the method. It's a lot less clear than just checking a method signature. In 1.x, I liked the fact of having reverse() automatically fail loud when the method signature didn't matched my URL pattern. That helps to catch a lot of views-urls mismatches. Can that behaviour be replicated with the class-based API by overriding it's __init__, instead of tucking parameters away on self.args/kwargs? Or there's really a philosophy that views should just trust URL pattern matching? On 11 nov, 22:30, Łukasz Rekucki wrote: > On 12 November 2010 01:16, hcarvalhoalves wrote: > > > What about having an official 1.3 feedback thread at django-developers > > list? ;) > > > I'm liking the pack of small improvements coming in this release, and > > timing is very good, well done. I must say I'm less than happy with > > the view classes though. Is the API on it frozen already? > > IMHO no, but it reached a point where the only way to make it better > was to have it released to the wild and see how people use it. I'm > personally interested in all and any feedback on the class based > views. There's a few thing I would like to improve myself, but just > didn't have the time to sit down and do the work. > > > > > On 11 nov, 05:34, James Bennett wrote: > >> The first alpha preview package for Django 1.3 is now available. > > >> * Release notes:http://docs.djangoproject.com/en/dev/releases/1.3-alpha-1/ > > >> * Download instructions:http://www.djangoproject.com/download/ > > >> -- > >> "Bureaucrat Conrad, you are technically correct -- the best kind of > >> correct." > > -- > Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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: Django 1.3 alpha 1 released
On 12 November 2010 01:45, Ian Lewis wrote: > 2010/11/12 Łukasz Rekucki >> >> On 12 November 2010 01:16, hcarvalhoalves >> wrote: >> > What about having an official 1.3 feedback thread at django-developers >> > list? ;) >> > >> > I'm liking the pack of small improvements coming in this release, and >> > timing is very good, well done. I must say I'm less than happy with >> > the view classes though. Is the API on it frozen already? >> >> IMHO no, but it reached a point where the only way to make it better >> was to have it released to the wild and see how people use it. I'm >> personally interested in all and any feedback on the class based >> views. There's a few thing I would like to improve myself, but just >> didn't have the time to sit down and do the work. > > I'm not sure what is meant by improve and or what you would like to improve > specifically but, > it was my impression that this conversation had been played out and that the > API was pretty much decided. I agree. The base View class is pretty much set in stone for me. So in context of the class based views as a whole the API is frozen. But there are minor things in the generic views and mixins that django provides, that didn't work too well for me while experimenting. For example, the FormMixin assumes that only arguments to your form is "data" and "files". It's not uncommon for forms to require a request object or some other additional objects (or maybe my way of using forms is fundametally broken). To make a CreateView work with such a form, you need to needlessly reimplement the whole get_form() method. I think this should be easier. I don't want to propose any kind of revolution, but rather extend the API based on real use cases. And the reason I didn't post any proposals to change some things is that I don't feel very strong with my arguments and I don't want to waste people's time on things I'm not sure about myself. -- Łukasz Rekucki -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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: Django 1.3 alpha 1 released
On 11/11/2010 5:04 PM, Russell Keith-Magee wrote: > It won't be 100% frozen until the final release Shouldn't that be "first beta"? regards Steve -- DjangoCon US 2010 September 7-9 http://djangocon.us/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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: Django 1.3 alpha 1 released
On Fri, Nov 12, 2010 at 9:17 AM, Steve Holden wrote: > On 11/11/2010 5:04 PM, Russell Keith-Magee wrote: >> It won't be 100% frozen until the final release > > Shouldn't that be "first beta"? Let me clarify: The absolute hard deadline for changes to API is the final release. That's the point at which our backwards compatibility policy kicks in. However, the closer we get to the final release, the harder it will be to make an API change. The beta will be a significant point in this process -- for all practical purposes, if a change hasn't been made before the beta, it probably won't happen unless a major problem or limitation is demonstrated. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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: Django 1.3 alpha 1 released
On Fri, Nov 12, 2010 at 9:09 AM, hcarvalhoalves wrote: > To be fair, I only had one small pet peeve with the current views API > after trying the alpha: the use of self.args / self.kwargs. > > There's added value on being able to see which parameters a view > expects by seeing it's method signature: > > > def publisher(request, publisher_name): > publisher = get_object_or_404(Publisher, > name__iexact=publisher_name) > ... > > > As opposed to (from the release notes): > > > class PublisherBookListView(ListView): > ... > def get_queryset(self): > publisher = get_object_or_404(Publisher, > name__iexact=self.args[0]) > ... > > > Using keyword arguments help a little more, so you don't pass values > around blindly based on indexes only. Still, the keyword will be lost > somewhere in the middle of the method. It's a lot less clear than just > checking a method signature. Thanks for the feedback. And what is your suggestion for fixing this? > In 1.x, I liked the fact of having reverse() automatically fail loud > when the method signature didn't matched my URL pattern. That helps to > catch a lot of views-urls mismatches. Can that behaviour be replicated > with the class-based API by overriding it's __init__, instead of > tucking parameters away on self.args/kwargs? Or there's really a > philosophy that views should just trust URL pattern matching? Yes, overriding a class to provide a specific list of keyword arguments to __init__ would work, and would provide the error handling you describe. As for whether views should just trust URL patterns: We're defining generic views. Introducing generic argument handling -- **kwargs -- is part of that pattern. When you make something more generic, one of the things you lose is specific error handling. Broadly speaking, what you're proposing sounds good to me. Tighter error handling is always a good thing, and the current API hasn't made an active decision to suppress error handling -- it's just a consequence of making views generic. However, we need a specific suggestion. If you can make a specific suggestion (preferably in the form of a patch), I'm happy to entertain that suggestion. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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: Django 1.3 alpha 1 released
2010/11/12 Łukasz Rekucki : > On 12 November 2010 01:45, Ian Lewis wrote: >> 2010/11/12 Łukasz Rekucki >>> >>> On 12 November 2010 01:16, hcarvalhoalves >>> wrote: >>> > What about having an official 1.3 feedback thread at django-developers >>> > list? ;) >>> > >>> > I'm liking the pack of small improvements coming in this release, and >>> > timing is very good, well done. I must say I'm less than happy with >>> > the view classes though. Is the API on it frozen already? >>> >>> IMHO no, but it reached a point where the only way to make it better >>> was to have it released to the wild and see how people use it. I'm >>> personally interested in all and any feedback on the class based >>> views. There's a few thing I would like to improve myself, but just >>> didn't have the time to sit down and do the work. >> >> I'm not sure what is meant by improve and or what you would like to improve >> specifically but, >> it was my impression that this conversation had been played out and that the >> API was pretty much decided. > > I agree. The base View class is pretty much set in stone for me. So in > context of the class based views as a whole the API is frozen. But > there are minor things in the generic views and mixins that django > provides, that didn't work too well for me while experimenting. > > For example, the FormMixin assumes that only arguments to your form is > "data" and "files". It's not uncommon for forms to require a request > object or some other additional objects (or maybe my way of using > forms is fundametally broken). To make a CreateView work with such a > form, you need to needlessly reimplement the whole get_form() method. > I think this should be easier. If I understand your use case, something like: class MyFormMixin(object): def get_form_class(self) def form_factory(self, *args, **kwargs): return MyForm(self.request, 'frobnitz', *args, **kwargs) return form_factory should do the job. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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.
Add a create button for foreign keys(ModelForms)
I have the following models.py file: class Account(models.Model): name = models.CharField(max_length=30) user = models.ForeignKey(User, related_name='account_creator') class Category(models.Model): name = models.CharField(max_length=30) account = models.ForeignKey(Account, related_name='categories') class Transaction(models.Model): name = models.CharField(max_length=30) ... category = models.ForeignKey(Category, related_name='transactions', blank=True, null=True) account = models.ForeignKey(Account, related_name='transactions') In a view I've a modelform for the Transaction class, but the problem with it is that I can't add a category or an account from this form. I'd like to know how to add a "create button" to the view/form. The django admin does this pretty well but I can't find how to use it. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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: Problem with custom tags
I assume webinterface is your django app. If so, you'll need to add it
to INSTALLED_APPS.
On Nov 11, 2:18 pm, vivek_12315 wrote:
> My project is in folder: webinterface/
>
> I have defined a custom "webinterface_tags.py" inside my project:
>
> webinterface/templatetags/webinterface_tags.py
>
> My webinterface/settings.py says:
>
> INSTALLED_APPS = (
> 'django.contrib.auth',
> 'django.contrib.contenttypes',
> 'django.contrib.sessions',
> 'django.contrib.sites',
> 'django.templatetags', # done 11 nov
> )
>
> I have included a {% load webinterface_tags %} statement in a
> template/search.html file. But while running this application on
> django on apache server, django is not able to find webinterface_tags
> file. Response is:
>
> 'webinterface_tags' is not a valid tag library: Could not load
> template library from django.templatetags.webinterface_tags, No module
> named webinterface_tags
>
> Am i missing any of the settings which I need to do for webinterface/
> templatetags directory ?
>
> I checked online, but there is not any concrete example. Kindly help!
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@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.
error codes for validation error messages
Hi
New to django, and just loving it!
Got the basics working - had the following question.
What would be the preferred way to associate an error code with an
error message (so that say it can be given back to an api call)
class MyForm(forms.Form):
email = forms.CharField(error_messages={'invalid' : _('10001 :
Email address is invalid')})
If form validation fails I would want to send associated error code to
api client, but on the web interface the error code need not appear.
If I stick the code in the translatable string a I have done then
localization files might look ugly?
Any suggestions on how the rest of the world does it would be very
helpful :)
Thanks a bunch
Ajai
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-us...@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.
Can Admin Widgets be used in non-admin templates?
Hi all, Django newbie question here. I am building some pages to let my users manage lists of data. I really like the look, feel, and behavior, of the admin pages. But I can't give my users that much control. Is there a way to reuse the admin widgets in non-admin pages? I want to give them limited filter, find, and editing capabilities for only a few tables. Are there any examples how to do this? Thanks! -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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: Apache config. admin page displays without stylesheets
Thanks for the fix. Besides adding a directory directive, one also needs to make an alias so that http://mysite.com/media/ points to the style sheets. I added this to the same apache config as above (and now it works): AllowOverride None Options None Order allow,deny Allow from all Alias /media/ /usr/share/python-support/python-django/django/ contrib/admin/media/ -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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.
Downloading files
Hi, I am new to django . >From html page I want to download a file from a location in my local system . I am using django server and not the apache/lightpd. By the following code I am able to get the dialouge box on clicking the link on web page . But it downloads exactly 0 bytes. Please suggest what to do ? *HTML CODE* Download Core *URLS*: (r'^mts/cpd/filename$','core.srdown') *views/core.srdown : *def srdown(request, id): paths= str(request.path) response = HttpResponse(mimetype='application/force-download') response['Content-Disposition'] = 'attachment; filename=%s' % paths response['X-Sendfile'] = paths return response* *I get the box asking for downloading but on clicking it downloads file with 0 bytes. I have given the absolute path to the file '/mts/cpd/filename'. Is that correct ? -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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.
