Re: views.py filtering and excluding objects
err.. Malcolm--sorry about the typo --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: views.py filtering and excluding objects
Thanks for the reply and sorry for my vagueness; Rob: I was talking about really long lines of python. Thanks for the heads up about the all. I was just typing off the top of my head and still and figuring out python. Malcom: I suppose that is what I am asking. Is there any simple way to take group of objects like breakingnews in my example and exclude those objects from another set of objects (news) without a for statement? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: memcached setup
Could it possibly be due to the fact that your python shell has the
correct PYTHONPATH set (with the memcached python bindings) and that
your django configuration doesn't have the correct PYTHONPATH?
omat wrote:
> Hi all,
>
> I have installed memcached and python bindings on Fedora Core 4. Using
> the python shell I am able to use cache with django:
>
>
from django.conf import settings
settings.configure(CACHE_BACKEND = 'memcached://127.0.0.1:11211/')
from django.core.cache import cache
cache.set('test', 'abc')
cache.get('test')
> 'abc'
>
> But when I put CACHE_BACKEND = 'memcached://127.0.0.1:11211/' in the
> settings.py I get:
>
> InvalidCacheBackendError: Memcached cache backend requires either
> 'memcached' or 'cmemcached' libraries
>
>
> Any ideas?
>
> oMat
>
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: memcached setup
On Tue, 2007-05-29 at 06:49 +, omat wrote:
> Hi all,
>
> I have installed memcached and python bindings on Fedora Core 4. Using
> the python shell I am able to use cache with django:
>
> >>> from django.conf import settings
> >>> settings.configure(CACHE_BACKEND = 'memcached://127.0.0.1:11211/')
> >>> from django.core.cache import cache
> >>> cache.set('test', 'abc')
> >>> cache.get('test')
> 'abc'
>
> But when I put CACHE_BACKEND = 'memcached://127.0.0.1:11211/' in the
> settings.py I get:
>
> InvalidCacheBackendError: Memcached cache backend requires either
> 'memcached' or 'cmemcached' libraries
The error message is telling you what the problem is. You are missing a
necessary library.
When you see a message like this, it's time to go and read the
documentation to see what you might have missed. The requirements are
all described in the caching document. See
http://www.djangoproject.com/documentation/cache/#memcached
Regards,
Malcolm
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: views.py filtering and excluding objects
On Tue, 2007-05-29 at 05:20 +, Michael Newman wrote: > Something that has been bothering me for awhile and I finally just > decided to post it here because my code work around hits the database > way too many times. > > I am writing a custom view for an application that uses multiple > categories per story. So I want to lookup stories so that they aren't > duplicates and they don't appear in a category that is displayed > before. So > > breakingnews = > Story.objects.all.filter(category__name__exact="breakingnews") > news = Story.Objects.all.exclude(ids = breakingnews.ids) > > Now I realize that I could just exclude the filter, so: > news = Story.Objects.all.exclude(category__name__exact="breakingnews") Well, at some point you have to specify which objects to exclude. What other way could there be to do it other than giving the query specifiers? Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
memcached setup
Hi all,
I have installed memcached and python bindings on Fedora Core 4. Using
the python shell I am able to use cache with django:
>>> from django.conf import settings
>>> settings.configure(CACHE_BACKEND = 'memcached://127.0.0.1:11211/')
>>> from django.core.cache import cache
>>> cache.set('test', 'abc')
>>> cache.get('test')
'abc'
But when I put CACHE_BACKEND = 'memcached://127.0.0.1:11211/' in the
settings.py I get:
InvalidCacheBackendError: Memcached cache backend requires either
'memcached' or 'cmemcached' libraries
Any ideas?
oMat
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: views.py filtering and excluding objects
Its hard to tell what you mean by "really long once I start factoring time and uniqueness". Do you mean really large data sets or really wide lines in your python file? If the former, you will probably need to be more specific about what the long query contains. If the latter, look at chaining query sets. BTW you don't need to use "all" if have any other function (exclude, filter, count etc). so Story.objects.exclude(xxx=yyy) would be fine -rob On May 28, 10:20 pm, Michael Newman <[EMAIL PROTECTED]> wrote: > Something that has been bothering me for awhile and I finally just > decided to post it here because my code work around hits the database > way too many times. > > I am writing a custom view for an application that uses multiple > categories per story. So I want to lookup stories so that they aren't > duplicates and they don't appear in a category that is displayed > before. So > > breakingnews = > Story.objects.all.filter(category__name__exact="breakingnews") > news = Story.Objects.all.exclude(ids = breakingnews.ids) > > Now I realize that I could just exclude the filter, so: > news = Story.Objects.all.exclude(category__name__exact="breakingnews") > > but this gets really long once I start factoring time and uniqueness. > Is there an easy way to filter objs like that? > > Thanks in advance, Mn --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
views.py filtering and excluding objects
Something that has been bothering me for awhile and I finally just decided to post it here because my code work around hits the database way too many times. I am writing a custom view for an application that uses multiple categories per story. So I want to lookup stories so that they aren't duplicates and they don't appear in a category that is displayed before. So breakingnews = Story.objects.all.filter(category__name__exact="breakingnews") news = Story.Objects.all.exclude(ids = breakingnews.ids) Now I realize that I could just exclude the filter, so: news = Story.Objects.all.exclude(category__name__exact="breakingnews") but this gets really long once I start factoring time and uniqueness. Is there an easy way to filter objs like that? Thanks in advance, Mn --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: include statements for non-dynamic pages
On 29-May-07, at 8:34 AM, Russell Keith-Magee wrote: > Note that for simple cases, you may be able to use a generic view. > These are views that cover simple use cases (just render a template, > render a template for a single database object, render a template for > a list of database objects, etc). Generic views are covered in the > fourth tutorial. > > http://www.djangoproject.com/documentation/tutorial04/ he could also explore the concept of flat pages http://www.djangoproject.com/documentation/flatpages/ -- regards kg http://lawgon.livejournal.com http://nrcfosshelpline.in/web/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
phone
look it _ 使用下一代的 MSN Messenger。 http://imagine-msn.com/messenger/launch80/default.aspx?locale=zh-cn&source=wlmailtagline --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~--- <>
Re: include statements for non-dynamic pages
On 5/29/07, Vincent Nijs <[EMAIL PROTECTED]> wrote:
>
> Russell,
>
> I think I am starting to get the basic idea of 'extends' for templates.
> However, I don't get what I need to do to get my basic example (or your
> example for that matter) to generate the page I want to see in my browser.
> It doesn't just work the way php would here so I am guessing I need to add a
> 'view' or do something with 'urls.py' or both but I can't figure out what
> that would be since I am not processing anything or sending any information
> to the page.
You're correct that the process is different to PHP. The Django
process goes something like this:
1) You set up base.html as a page template for your entire site
2) You set up home.html, extending base.html, describing your home page content
3) You set up a view in views.py that renders home.html.
4) You set up an entry in urls.py that directs the URL '/home/' to the
home view.
All of the processing (calculations, database access, etc) that would
normally happen on a PHP page happens in the view. The view produces a
context that contains the result of that processing, and the template
exposes pieces of the context.
However, if you're not doing any processing, your view could be as simple as:
from django.shortcuts import render_to_response
def home_view(request):
return render_to_response('home.html')
When someone requests a URL that has been redirected to this view,
Django responds by rendering your template, and returns the resulting
HTML to be displayed in the client browser.
This process is covered in the third tutorial:
http://www.djangoproject.com/documentation/tutorial03/
Note that for simple cases, you may be able to use a generic view.
These are views that cover simple use cases (just render a template,
render a template for a single database object, render a template for
a list of database objects, etc). Generic views are covered in the
fourth tutorial.
http://www.djangoproject.com/documentation/tutorial04/
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-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: include statements for non-dynamic pages
Russell,
I think I am starting to get the basic idea of 'extends' for templates.
However, I don't get what I need to do to get my basic example (or your
example for that matter) to generate the page I want to see in my browser.
It doesn't just work the way php would here so I am guessing I need to add a
'view' or do something with 'urls.py' or both but I can't figure out what
that would be since I am not processing anything or sending any information
to the page.
Thanks,
Vincent
On 5/28/07 7:39 PM, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote:
>
> On 5/29/07, vince <[EMAIL PROTECTED]> wrote:
>>
>> What would i need to do exactly to
>> get the following to work?
>>
>> {% include("design/index_nav.html") %}
>> Welcome to the home page
>> {% include("design/footer.html") %}
>
> The following would work:
>
> {% include "design/index_nav.html" %}
> Welcome to the home page
> {% include "design/footer.html" %}
>
> But this probably isn't the best way to solve the problem. A better
> approach is to use blocks and extend.
>
> design/base.html:
> -
> {% block nav %}
> Some navigation content
> {% endblock %}
> {% block content %}
> {% endblock %}
> {% block footer %}
> Some footer content
> {% endblock %}
>
>
> design/home.html
> -
> {% extends "design/base.html" %}
> {% block content %}
> Welcome to the home page
> {% endblock %}
>
> That way, you set up a single page template (base.html), with a block
> where you want various significant pieces of content (main content,
> sidebar, etc), and then on your actual content page, you replace
> specific blocks.
>
> This way, you ensure that every page on your site is using a common
> basic template. If you need to, you can even layer ther extensions
> (e.g., base -> content -> home) to add complexity to your basic
> templates in layers.
>
> See [1] for more details on how template inheritance works.
>
> [1] http://www.djangoproject.com/documentation/templates/#template-inheritance
>
> Yours,
> Russ Magee %-)
>
> >
--
Vincent R. Nijs
Assistant Professor of Marketing
Kellogg School of Management, Northwestern University
2001 Sheridan Road, Evanston, IL 60208-2001
Phone: +1-847-491-4574 Fax: +1-847-491-2498
E-mail: [EMAIL PROTECTED]
Skype: vincentnijs
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Alternative approach to UserProfile
On 5/28/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > I thought I had the lock on the grumpy old man role in this list. I'm grumpy but not old; what prize do I get? Dang kids these days with their user profiles... -- "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-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Alternative approach to UserProfile
On Mon, 2007-05-28 at 15:00 -0700, dehora wrote: > > ZZorba wrote: > > I'm also aware of trickiness of eval() methods, > > so,, I could solve the problem in this way > > > > " > > profile_fields = "email email_backup brother sister".split() > > for key in profile_fields: > > getattr(request.user.get_profile(), key) > > " > > That's so Zope. > > > And, it works well. > > That's the problem. *This* is what you choose to be your first contribution in months? :-) I thought I had the lock on the grumpy old man role in this list. Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Unicode-branch: testers wanted
On Tue, 2007-05-29 at 00:30 +0200, Sandro Dentella wrote: > On Mon, May 28, 2007 at 04:26:17PM -0500, Jeremy Dunck wrote: > > > > On 5/28/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > > Okay... time to fix that problem then. Probably need to introduce a > > > settings for tests only for database encoding. I should have done that > > > when I first saw the problem instead of trying to dodge around it. > > Do we need such a settings or we really need to *copy* database encoding so > that tests are done exactly as the application database. (if it's possible > to use other than utf8...). That assumes there is an application database to copy and/or that is configured sensibly. It's a bit of a wart that DATABASE_NAME is required at all in the test settings file -- it's just that it's woven pretty deeply into various places in the code. For fun, somebody could look into fixing that; it would only take an hour or so for somebody with reasonable Pyhthon familiarity and not much Django internals familiarity, I would guess. Short verison: tests should be as independent and run in as uniform an environment as possible. > That would prevent people from runnnig wanderfull tests on a well configured > db when the real db is still "SQL_ASCII" just becouse template1 was shipped > that way! The test framework can't realistically insulate people against mistakes they make outside of Django. You create test databases much more often than project databases (unless you don't run your tests). So I'm -1 on trying to do anything like this. Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Unicode-branch: testers wanted
On Mon, 2007-05-28 at 16:26 -0500, Jeremy Dunck wrote: > On 5/28/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > Okay... time to fix that problem then. Probably need to introduce a > > settings for tests only for database encoding. I should have done that > > when I first saw the problem instead of trying to dodge around it. > > FWIW, as a workaround, in Mysql's my.cnf, you can set: > character_set_database = 'utf8' Yeah, I'm aware of this. It's only a workaround, as you say, though, since it makes tests dependent on configuration outside of Django. There are already some implicit assumptions like that in the tests (if you database can't hold characters that are also in the latin1 charater set, encoded suitably to the encoding of your database, tests will fail mysteriously). But don't tell anybody that. We'll keep as just our little secret. :-) > In postgres, new databases are created from the template1 system > database; new databases will have whatever encoding that database has. > (template0 is the pristine DB shipped with postgres and should never > be changed, but you should feel free to change template1 as is > useful). Agreed. Since both servers allow you to specify the encoding at creation time, I'll add support for TEST_DATABASE_CHARSET and TEST_DATABASE_COLLATION settings today (to trunk, since this isn't Unicode specific). That should make things more portable. Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: include statements for non-dynamic pages
On 5/29/07, vince <[EMAIL PROTECTED]> wrote:
>
> What would i need to do exactly to
> get the following to work?
>
> {% include("design/index_nav.html") %}
> Welcome to the home page
> {% include("design/footer.html") %}
The following would work:
{% include "design/index_nav.html" %}
Welcome to the home page
{% include "design/footer.html" %}
But this probably isn't the best way to solve the problem. A better
approach is to use blocks and extend.
design/base.html:
-
{% block nav %}
Some navigation content
{% endblock %}
{% block content %}
{% endblock %}
{% block footer %}
Some footer content
{% endblock %}
design/home.html
-
{% extends "design/base.html" %}
{% block content %}
Welcome to the home page
{% endblock %}
That way, you set up a single page template (base.html), with a block
where you want various significant pieces of content (main content,
sidebar, etc), and then on your actual content page, you replace
specific blocks.
This way, you ensure that every page on your site is using a common
basic template. If you need to, you can even layer ther extensions
(e.g., base -> content -> home) to add complexity to your basic
templates in layers.
See [1] for more details on how template inheritance works.
[1] http://www.djangoproject.com/documentation/templates/#template-inheritance
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-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: include statements for non-dynamic pages
On 29-May-07, at 5:28 AM, vince wrote:
> {% include("design/index_nav.html") %}
> Welcome to the home page
> {% include("design/footer.html") %}
make a base.html page like this:
contents of design/index_nav.html
{% block maincontent %}
{% endblock %}
contents of design/footer.html
and in your static pages:
{% extends 'base.html'%}
{% block maincontent %}
your content here
{% endblock %}
--
regards
kg
http://lawgon.livejournal.com
http://nrcfosshelpline.in/web/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Path problem with mod_python
OK, found it!
The urls.py file in subapplication had:
urlpatterns = patterns('subapplication.views', )
rather than:
urlpatterns = patterns('project.subapplication.views', ...)
Thanks if you were working on this.
Juampa
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Path problem with mod_python
Sorry about the "subapplication". I added those thinking they would highlight the "subapplication" name in the post. They are *not* in the httpd.conf file! Thanks again. Juampa --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Path problem with mod_python
Hello all: I am trying to deploy a test application with Apache 2.0.59 and mod_python 3.3.1. I am also using Django 0.97-pre (development version). The project has a single cistom application and it is listed in INSTALLED_APPS in settings.py. Also, I have a urls.py file within the subapplication and the main urls.py file imports it. Everything works fine except that whenever I try to access a URL that is parsed by the urls.py file within the subapplication, I get debug error page saying that "subapplication.views could not be imported Error was no module named subapplication.views". The section in httpd.conf has the line: PythonPath "['/path/to/project'] + sys.path" If I change it to: PythonPath "['/path/to/project', '/path/to/project/ subapplication'] + sys.path" then everything works. But I think only the path to the project should be needed. Any ideas as to what is wrong? Thanks, Juampa --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
include statements for non-dynamic pages
I am trying to learn Django to convert a site where I use php + python
cgi scripts. For consistent layout i would use php's include statement
for headers and footers on the old site. It is mentioned the Django
book that something similar exists for Django. Suppose i want to
create a home page (index.html). What would i need to do exactly to
get the following to work?
{% include("design/index_nav.html") %}
Welcome to the home page
{% include("design/footer.html") %}
If you have suggestion for better solutions with templates i'd luv to
hear them.
Thanks,
Vincent
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Unicode-branch: testers wanted
On Mon, May 28, 2007 at 04:26:17PM -0500, Jeremy Dunck wrote: > > On 5/28/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > > Okay... time to fix that problem then. Probably need to introduce a > > settings for tests only for database encoding. I should have done that > > when I first saw the problem instead of trying to dodge around it. Do we need such a settings or we really need to *copy* database encoding so that tests are done exactly as the application database. (if it's possible to use other than utf8...). That would prevent people from runnnig wanderfull tests on a well configured db when the real db is still "SQL_ASCII" just becouse template1 was shipped that way! sandro *:-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Cross validation of form fields (svn)
On May 28, 1:43 am, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Validation involving multiple fields is the responsibility of the form, > not any individual field. So do this type of checking in the clean() > method of your Form sub-class. Thanks Malcolm, works grand! L. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Alternative approach to UserProfile
ZZorba wrote: > I'm also aware of trickiness of eval() methods, > so,, I could solve the problem in this way > > " > profile_fields = "email email_backup brother sister".split() > for key in profile_fields: > getattr(request.user.get_profile(), key) > " That's so Zope. > And, it works well. That's the problem. cheers Bill --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Unicode-branch: testers wanted
On 5/28/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Okay... time to fix that problem then. Probably need to introduce a > settings for tests only for database encoding. I should have done that > when I first saw the problem instead of trying to dodge around it. FWIW, as a workaround, in Mysql's my.cnf, you can set: character_set_database = 'utf8' In postgres, new databases are created from the template1 system database; new databases will have whatever encoding that database has. (template0 is the pristine DB shipped with postgres and should never be changed, but you should feel free to change template1 as is useful). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Stagnating Djangobook? Broken Atom feed?
Hey Andrew -- The reason you haven't seen updates to the book is that we're in the process of doing the final reviews for print. It's entirely uninteresting work so we're not doing it publically. Expect to see the first of the final chapters online in the next couple of weeks; we'll be posting them as we send 'em off to Apress. Jacob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: django models
On 28-May-07, at 11:24 PM, Lic. José M. Rodriguez Bacallao wrote: > So, if I add a ForeignKey field to my model it simply add a > "related_model_id" column to my table, let me ask something, how > django enforce that when I add a repeated value to that field it > will an error, I mean, a foreign key value that does not exist in > the original table in a one to many relationship? even if django doesnt, postgres will barf - dont know about mysql or sqlite -- regards kg http://lawgon.livejournal.com http://nrcfosshelpline.in/web/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Unicode-branch: testers wanted
>> Aaah! :-(
>>
>> I've been fighting this problem a bit when testing with MySQL, too,
>> because my system creates the databases in LATIN1 if I don't tell it
>> anything special and so the test database can't hold the full unicode
>> range of characters. It creates PostgreSQL database in UTF-8 on my end,
>> though, so I've never seen it with that database.
>>
>> Okay... time to fix that problem then. Probably need to introduce a
>> settings for tests only for database encoding. I should have done that
>> when I first saw the problem instead of trying to dodge around it.
>>
>> I hate it when being lazy doesn't work. :-(
>>
>> I'll put this one on my list. Nice debugging job. Thanks.
Hello again,
I temporarily patched Django source code (django/test/utils.py, lines 96
and 107) to:
cursor.execute("CREATE DATABASE %s WITH ENCODING 'UNICODE'" %
backend.quote_name(TEST_DATABASE_NAME))
So, now I could run my tests. And here is some experience which I get
during debuging (my advices are dedicated mainly for other testers; I am
developing application in Czech language, in utf-8 encoding):
* check *all* your strings (I have a lot of strings like 'něco' or
'%s-123' % var; most of them I must to rewrite to u'něco' and u'%s-123'
% var); check them on all possible places (models, views, tests,
settings, custom tags, ...)
* if you use Client in test (django.test.client), make sure, that you
recode content with smart_unicode function. For example:
response = self.submitHelper('www.example.com')
self.failUnlessEqual(response.status_code, 200)
self.failUnless(smart_unicode(response.content).find(u'nějaký
rětězec') != -1)
* make sure, that data, which you post via client.post, are correctly
encoded. For example:
post_data = {
'item1': u"První položka",
'item2': u"Druhá položka",
'item3': u"Třetí položka"
}
response = self.client.post('/url/', post_data)
Hope this will help to somebody.
Regards
Michal
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: django models
So, if I add a ForeignKey field to my model it simply add a "related_model_id" column to my table, let me ask something, how django enforce that when I add a repeated value to that field it will an error, I mean, a foreign key value that does not exist in the original table in a one to many relationship? On 5/28/07, Marc Fargas <[EMAIL PROTECTED]> wrote: > > > Hi Jos�, > As the documentation says, the best alternative right now is to set a > ForeignKey from one of the models to the other, on which you should > place the ForeignKey really depends on every specific case, normaly it > should go to the one that "cannot live with the other" (hence, the > dependent one). > > ForeignKey simply adds a "related_model_id" column to hold the id of the > other model and both models get the appropiate attributes/methods to > find their relatives. > > Hope this helps, > Marc > > El lun, 28-05-2007 a las 11:45 -0400, Lic. Jos� M. Rodriguez Bacallao > escribi�: > > Hi every one, first of all, sorry about my english, it's not so good > > but I'm still learning. Well, I'm new to django and right now I come > > from zope (2/3) and plone. I find django very exciting but I got a > > little problem, how can I specify a Generalization/Especialization > > relation in django, I mean, the better way. Until now, I specify it by > > a OneToOne relationship but reading the documentation about models I > > saw that the semantic of this relationship will change, so, right now, > > I don't know what to do to be forward compatible, anyone can help me? > > > > -- > > Lic. Jos� M. Rodriguez Bacallao > > Informatics Science University > > Habana-Cuba. > > > > > > > -- Lic. José M. Rodriguez Bacallao Informatics Science University Habana-Cuba. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: relation-spanning lookups with generic relations?
On 5/28/07, Bram - Smartelectronix <[EMAIL PROTECTED]> wrote: > > Hi there, > > > > Say I have: > > class TaggedItem(models.Model): > """A tag on an item.""" > tag = models.SlugField() > content_type = models.ForeignKey(ContentType) > object_id = models.PositiveIntegerField() > > content_object = models.GenericForeignKey() > > class Meta: > ordering = ["tag"] > > def __str__(self): > return self.tag > > class Book(models.Model): > writer = models.ForeignKey(User) > tags = models.GenericRelation(TaggedItem) > > > How do I get all Tags for books by Dostoevsky ? :-) > > TaggedItem.objects.filter(content_type=ContentType.objects.get_for_model(Book), > content_object__writer="Dostoevsky") > > ...doesn't work... And > > TaggedItem.objects.filter(content_type=ContentType.objects.get_for_model(Book), > object_id__in=[ book.id for book in > Book.objects.filter(writer="Dostoevsky")]) > > is pretty bad. > > > Should I be looking at extra( ) or is there a smarter way to go about this? > > > - bram I've just implemented something like this in django-tagging, but it feels like a massive hack: Check out the usage_for_model method in http://django-tagging.googlecode.com/svn/trunk/models.py It starts with a basic query template which will retrieve tags and usage counts for a particular model, taking a dictionary of field lookups as an optional argument. If this is provided, some of Django's query generation internals are used to generate required JOIN and WHERE statements to restrict the tags returned to a subset of the model. If anyone reading that immediately thinks "there's a much cleaner way to do that with the DB API, yuo buffoon", I'm all ears! :) Jonathan. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: django models
Hi Jos�, As the documentation says, the best alternative right now is to set a ForeignKey from one of the models to the other, on which you should place the ForeignKey really depends on every specific case, normaly it should go to the one that "cannot live with the other" (hence, the dependent one). ForeignKey simply adds a "related_model_id" column to hold the id of the other model and both models get the appropiate attributes/methods to find their relatives. Hope this helps, Marc El lun, 28-05-2007 a las 11:45 -0400, Lic. Jos� M. Rodriguez Bacallao escribi�: > Hi every one, first of all, sorry about my english, it's not so good > but I'm still learning. Well, I'm new to django and right now I come > from zope (2/3) and plone. I find django very exciting but I got a > little problem, how can I specify a Generalization/Especialization > relation in django, I mean, the better way. Until now, I specify it by > a OneToOne relationship but reading the documentation about models I > saw that the semantic of this relationship will change, so, right now, > I don't know what to do to be forward compatible, anyone can help me? > > -- > Lic. Jos� M. Rodriguez Bacallao > Informatics Science University > Habana-Cuba. > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Unicode-branch: testers wanted
Thanks for fixing that. I also find using the smart_str() really handy, for cases where stuff getting out of python. Regards, itsnotvalid --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
django models
Hi every one, first of all, sorry about my english, it's not so good but I'm still learning. Well, I'm new to django and right now I come from zope (2/3) and plone. I find django very exciting but I got a little problem, how can I specify a Generalization/Especialization relation in django, I mean, the better way. Until now, I specify it by a OneToOne relationship but reading the documentation about models I saw that the semantic of this relationship will change, so, right now, I don't know what to do to be forward compatible, anyone can help me? -- Lic. José M. Rodriguez Bacallao Informatics Science University Habana-Cuba. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Unicode-branch: testers wanted
Am 28.05.2007 um 15:51 schrieb Malcolm Tredinnick: > I can't replicate this problem, but I can take a guess at what is > going > on. In [5377] I've checked in what is probably a fix for the problem. > Could you try it and see if it changes things for you? Looks good so far. I'll report if the error pops up again. Thank you! A. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Django / Python (student / intern) programmer wanted in Berlin / Germany
Hi, We (Music Pictures Ltd) are on the lookout for a Django / Python programmer to join our small team in Berlin, Germany. Currently this is a student / intern ( praktikant ) position. Any Linux, Postgres and Oracle would also be cool. Our current projects are: a port of our image library software (see www.propxt.com) to django and an alpha staged django / postgres based network community site. To learn something of our philosophy see www.tesobe.com. Please email jobs musicpictures com cheers, Simon. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
relation-spanning lookups with generic relations?
Hi there, Say I have: class TaggedItem(models.Model): """A tag on an item.""" tag = models.SlugField() content_type = models.ForeignKey(ContentType) object_id = models.PositiveIntegerField() content_object = models.GenericForeignKey() class Meta: ordering = ["tag"] def __str__(self): return self.tag class Book(models.Model): writer = models.ForeignKey(User) tags = models.GenericRelation(TaggedItem) How do I get all Tags for books by Dostoevsky ? :-) TaggedItem.objects.filter(content_type=ContentType.objects.get_for_model(Book), content_object__writer="Dostoevsky") ...doesn't work... And TaggedItem.objects.filter(content_type=ContentType.objects.get_for_model(Book), object_id__in=[ book.id for book in Book.objects.filter(writer="Dostoevsky")]) is pretty bad. Should I be looking at extra( ) or is there a smarter way to go about this? - bram --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Stagnating Djangobook? Broken Atom feed?
I don't know for sure, but since some features will change rather dramatically before 1.0 is released (admin-newforms for instance), I imagine they decided to put the chapters that would be affected on hold until feature freeze. Vince. On May 28, 6:48 am, AndrewK <[EMAIL PROTECTED]> wrote: > I've been learning Django for a while, but I'm new to this group, so > if there's a source of news that I'm not aware of, where this has been > covered, please accept my apologies. > > Does anybody know why the writing of the Djangobook seems to have > ground to a halt? I check it fairly frequently, and just tried to add > the atom feed to my RSS reader, only to find it's a broken link. The > javascript comment system seems to be broken now as well (Firefox > 2.0.0.3 on WinXP). > > I keep half-expecting to see a weblog post > onhttp://www.djangoproject.com/weblog/ > saying, "Oh yeah - we've been busy doing xyz, so the book's been > shelved for a while." > > Does anybody know what the status quo is on this? I'm not intending to > bad-mouth the project, which I think is great (I'm using it, after > all). I was just curious. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Unicode-branch: testers wanted
On Mon, 2007-05-28 at 11:27 +0200, Andreas Ahlenstorf wrote: > Hi, > > I'm having issues with the Unicode Branch and mod_python (the > development server ist working fine). That's what's comming from > mod_python: > > Phase: 'PythonHandler' > Handler:'django.core.handlers.modpython' > > Traceback (most recent call last): > >File "/usr/lib/python2.4/site-packages/mod_python/importer.py", > line 1537, in HandlerDispatch > default=default_handler, arg=req, silent=hlist.silent) > >File "/usr/lib/python2.4/site-packages/mod_python/importer.py", > line 1229, in _process_target > result = _execute_target(config, req, object, arg) > >File "/usr/lib/python2.4/site-packages/mod_python/importer.py", > line 1128, in _execute_target > result = object(arg) > >File "/usr/lib/python2.4/site-packages/django/core/handlers/ > modpython.py", line 177, in handler > return ModPythonHandler()(req) > >File "/usr/lib/python2.4/site-packages/django/core/handlers/ > modpython.py", line 163, in __call__ > req.headers_out[key] = value > > TypeError: table values must be strings I can't replicate this problem, but I can take a guess at what is going on. In [5377] I've checked in what is probably a fix for the problem. Could you try it and see if it changes things for you? If you still get the traceback, try modifying the source just before that last line in the exception traceback (django/core/handlers/modpython.py) and print out what "key" and "value" are. I am guessing they have a type of unicode, but they should still be ASCII characters, because you can't put anything else into HTTP headers. So if for some reason there are non-ASCII characters in there, we need to work out where they are coming from. However, I suspect [5377] is going to fix the main problem by coercing both "key" and "value" to string types. Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: newforms + testing
New update, I used ModelChoiceFields and ModelMultipleChoiceFields. Problem solved :) On May 23, 9:01 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > Hello, > > I wrote a newforms form, but I have some problems when I want to test > the class. Here's the definition: > > def _users(): > print "calling _users()" > return [(u.id, u.get_full_name()) for u > inUser.objects.filter(is_active=True)] > > class MemoForm(forms.Form): > body = forms.CharField(widget=forms.Textarea, required=True) > recipients = forms.MultipleChoiceField(choices=_users(), > required=True) > > This works fine, however when I run my tests, _users() is called at > the very beginning, so the choices in recipients come from my > production database, not from the fixtures I wrote. Does anyone know > how I could fix this? > > Thank you, > > Vincent --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Another suggestion for django-multilingual
Hello, I found another deficiency in django-multilingual. I'm sure that on many sites, including the one I'm developing now, there would be one primary language for content and translations will appear slowly after the content in the primary language is published. I want to display content in primary language if there's no translation for currently selected language. Unfortunately, there's no such a feature in django- multilingual and implementing it would require learning django ORM internals. Eugene --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Unicode-branch: testers wanted
Malcolm Tredinnick wrote: > On Mon, 2007-05-28 at 13:55 +0200, Michal wrote: > [...] >> You are right, the problem is in the database. >> >> It seems like the test database is created in SQL_ASCII encoding. I >> looked into psql terminal and found: >> >> List of databases >>Name | Owner| Encoding >> -++--- >> gr4unicode | pgsql | UNICODE >> test_gr4unicode | gr4unicode | SQL_ASCII >> >> DB gr4unicode was created by me, manually: >> >>CREATE DATABASE gr4unicode WITH ENCODING 'UNICODE'; >> >> Database test_gr4unicode was created dynamically by calling ./manage.py test > > > Aaah! :-( > > I've been fighting this problem a bit when testing with MySQL, too, > because my system creates the databases in LATIN1 if I don't tell it > anything special and so the test database can't hold the full unicode > range of characters. It creates PostgreSQL database in UTF-8 on my end, > though, so I've never seen it with that database. > > Okay... time to fix that problem then. Probably need to introduce a > settings for tests only for database encoding. I should have done that > when I first saw the problem instead of trying to dodge around it. > > I hate it when being lazy doesn't work. :-( > > I'll put this one on my list. Nice debugging job. Thanks. It was my pleasure :) Regards, Michal --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Test DB creation parameters
Michal wrote: > It seems like the test database is created in SQL_ASCII encoding. I > looked into psql terminal and found: > > List of databases >Name | Owner| Encoding > -++--- > gr4unicode | pgsql | UNICODE > test_gr4unicode | gr4unicode | SQL_ASCII > > DB gr4unicode was created by me, manually: > >CREATE DATABASE gr4unicode WITH ENCODING 'UNICODE'; > > Database test_gr4unicode was created dynamically by calling ./manage.py test Ah! Yes I've stepped on this one too (wrong collation in my case). I don't know if it could be worked around currently... Looks like we need a way to specify db creation parameters. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Unicode-branch: testers wanted
On Mon, 2007-05-28 at 13:55 +0200, Michal wrote: [...] > > You are right, the problem is in the database. > > It seems like the test database is created in SQL_ASCII encoding. I > looked into psql terminal and found: > > List of databases >Name | Owner| Encoding > -++--- > gr4unicode | pgsql | UNICODE > test_gr4unicode | gr4unicode | SQL_ASCII > > DB gr4unicode was created by me, manually: > >CREATE DATABASE gr4unicode WITH ENCODING 'UNICODE'; > > Database test_gr4unicode was created dynamically by calling ./manage.py test Aaah! :-( I've been fighting this problem a bit when testing with MySQL, too, because my system creates the databases in LATIN1 if I don't tell it anything special and so the test database can't hold the full unicode range of characters. It creates PostgreSQL database in UTF-8 on my end, though, so I've never seen it with that database. Okay... time to fix that problem then. Probably need to introduce a settings for tests only for database encoding. I should have done that when I first saw the problem instead of trying to dodge around it. I hate it when being lazy doesn't work. :-( I'll put this one on my list. Nice debugging job. Thanks. Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Unicode-branch: testers wanted
On Sun, 2007-05-27 at 13:34 -0700, itsnotvalid wrote:
> I got an error when I am using admin interface to submit some forms as
> following the Django book (CH6).
>
> When the form in admin interface saving.
[... snip...]
>
> UnicodeDecodeError at /admin/books/author/add/
> 'ascii' codec can't decode byte 0xe4 in position 0: ordinal not in
> range(128)
>
> Not sure if that is only my n00b skillz kicking on, it should be a
> direct result of the return string as here:
>
> from django.db import models
> # ...
> class Author(models.Model):
> salutation = models.CharField(maxlength=10)
> first_name = models.CharField(maxlength=30)
> last_name = models.CharField(maxlength=40)
> email = models.EmailField()
> headshot = models.ImageField(upload_to= ('/tmp'))
> class Admin:
> pass
>
> def __unicode__(self):
> return self.first_name # this string is what I am talking
> about
That was a little bit of a tricky example. The problem only occurs when
a file upload field is included in the form, which is why I'd never seen
it before.
Should be fixed in [5373].
Regards,
Malcolm
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Unicode-branch: testers wanted
Malcolm Tredinnick wrote:
> On Mon, 2007-05-28 at 13:16 +0200, Michal wrote:
>> Malcolm Tredinnick wrote:
>>> On Mon, 2007-05-28 at 12:59 +0200, Michal wrote:
>>> [...]
My note was in relation with latest error (ie. I have problem with
execution of tests due to verbose_name error).
I am just after dinner too, so I will try to find what is wrong in my
application... :)
Once again, sorry for my obscure latest report and english.
>>> No worries. :-)
>>>
>>> I think I've fixed this problem (non-ASCII bytestrings for verbose_name)
>>> in [5372], which I've just committed.
>> I am just rewrite all my string like:
>>
>>verbose_name='něco'
>>fields = (
>> (None, {'fields': ('title', 'slug', 'annotation', 'content',)}),
>> ('Hiearchie', {'fields': ('parent', 'order')}),
>> ('Pokročilé nastavení', {'fields': ('short_title','template_name',
>> 'person', 'info_box', 'show_menu')}),
>> ('Omezení přístupu na stránku', {'fields':
>> ('registration_required', 'groups')}),
>>)
>>order = models.IntegerField("Pořadí", help_text="Pořadí stránky v
>> rámci sourozenců, tj. stránek které mají stejného rodiče.")
>>
>> to:
>>
>>verbose_name=u'něco'
>>fields = (
>> (None, {'fields': ('title', 'slug', 'annotation', 'content',)}),
>> (u'Hiearchie', {'fields': ('parent', 'order')}),
>> (u'Pokročilé nastavení', {'fields': ('short_title','template_name',
>> 'person', 'info_box', 'show_menu')}),
>> (u'Omezení přístupu na stránku', {'fields':
>> ('registration_required', 'groups')}),
>> )
>>order = models.IntegerField(u"Pořadí", help_text=u"Pořadí stránky v
>> rámci sourozenců, tj. stránek které mají stejného rodiče.")
>>
>>
>> I am also update my unicode branch to revision [5372] and now I get
>> another error messages:
>>
>>
>> [EMAIL PROTECTED] app $./manage.py test
>> Creating test database...
>> Creating test database...
>> Creating table auth_message
>> Creating table auth_group
>> Creating table auth_user
>> Creating table auth_permission
>> Creating table django_content_type
>> Creating table django_session
>> Creating table django_site
>> Creating table django_admin_log
>> Creating table staticpages_staticpage
>> Creating table news_subscriber
>> Creating table news_new
>> Creating table news_tag
>> Creating table partners_partneruser
>> Creating table parameters_parameter
>> Creating table pressreleases_pressrelease
>> Traceback (most recent call last):
>>File "./manage.py", line 11, in ?
>> execute_manager(settings)
>>File
>> "/usr/local/lib/python2.4/site-packages/django/core/management.py", line
>> 1678, in execute_manager
>> execute_from_command_line(action_mapping, argv)
>>File
>> "/usr/local/lib/python2.4/site-packages/django/core/management.py", line
>> 1592, in execute_from_command_line
>> action_mapping[action](args[1:], int(options.verbosity))
>>File
>> "/usr/local/lib/python2.4/site-packages/django/core/management.py", line
>> 1309, in test
>> failures = test_runner(app_list, verbosity)
>>File "/usr/local/lib/python2.4/site-packages/django/test/simple.py",
>> line 84, in run_tests
>> create_test_db(verbosity)
>>File "/usr/local/lib/python2.4/site-packages/django/test/utils.py",
>> line 118, in create_test_db
>> management.syncdb(verbosity, interactive=False)
>>File
>> "/usr/local/lib/python2.4/site-packages/django/core/management.py", line
>> 537, in syncdb
>> _emit_post_sync_signal(created_models, verbosity, interactive)
>>File
>> "/usr/local/lib/python2.4/site-packages/django/core/management.py", line
>> 464, in _emit_post_sync_signal
>> verbosity=verbosity, interactive=interactive)
>>File
>> "/usr/local/lib/python2.4/site-packages/django/dispatch/dispatcher.py",
>> line 358, in send
>> sender=sender,
>>File
>> "/usr/local/lib/python2.4/site-packages/django/dispatch/robustapply.py",
>> line 47, in robustApply
>> return receiver(*arguments, **named)
>>File
>> "/usr/local/lib/python2.4/site-packages/django/contrib/auth/management.py",
>> line 26, in create_permissions
>> ctype = ContentType.objects.get_for_model(klass)
>>File
>> "/usr/local/lib/python2.4/site-packages/django/contrib/contenttypes/models.py",
>>
>> line 20, in get_for_model
>> model=key[1], defaults={'name': smart_unicode(opts.verbose_name_raw)})
>>File
>> "/usr/local/lib/python2.4/site-packages/django/db/models/manager.py",
>> line 76, in get_or_create
>> return self.get_query_set().get_or_create(**kwargs)
>>File
>> "/usr/local/lib/python2.4/site-packages/django/db/models/query.py", line
>> 280, in get_or_create
>> obj.save()
>>File
>> "/usr/local/lib/python2.4/site-packages/django/db/models/base.py", line
>> 246, in save
>> ','.join(placeholders)), db_values)
>>File
>> "/usr/local/lib/python2.4/site-packages/django/db/backends/postgresql/base.py",
>>
>> line 54, in execu
Large forms with unknown number of fileds
Hi!
I need an order form that will handle the orders for X number of
students and Y number of products. I have a working solution that
creates a .. for every product and submits it on
onchange, but I was wondering if there was more of a "django" way to
do this.
I would like my form to look like this:
--
Student name| Product 1: | Product 2: | sum:
price*quantity etc
Student name| Product 1: | Product 2: | sum:
price*quantity etc
Student name| Product 1: | Product 2: | sum:
price*quantity etc
Student name| Product 1: | Product 2: | sum:
price*quantity etc
Student name| Product 1: | Product 2: | sum:
price*quantity etc
| total q of this product | total q of this
product | sum:
total price
--
The school administrator need to add/remove products and hey should
be able to tab through the form(not hitting any save button for every
field.)
My models:
class Student(models.Model):
first_name = models.CharField(maxlength=30)
last_name = models.CharField(maxlength=30)
class Product(models.Model):
name = models.CharField(maxlength=20)
description = models.TextField()
price = models.DecimalField(max_digits=5, decimal_places=2)
class Order(models.Model):
student = models.ForeignKey(Student)
product = models.ForeignKey(Product)
quantity = models.IntegerField()
My template code:
{% for student in students %}
{{ student.first_name }} {{ student.last_name }}
{% for product in products %}
{{ product.name }}
{% endfor %}
{% endfor %}
order-quantity is a custom template tag with this logic: orders =
student.order_set.filter(product=product) and then returns the
quantity from the first order object.
Any help would be greatly appreciated!
--
Knut Ivar Nesheim
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
Re: Unicode-branch: testers wanted
On Mon, 2007-05-28 at 13:16 +0200, Michal wrote:
> Malcolm Tredinnick wrote:
> > On Mon, 2007-05-28 at 12:59 +0200, Michal wrote:
> > [...]
> >> My note was in relation with latest error (ie. I have problem with
> >> execution of tests due to verbose_name error).
> >>
> >> I am just after dinner too, so I will try to find what is wrong in my
> >> application... :)
> >>
> >>
> >> Once again, sorry for my obscure latest report and english.
> >
> > No worries. :-)
> >
> > I think I've fixed this problem (non-ASCII bytestrings for verbose_name)
> > in [5372], which I've just committed.
>
> I am just rewrite all my string like:
>
>verbose_name='něco'
>fields = (
> (None, {'fields': ('title', 'slug', 'annotation', 'content',)}),
> ('Hiearchie', {'fields': ('parent', 'order')}),
> ('Pokročilé nastavení', {'fields': ('short_title','template_name',
> 'person', 'info_box', 'show_menu')}),
> ('Omezení přístupu na stránku', {'fields':
> ('registration_required', 'groups')}),
>)
>order = models.IntegerField("Pořadí", help_text="Pořadí stránky v
> rámci sourozenců, tj. stránek které mají stejného rodiče.")
>
> to:
>
>verbose_name=u'něco'
>fields = (
> (None, {'fields': ('title', 'slug', 'annotation', 'content',)}),
> (u'Hiearchie', {'fields': ('parent', 'order')}),
> (u'Pokročilé nastavení', {'fields': ('short_title','template_name',
> 'person', 'info_box', 'show_menu')}),
> (u'Omezení přístupu na stránku', {'fields':
> ('registration_required', 'groups')}),
> )
>order = models.IntegerField(u"Pořadí", help_text=u"Pořadí stránky v
> rámci sourozenců, tj. stránek které mají stejného rodiče.")
>
>
> I am also update my unicode branch to revision [5372] and now I get
> another error messages:
>
>
> [EMAIL PROTECTED] app $./manage.py test
> Creating test database...
> Creating test database...
> Creating table auth_message
> Creating table auth_group
> Creating table auth_user
> Creating table auth_permission
> Creating table django_content_type
> Creating table django_session
> Creating table django_site
> Creating table django_admin_log
> Creating table staticpages_staticpage
> Creating table news_subscriber
> Creating table news_new
> Creating table news_tag
> Creating table partners_partneruser
> Creating table parameters_parameter
> Creating table pressreleases_pressrelease
> Traceback (most recent call last):
>File "./manage.py", line 11, in ?
> execute_manager(settings)
>File
> "/usr/local/lib/python2.4/site-packages/django/core/management.py", line
> 1678, in execute_manager
> execute_from_command_line(action_mapping, argv)
>File
> "/usr/local/lib/python2.4/site-packages/django/core/management.py", line
> 1592, in execute_from_command_line
> action_mapping[action](args[1:], int(options.verbosity))
>File
> "/usr/local/lib/python2.4/site-packages/django/core/management.py", line
> 1309, in test
> failures = test_runner(app_list, verbosity)
>File "/usr/local/lib/python2.4/site-packages/django/test/simple.py",
> line 84, in run_tests
> create_test_db(verbosity)
>File "/usr/local/lib/python2.4/site-packages/django/test/utils.py",
> line 118, in create_test_db
> management.syncdb(verbosity, interactive=False)
>File
> "/usr/local/lib/python2.4/site-packages/django/core/management.py", line
> 537, in syncdb
> _emit_post_sync_signal(created_models, verbosity, interactive)
>File
> "/usr/local/lib/python2.4/site-packages/django/core/management.py", line
> 464, in _emit_post_sync_signal
> verbosity=verbosity, interactive=interactive)
>File
> "/usr/local/lib/python2.4/site-packages/django/dispatch/dispatcher.py",
> line 358, in send
> sender=sender,
>File
> "/usr/local/lib/python2.4/site-packages/django/dispatch/robustapply.py",
> line 47, in robustApply
> return receiver(*arguments, **named)
>File
> "/usr/local/lib/python2.4/site-packages/django/contrib/auth/management.py",
> line 26, in create_permissions
> ctype = ContentType.objects.get_for_model(klass)
>File
> "/usr/local/lib/python2.4/site-packages/django/contrib/contenttypes/models.py",
>
> line 20, in get_for_model
> model=key[1], defaults={'name': smart_unicode(opts.verbose_name_raw)})
>File
> "/usr/local/lib/python2.4/site-packages/django/db/models/manager.py",
> line 76, in get_or_create
> return self.get_query_set().get_or_create(**kwargs)
>File
> "/usr/local/lib/python2.4/site-packages/django/db/models/query.py", line
> 280, in get_or_create
> obj.save()
>File
> "/usr/local/lib/python2.4/site-packages/django/db/models/base.py", line
> 246, in save
> ','.join(placeholders)), db_values)
>File
> "/usr/local/lib/python2.4/site-packages/django/db/backends/postgresql/base.py",
>
> line 54, in execute
> return self.cursor.execute(smart_str(sql, self.charset),
> self.format_params(params))
>File
> "/usr/local/li
Re: Unicode-branch: testers wanted
Malcolm Tredinnick wrote:
> On Mon, 2007-05-28 at 12:59 +0200, Michal wrote:
> [...]
>> My note was in relation with latest error (ie. I have problem with
>> execution of tests due to verbose_name error).
>>
>> I am just after dinner too, so I will try to find what is wrong in my
>> application... :)
>>
>>
>> Once again, sorry for my obscure latest report and english.
>
> No worries. :-)
>
> I think I've fixed this problem (non-ASCII bytestrings for verbose_name)
> in [5372], which I've just committed.
I am just rewrite all my string like:
verbose_name='něco'
fields = (
(None, {'fields': ('title', 'slug', 'annotation', 'content',)}),
('Hiearchie', {'fields': ('parent', 'order')}),
('Pokročilé nastavení', {'fields': ('short_title','template_name',
'person', 'info_box', 'show_menu')}),
('Omezení přístupu na stránku', {'fields':
('registration_required', 'groups')}),
)
order = models.IntegerField("Pořadí", help_text="Pořadí stránky v
rámci sourozenců, tj. stránek které mají stejného rodiče.")
to:
verbose_name=u'něco'
fields = (
(None, {'fields': ('title', 'slug', 'annotation', 'content',)}),
(u'Hiearchie', {'fields': ('parent', 'order')}),
(u'Pokročilé nastavení', {'fields': ('short_title','template_name',
'person', 'info_box', 'show_menu')}),
(u'Omezení přístupu na stránku', {'fields':
('registration_required', 'groups')}),
)
order = models.IntegerField(u"Pořadí", help_text=u"Pořadí stránky v
rámci sourozenců, tj. stránek které mají stejného rodiče.")
I am also update my unicode branch to revision [5372] and now I get
another error messages:
[EMAIL PROTECTED] app $./manage.py test
Creating test database...
Creating test database...
Creating table auth_message
Creating table auth_group
Creating table auth_user
Creating table auth_permission
Creating table django_content_type
Creating table django_session
Creating table django_site
Creating table django_admin_log
Creating table staticpages_staticpage
Creating table news_subscriber
Creating table news_new
Creating table news_tag
Creating table partners_partneruser
Creating table parameters_parameter
Creating table pressreleases_pressrelease
Traceback (most recent call last):
File "./manage.py", line 11, in ?
execute_manager(settings)
File
"/usr/local/lib/python2.4/site-packages/django/core/management.py", line
1678, in execute_manager
execute_from_command_line(action_mapping, argv)
File
"/usr/local/lib/python2.4/site-packages/django/core/management.py", line
1592, in execute_from_command_line
action_mapping[action](args[1:], int(options.verbosity))
File
"/usr/local/lib/python2.4/site-packages/django/core/management.py", line
1309, in test
failures = test_runner(app_list, verbosity)
File "/usr/local/lib/python2.4/site-packages/django/test/simple.py",
line 84, in run_tests
create_test_db(verbosity)
File "/usr/local/lib/python2.4/site-packages/django/test/utils.py",
line 118, in create_test_db
management.syncdb(verbosity, interactive=False)
File
"/usr/local/lib/python2.4/site-packages/django/core/management.py", line
537, in syncdb
_emit_post_sync_signal(created_models, verbosity, interactive)
File
"/usr/local/lib/python2.4/site-packages/django/core/management.py", line
464, in _emit_post_sync_signal
verbosity=verbosity, interactive=interactive)
File
"/usr/local/lib/python2.4/site-packages/django/dispatch/dispatcher.py",
line 358, in send
sender=sender,
File
"/usr/local/lib/python2.4/site-packages/django/dispatch/robustapply.py",
line 47, in robustApply
return receiver(*arguments, **named)
File
"/usr/local/lib/python2.4/site-packages/django/contrib/auth/management.py",
line 26, in create_permissions
ctype = ContentType.objects.get_for_model(klass)
File
"/usr/local/lib/python2.4/site-packages/django/contrib/contenttypes/models.py",
line 20, in get_for_model
model=key[1], defaults={'name': smart_unicode(opts.verbose_name_raw)})
File
"/usr/local/lib/python2.4/site-packages/django/db/models/manager.py",
line 76, in get_or_create
return self.get_query_set().get_or_create(**kwargs)
File
"/usr/local/lib/python2.4/site-packages/django/db/models/query.py", line
280, in get_or_create
obj.save()
File
"/usr/local/lib/python2.4/site-packages/django/db/models/base.py", line
246, in save
','.join(placeholders)), db_values)
File
"/usr/local/lib/python2.4/site-packages/django/db/backends/postgresql/base.py",
line 54, in execute
return self.cursor.execute(smart_str(sql, self.charset),
self.format_params(params))
File
"/usr/local/lib/python2.4/site-packages/django/db/backends/postgresql/base.py",
line 51, in format_params
return tuple([smart_str(p, self.charset, True) for p in params])
File
"/usr/local/lib/python2.4/site-packages/django/utils/encoding.py", line
55, in smart_str
return s.encode(encoding, errors)
UnicodeEncodeError
Re: Unicode-branch: testers wanted
On Mon, 2007-05-28 at 12:59 +0200, Michal wrote: [...] > > My note was in relation with latest error (ie. I have problem with > execution of tests due to verbose_name error). > > I am just after dinner too, so I will try to find what is wrong in my > application... :) > > > Once again, sorry for my obscure latest report and english. No worries. :-) I think I've fixed this problem (non-ASCII bytestrings for verbose_name) in [5372], which I've just committed. Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Unicode-branch: testers wanted
Malcolm Tredinnick wrote: > On Mon, 2007-05-28 at 11:27 +0200, Michal wrote: >> Malcolm Tredinnick wrote: >>> On Mon, 2007-05-28 at 02:09 -0700, itsnotvalid wrote: Michal, your error looks nearly identical to the one I encounter with admin interface. Except the byte offending is not the same. I guess there is something between the model class and database adapters which adds those strange bytes. >>> No, there's nothing like that. These are just standard ASCII decoding >>> errors that Python reports. A byte starting with 'C' in the high nibble >>> (e.g. Michal's 0xc3) is the start of a two-byte UTF-8 sequence, >>> something like your 0xe4 is the first byte of three byte UTF-8 sequence >>> (or possibly some non-UTF-8 bytes altogether, in both cases). >> Hmm... Sorry, but I could't locate this problem (before my last update >> to revivision 5371) > > When you say "this problem", which problem do you mean? The one you > reported in your first email? Because in the email fragment you quoted > from me, there is no "problem" reported. > > I'm very happy to help fix these errors people are seeing; they are all > small things and easy to nail with a good explanation, but you have to > help me help you: what is failing? Remember that there are about four > different sub-threads going on under this topic, so giving replying to > the right email so that the right replies thread together is going to be > useful, too. > > If this is the problem you reported in your first email, the simplest > thing you can do to help is work out which model's verbose name is > causing problems. From reading your email, I suspect you have a UTF-8 > string being used as a verbose_name somewhere (which is perfectly fine) > and it uses some codepoints outside the ASCII range. I've just finished > eating dinner and am about to try and test that theory, because my gut > feeling is that will cause a traceback, just from reading the code. > > Assuming it's what I think it is, this will be fixed in about 30 > minutes. Sorry for confusions Malcolm. My note was in relation with latest error (ie. I have problem with execution of tests due to verbose_name error). I am just after dinner too, so I will try to find what is wrong in my application... :) Once again, sorry for my obscure latest report and english. Michal --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Stagnating Djangobook? Broken Atom feed?
I've been learning Django for a while, but I'm new to this group, so if there's a source of news that I'm not aware of, where this has been covered, please accept my apologies. Does anybody know why the writing of the Djangobook seems to have ground to a halt? I check it fairly frequently, and just tried to add the atom feed to my RSS reader, only to find it's a broken link. The javascript comment system seems to be broken now as well (Firefox 2.0.0.3 on WinXP). I keep half-expecting to see a weblog post on http://www.djangoproject.com/weblog/ saying, "Oh yeah - we've been busy doing xyz, so the book's been shelved for a while." Does anybody know what the status quo is on this? I'm not intending to bad-mouth the project, which I think is great (I'm using it, after all). I was just curious. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Unicode-branch: testers wanted
On Mon, 2007-05-28 at 11:27 +0200, Andreas Ahlenstorf wrote: > Hi, > > I'm having issues with the Unicode Branch and mod_python (the > development server ist working fine). That's what's comming from > mod_python: > > Phase: 'PythonHandler' > Handler:'django.core.handlers.modpython' > > Traceback (most recent call last): > >File "/usr/lib/python2.4/site-packages/mod_python/importer.py", > line 1537, in HandlerDispatch > default=default_handler, arg=req, silent=hlist.silent) > >File "/usr/lib/python2.4/site-packages/mod_python/importer.py", > line 1229, in _process_target > result = _execute_target(config, req, object, arg) > >File "/usr/lib/python2.4/site-packages/mod_python/importer.py", > line 1128, in _execute_target > result = object(arg) > >File "/usr/lib/python2.4/site-packages/django/core/handlers/ > modpython.py", line 177, in handler > return ModPythonHandler()(req) > >File "/usr/lib/python2.4/site-packages/django/core/handlers/ > modpython.py", line 163, in __call__ > req.headers_out[key] = value > > TypeError: table values must be strings > > The checkout of the Unicode Branch is from yesterday evening (cannot > remember the revision number) and I'm using Apache 2.0.59, Python > 2.4, MySQL-python-1.2.2 and MySQL 5.0.38. Is this a bug or am I doing > something wrong? Unfortunately, I wasn't able to figure it out. Aah.. I didn't think to check that (that's why other people are helping with the tests .. thanks). That's easy enough to fix. Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Unicode-branch: testers wanted
On Mon, 2007-05-28 at 11:27 +0200, Michal wrote: > Malcolm Tredinnick wrote: > > On Mon, 2007-05-28 at 02:09 -0700, itsnotvalid wrote: > >> Michal, your error looks nearly identical to the one I encounter with > >> admin interface. Except the byte offending is not the same. > >> > >> I guess there is something between the model class and database > >> adapters which adds those strange bytes. > > > > No, there's nothing like that. These are just standard ASCII decoding > > errors that Python reports. A byte starting with 'C' in the high nibble > > (e.g. Michal's 0xc3) is the start of a two-byte UTF-8 sequence, > > something like your 0xe4 is the first byte of three byte UTF-8 sequence > > (or possibly some non-UTF-8 bytes altogether, in both cases). > > Hmm... Sorry, but I could't locate this problem (before my last update > to revivision 5371) When you say "this problem", which problem do you mean? The one you reported in your first email? Because in the email fragment you quoted from me, there is no "problem" reported. I'm very happy to help fix these errors people are seeing; they are all small things and easy to nail with a good explanation, but you have to help me help you: what is failing? Remember that there are about four different sub-threads going on under this topic, so giving replying to the right email so that the right replies thread together is going to be useful, too. If this is the problem you reported in your first email, the simplest thing you can do to help is work out which model's verbose name is causing problems. From reading your email, I suspect you have a UTF-8 string being used as a verbose_name somewhere (which is perfectly fine) and it uses some codepoints outside the ASCII range. I've just finished eating dinner and am about to try and test that theory, because my gut feeling is that will cause a traceback, just from reading the code. Assuming it's what I think it is, this will be fixed in about 30 minutes. Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: [bug]URLField 200 max_length is not enough.
Thanks for tell me this, I know now, I'm not familiar with open source project process. On 5/28/07, James Bennett <[EMAIL PROTECTED]> wrote: > > > On 5/28/07, flyaflya <[EMAIL PROTECTED]> wrote: > > I have a url, its length is 201. > > I'm not trying to be mean here, but... > > 1. We have a public bug-tracking system for bug reports: > http://code.djangoproject.com/timeline > 2. Please search the bug-tracking system before reporting an issue; > odds are it's been reported before and someone is working on it or has > posted a patch. > 3. A bug was opened for this, a patch was submitted, and a new > "maxlength" argument for URLField was added five months ago: > http://code.djangoproject.com/ticket/1477 > > (and yes, I'm aware that documentation of that change is lacking, but > when reporting a bug it's important to take advantage of the Trac > install to see if something's already been reported or fixed; > duplicate reports take valuable time away from improving Django...) > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of > correct." > > > > -- http://www.flyaflya.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Unicode-branch: testers wanted
Malcolm Tredinnick wrote: > On Mon, 2007-05-28 at 02:09 -0700, itsnotvalid wrote: >> Michal, your error looks nearly identical to the one I encounter with >> admin interface. Except the byte offending is not the same. >> >> I guess there is something between the model class and database >> adapters which adds those strange bytes. > > No, there's nothing like that. These are just standard ASCII decoding > errors that Python reports. A byte starting with 'C' in the high nibble > (e.g. Michal's 0xc3) is the start of a two-byte UTF-8 sequence, > something like your 0xe4 is the first byte of three byte UTF-8 sequence > (or possibly some non-UTF-8 bytes altogether, in both cases). Hmm... Sorry, but I could't locate this problem (before my last update to revivision 5371) tests fails too, but not so early (they fails when fixtures was loadaded to DB). So, I think that there is some problem in Django Unicode branch. I have plan to: 1) update unicode branch to latest revision 2) run separate all of my tests 3) locate unicode problems But now (after update), I couldn't run any of the test. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Unicode-branch: testers wanted
Hi, I'm having issues with the Unicode Branch and mod_python (the development server ist working fine). That's what's comming from mod_python: Phase: 'PythonHandler' Handler:'django.core.handlers.modpython' Traceback (most recent call last): File "/usr/lib/python2.4/site-packages/mod_python/importer.py", line 1537, in HandlerDispatch default=default_handler, arg=req, silent=hlist.silent) File "/usr/lib/python2.4/site-packages/mod_python/importer.py", line 1229, in _process_target result = _execute_target(config, req, object, arg) File "/usr/lib/python2.4/site-packages/mod_python/importer.py", line 1128, in _execute_target result = object(arg) File "/usr/lib/python2.4/site-packages/django/core/handlers/ modpython.py", line 177, in handler return ModPythonHandler()(req) File "/usr/lib/python2.4/site-packages/django/core/handlers/ modpython.py", line 163, in __call__ req.headers_out[key] = value TypeError: table values must be strings The checkout of the Unicode Branch is from yesterday evening (cannot remember the revision number) and I'm using Apache 2.0.59, Python 2.4, MySQL-python-1.2.2 and MySQL 5.0.38. Is this a bug or am I doing something wrong? Unfortunately, I wasn't able to figure it out. Regards, A. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Unicode-branch: testers wanted
On Mon, 2007-05-28 at 02:09 -0700, itsnotvalid wrote: > Michal, your error looks nearly identical to the one I encounter with > admin interface. Except the byte offending is not the same. > > I guess there is something between the model class and database > adapters which adds those strange bytes. No, there's nothing like that. These are just standard ASCII decoding errors that Python reports. A byte starting with 'C' in the high nibble (e.g. Michal's 0xc3) is the start of a two-byte UTF-8 sequence, something like your 0xe4 is the first byte of three byte UTF-8 sequence (or possibly some non-UTF-8 bytes altogether, in both cases). Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Unicode-branch: testers wanted
Michal, your error looks nearly identical to the one I encounter with admin interface. Except the byte offending is not the same. I guess there is something between the model class and database adapters which adds those strange bytes. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: [bug]URLField 200 max_length is not enough.
On 5/28/07, flyaflya <[EMAIL PROTECTED]> wrote: > I have a url, its length is 201. I'm not trying to be mean here, but... 1. We have a public bug-tracking system for bug reports: http://code.djangoproject.com/timeline 2. Please search the bug-tracking system before reporting an issue; odds are it's been reported before and someone is working on it or has posted a patch. 3. A bug was opened for this, a patch was submitted, and a new "maxlength" argument for URLField was added five months ago: http://code.djangoproject.com/ticket/1477 (and yes, I'm aware that documentation of that change is lacking, but when reporting a bug it's important to take advantage of the Trac install to see if something's already been reported or fixed; duplicate reports take valuable time away from improving Django...) -- "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-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
[bug]URLField 200 max_length is not enough.
I have a url, its length is 201. -- http://www.flyaflya.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Unicode-branch: testers wanted
Hello Malcolm,
I try to make tests on my application, but after update of unicode
branch (now I am synced to revision 5371), I am unable to do it due to
some errors:
[EMAIL PROTECTED] app $./manage.py test staticpages
Creating test database...
Creating table auth_message
Creating table auth_group
Creating table auth_user
Creating table auth_permission
Creating table django_content_type
Creating table django_session
Creating table django_site
Creating table django_admin_log
Creating table staticpages_staticpage
Creating table news_subscriber
Creating table news_new
Creating table news_tag
Creating table partners_partneruser
Creating table parameters_parameter
Creating table pressreleases_pressrelease
Traceback (most recent call last):
File "./manage.py", line 11, in ?
execute_manager(settings)
File
"/usr/local/lib/python2.4/site-packages/django/core/management.py", line
1678, in execute_manager
execute_from_command_line(action_mapping, argv)
File
"/usr/local/lib/python2.4/site-packages/django/core/management.py", line
1592, in execute_from_command_line
action_mapping[action](args[1:], int(options.verbosity))
File
"/usr/local/lib/python2.4/site-packages/django/core/management.py", line
1309, in test
failures = test_runner(app_list, verbosity)
File "/usr/local/lib/python2.4/site-packages/django/test/simple.py",
line 84, in run_tests
create_test_db(verbosity)
File "/usr/local/lib/python2.4/site-packages/django/test/utils.py",
line 118, in create_test_db
management.syncdb(verbosity, interactive=False)
File
"/usr/local/lib/python2.4/site-packages/django/core/management.py", line
537, in syncdb
_emit_post_sync_signal(created_models, verbosity, interactive)
File
"/usr/local/lib/python2.4/site-packages/django/core/management.py", line
464, in _emit_post_sync_signal
verbosity=verbosity, interactive=interactive)
File
"/usr/local/lib/python2.4/site-packages/django/dispatch/dispatcher.py",
line 358, in send
sender=sender,
File
"/usr/local/lib/python2.4/site-packages/django/dispatch/robustapply.py",
line 47, in robustApply
return receiver(*arguments, **named)
File
"/usr/local/lib/python2.4/site-packages/django/contrib/auth/management.py",
line 26, in create_permissions
ctype = ContentType.objects.get_for_model(klass)
File
"/usr/local/lib/python2.4/site-packages/django/contrib/contenttypes/models.py",
line 20, in get_for_model
model=key[1], defaults={'name': smart_unicode(opts.verbose_name_raw)})
File
"/usr/local/lib/python2.4/site-packages/django/db/models/options.py",
line 105, in verbose_name_raw
raw = unicode(self.verbose_name)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 7:
ordinal not in range(128)
Regards
Michal
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
ordered many-to-many relationship
I'm putting together an on-line bibliography system, and I'd like to
be able to associate with each item (book, article...) a list of
authors in the order in which they were listed in the original
publication. I'm guessing the best way to do this is with a many-to-
many relationship via an intermediary table, like so:
---
class Item(models.Model):
...
authors = models.ManyToManyField('Author', related_name='editors',
blank=True, filter_interface=True)
...
class Author(models.Model):
person = models.ForeignKey('Person')
order = models.IntegerField()
class Person(models.Model):
first_name = models.CharField(maxlength=100)
..
---
What's got me confused is how to set all of this up in the admin
interface. I'd like to be able to easily add new People when adding a
new Item. Any suggestions?
Thanks very much for your help!
Drew
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---
