Re: dbsettings, and user configurable app settings
For PyLucid i have made http://code.google.com/p/django-dbpreferences/ """ A django app defines a form with initial values. The form cleaned data dict would be stored serialized into the database. The app can easy get the current preference dict and the user can easy edit the values in the django admin panel. """ Some examples: http://code.google.com/p/django-dbpreferences/wiki/DBPreferences_example http://code.google.com/p/django-dbpreferences/wiki/UserSettings_example Mfg. Jens -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Manage CSS/JS files in admin views.
I notice that jQuery comes into django with http://code.djangoproject.com/changeset/12297 In my own project i already have jQuery saved in my own media dir and i added in my own /admin/base_site.html file. So in some admin views i have two jQuery included. That's not really good. Managing CSS/JS files in the admin views should be reconsidered. But i have not a solution for this, now :( Ideas? Mfg. Jens -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: double {{ media }} in admin templates...
I created a ticket: http://code.djangoproject.com/ticket/12726 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
double {{ media }} in admin templates...
I have double media files in some admin panel views. See: http://paste.pocoo.org/show/171364/ There is two times {{ media }} in the file contrib/admin/templates/ admin/change_list.html ince Changeset 12298 [1] One in {% block extrastyle %} and one in {% block extrahead %} This is a bug, isn't it? [1] http://code.djangoproject.com/changeset/12298#file6 Mfg. Jens Diemer -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Why not datetime.utcnow() in auto_now/auto_now_add
On 25 Nov., 00:36, Russell Keith-Magee wrote: > Why would it be? A datetime field isn't necessarily stored in UTC. It > uses datetime.now() because that will return the same time as > settings.TIME_ZONE. To improve my understanding: What if the server changed and the time zone is not the same? IMHO the user can choose: 1. leave the settings.TIME_ZONE to the old value, so all old datetimes are right, but new datetimes are wrong. Or 2. he can update settings.TIME_ZONE and old datetimes would be wrong, but new are right. Isn't it? > On top of that, making this change would be a *huge* backwards > incompatibility, as any existing uses of auto_now etc would break. Yes. But it's easy to add a settings and the admin can choose between now or utcnow. The default settings should be set utcnow. Mfg. Jens Diemer -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Why not datetime.utcnow() in auto_now/auto_now_add
DateTimeField "auto_now" and "auto_now_add" used datetime.now(). But why this? IMHO it's better to use datetime.utcnow(), isn't it? Mfg. Jens Diemer -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
cache middleware on multi sites...
There exist some "intersection" on multi site installation, if i use django.middleware.cache.UpdateCacheMiddleware and django.middleware.cache.FetchFromCacheMiddleware Problem: The cache key would be only generated based on the url without the domain name. So if the page /foobar/ exist on site A and site B but with different content, they would be only caches one time. Solutions: 1. The user can insert this into his settings: CACHE_MIDDLEWARE_KEY_PREFIX = "FooBar %s" % SITE_ID 2. Django should insert the SITE_ID into cache key. e.g. in django.utils.cache.get_cache_key() 3. Django should use the complete path to build the cache key. e.g.: use request.build_absolute_uri() in django.utils.cache._generate_cache_header_key() instead of iri_to_uri (request.path) Mfg. Jens Diemer -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=.
CACHE_BACKEND = 'locmem:///' <-> 'locmem://'
What is the right "spelling": 'locmem:///' or 'locmem://' ??? In the docu is three "/" [1] but in global_settings.py is two "/" [2] [1] http://docs.djangoproject.com/en/dev/topics/cache/#local-memory-caching [2] http://code.djangoproject.com/browser/django/trunk/django/conf/global_settings.py?rev=11709#L329 Sorry, if this is nonrelevant ;) Mfg. Jens Diemer -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=.
myuser.user_permissions.add("whoops, a string here?!?")
Hi... If i made this: myuser.user_permissions.add("whoops, a string here?!?") I get no Traceback, why? Is this a Bug or something for: http://code.djangoproject.com/wiki/BetterErrorMessages Mfg. Jens --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
List of Backwards-compatible changes...
There exist the gread wiki page: http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges I think it would be nice if there is the same list for Backwards- compatible changes, too. Sometimes i find some parte in the documentation and wonder, woops this must be new. OK, on the main Documentation page every new stuff market bold "New:"... And we have the weblog and "this week in django"... But a Backwards-compatible changes list with a TOC is IMHO more well arranged. So i can good see, what's is new for _me_. Mfg. Jens Diemer --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: routing to a log file when daemonizing a fastcgi process
On 29 Feb., 21:38, tamas kemenczy <[EMAIL PROTECTED]> wrote: > Recently at work I've encountered a need to be able to redirect the > stdout/stderr of a daemonized fastcgi Django process to a log file > (something other than /dev/null). This is very interesting for me, too. Can you post you existing code in a django ticket? btw. i have problems to setup a fastCGI app in a non root environment. If something is not right, it only helps to look into the Apache error log. But i haven't access to the log file :( Sometimes it helps to activate the flup "low level" debug traceback, but this is deactivated hardcoded with http://code.djangoproject.com/changeset/4170 I have created a patch for this: http://code.djangoproject.com/ticket/6610 Redirect stdout/stderr into a file helps, too. I created a fastCGI dispatcher on the top of the django runfastcgi() function. In this additional layer i implemented a file logging (using the logging module) and a way for catching all possible errors and displayed these with a small own WSGI app. These two files contains the code: http://pylucid.net:8080/pylucid/browser/trunk/pylucid/index.fcgi http://pylucid.net:8080/pylucid/browser/trunk/pylucid/PyLucid/system/fastcgi_server.py Unfortunately, not all errors intercepted :( It would help, if there exist something like a "always reload" mode in tb_catch_app(), but i don't know to implement this. -- Mfg. Jens Diemer A django powered CMS: http://www.pylucid.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Pluggable filestorage [was Heads-up: doing a bit of triage work]
On 17 Sep., 18:13, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > On 9/17/07, jedie <[EMAIL PROTECTED]> wrote: > > > What's about a FTP backend? ;) > > I'd be -1 on including one with Django for the simple reason that FTP > is dangerously insecure. Anyone still using FTP should be encouraged > strongly to switch. > > The is the same reasoning behind not shipping with a CGI handler -- > Django shouldn't make it easy to do stupid things. > > Now, a SSH/SFTP backend... that would rock. Yes, SFTP would be better than normal FTP. IMHO it needs some external Libs to support this. FTP is in the standard python lib. I can use FTP for a little circuitous way: I would like to store files via FTP on the same machine. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Pluggable filestorage [was Heads-up: doing a bit of triage work]
On 17 Sep., 15:38, "Jacob Kaplan-Moss" <[EMAIL PROTECTED]> wrote: > In general, more backends is better, of course :) I'd be +1 on just > including all of 'em (though SVN is a bit marginal), but if others > feel differently I'd love to hear about it. What's about a FTP backend? ;) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: manage.py idea?
On 15 Aug., 19:30, Rob Hudson <[EMAIL PROTECTED]> wrote: > Would it be worthwhile to add a way to purge unused content types via > manage.py? It could look at INSTALLED_APPS and anything not installed > it removes? I have started a tread in django-users a long time ago: http://groups.google.com/group/django-users/browse_thread/thread/4f74fc5a98f7c8fe/ Here a old ugly code for removing unused conrenttypes: http://paste.pocoo.org/show/1482/ Mfg. Jens Diemer --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Documentation should never show non-working examples. - was: "@cache_page" bug...
On 5 Jul., 09:41, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Thu, 2007-07-05 at 00:39 -0700, jedie wrote: > > The documentation philosophy is relevant for me: The documentation > > should really never show non-working examples. > > Unsurprisingly,weare in100%agreement. So if the documentation and > the code are in disagreement, one of them has to be fixed. Fixing the > code is the right thing in this case. No, i thing we are not 100% agreement ;) I think: 1. The documentation should be changed, if there is a not working code example. (At least a node sould be inserted.) 2. Fix the bug and commit the pach. 3. Update the documentation again. (remove the obsolete note) You think: inset a note in the documentation is needless, because the bugfix patch would be shortly commit. IMHO: Bugs lived a long time in django, often :( It is not necessary to search non working example code every day or so. But if a user find a buggy example code and write a ticked like http://code.djangoproject.com/ticket/4649 , the documentation should be updated until the bug is not fixed. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Documentation should never show non-working examples. - was: "@cache_page" bug...
On 4 Jul., 09:51, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Wed, 2007-07-04 at 00:30 -0700, jedie wrote: > > "shortly"... But my "change docu" ticket is opened 2 weeks ago: > >http://code.djangoproject.com/ticket/4649 > > > The real bug is 2 years old and last modified 2 weeks ago, too: > >http://code.djangoproject.com/ticket/1015 > > Posts like this really encourage people to stop and help you, too. > > Have a look at what we've indicated is the correct fix for the problem > (#1015). Notice how the last comment on that ticket indicates what needs > to be done to get it finished? Directing your energies in that direction > would be a more productive use of time than posts like this. Sorry, you have misunderstood this. Thus I have not meant this. ;) Fixing the ticket #1015 is not important to me. The documentation philosophy is relevant for me: The documentation should really never show non-working examples. This is the point i mean and that is the question here. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: "@cache_page" bug...
On 23 Jun., 12:40, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Fortunately,it'sallincrediblymoot, since the real fix (in #1015) is > just about ready to go.Itwas being looked at again as a result of Gary > closing the ticket with a pointer to the real fix the first time, before > this thread started. So the issue wil lbe resolved in a satisfactory way > shortly anyway. "shortly"... But my "change docu" ticket is opened 2 weeks ago: http://code.djangoproject.com/ticket/4649 The real bug is 2 years old and last modified 2 weeks ago, too: http://code.djangoproject.com/ticket/1015 The documentation has not been changed and still display a not working example code: http://www.djangoproject.com/documentation/cache/#the-per-view-cache When is "shortly" ? Btw. In between I used the per-view-cache no more. I think only of new users and i think it's a general question. =;-) voting for change the docu: +1 - Jens Diemer +1 - Smiley Chris +1 - Aidas Bendoraitis -1 - Gary Wilson -1 - Malcolm Tredinnick Is this right? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Bug: Underscores in primary keys and quote/unquote...
I don't know how to find this bug. So i create a ticket for this: http://code.djangoproject.com/ticket/4725 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Bug: Underscores in primary keys and quote/unquote...
On 26 Jun., 13:53, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Since the bug is crash inside change_stage() in the same file, try to > work out what why the wrong string is being passed in there. This should > be just pieces of input captured from the URL (via admin/urls.py), so > this suggests that something is creating the wrong URL (and I thought we > would have noticed that previously: it's why quote() and unquote() were > written in the first place). No, i think the URL is ok. It's the combination of "_ad"... Because the primary key "TEST_adTEST" goes into the same traceback... In /django/views/decorators/cache.py in _wrapped_view_func the String is ok: --- Line 39. | response = view_func(request, *args, **kwargs) --- Local var "args" is -> ('PyLucid', 'pagesinternal', 'TEST_adTEST') In the next trace /django/contrib/admin/views/main.py in change_stage the String is broken: --- Line 322. | manipulator = model.ChangeManipulator(object_id) --- Local var "object_id" is -> 'TEST\xadTEST' The method change_stage() always unquote the object_id in Line 310! And repr(unquote("TEST_adTEST")) is -> 'TEST\xadTEST' Note: I used the unicode branch. Does the error related to this branch? I implement a silly work-a-round (rename the primary keys on the fly): http://pylucid.net/trac/changeset/1110 -- Mfg. Jens Diemer A django powered CMS: http://www.pylucid.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Bug: Underscores in primary keys and quote/unquote...
I have a model class like this: class PagesInternal(models.Model): name = models.CharField(primary_key=True, maxlength=150) ... And my names (the primary keys) contains unterscore, like this: "page_admin.edit_page" I used no ID for the primary key, because i "addressed" the entries about the names. I used the unicode-branch and get a error, if i edit a entry in this model with the django admin panel: Traceback (most recent call last): File "./django/core/handlers/base.py" in get_response 72. response = middleware_method(request, callback, callback_args, callback_kwargs) File "./PyLucid/middlewares/pagestats.py" in process_view 45. response = view_func(request, *view_args, **view_kwargs) File "./django/contrib/admin/views/decorators.py" in _checklogin 55. return view_func(request, *args, **kwargs) File "./django/views/decorators/cache.py" in _wrapped_view_func 39. response = view_func(request, *args, **kwargs) File "./django/contrib/admin/views/main.py" in change_stage 324. manipulator = model.ChangeManipulator(object_id) File "./django/db/models/manipulators.py" in __init__ 261. self.original_object = self.manager.get(pk=obj_key) File "./django/db/models/manager.py" in get 73. return self.get_query_set().get(*args, **kwargs) File "./django/db/models/query.py" in get 258. obj_list = list(clone) File "./django/db/models/query.py" in __iter__ 111. return iter(self._get_data()) File "./django/db/models/query.py" in _get_data 478. self._result_cache = list(self.iterator()) File "./django/db/models/query.py" in iterator 186. cursor.execute("SELECT " + (self._distinct and "DISTINCT " or "") + ",".join(select) + sql, params) File "./django/db/backends/util.py" in execute 23. 'sql': smart_unicode(sql) % convert_args(params), File "./django/db/backends/util.py" in convert_args 50. return tuple([to_unicode(val) for val in args]) File "./django/db/backends/util.py" in 48. to_unicode = lambda s: force_unicode(s, strings_only=True) File "./django/utils/encoding.py" in force_unicode 42. s = unicode(s, encoding, errors) UnicodeDecodeError at /_admin/PyLucid/pagesinternal/ page_admin.edit_page/ 'utf8' codec can't decode byte 0xad in position 4: unexpected code byte But i think this is not a real UnicodeDecodeError... It's a problem with the quote()/unquote() routines in django.contrib.admin.views.main.py The string before unquote() is..: page_admin.edit_page The string after unquote() is...: page\ufffdmin.edit_page In a local test, it seems to work fine: from django.contrib.admin.views.main import quote, unquote TEST_STRING = "page_admin.edit_page" q = quote(TEST_STRING) print "quote():", q print "unquote():", unquote(q) print print "unquote()2:", unquote(TEST_STRING) output: quote(): page_5Fadmin.edit_5Fpage unquote(): page_admin.edit_page unquote()2: page\ufffdmin.edit_page But, in my case, the real input for unquote() is not the quoted one like "page_5Fadmin.edit_5Fpage"! It is the non-quoted one like: "page_admin.edit_page" And then the unquote() break the string into: "page \ufffdmin.edit_page" It this a django bug? -- Mfg. Jens Diemer A django powered CMS: http://www.pylucid.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: "@cache_page" bug...
OK, i accepted: The documentation should not document bugs. This is the job for trac. But on the other side: The documentation should IMHO never have example code that doesn't work. In this specific instance, a remark would have been enough. e.g.: "This example code doesn't work until #1015 is fixed. A work-a-round is to use this code: FooBar..." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
"@cache_page" bug...
In the docu there ware two syntax for a "per-view cache": """ def my_cool_view(request): # cool processing slashdot_this = cache_page(slashdot_this, 60 * 15) """ or """ @cache_page(60 * 15) def my_cool_view(request): # cool processing """ see: http://www.djangoproject.com/documentation/cache/#the-per-view-cache Both syntax version doesn't work yet, because of this Bug: http://code.djangoproject.com/ticket/1015 The Bug is opened 2 years ago. Two years! And this ticket has a work-a- round that works: """ @cache_page def my_cool_view(request): # cool processing """ I fall into this bug trap, because i have used the code from the documentation. If you search the maillinglist, you can see, that other users are falled into the same trap. I have made a ticket, that the docu should be changed (insert a comment and/or insert the work-a-round): http://code.djangoproject.com/ticket/4649 This ticket is closed ("invalid")... I think that is not the best way, to handle those things. -- Mfg. Jens Diemer A django powered CMS: http://www.pylucid.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: UnicodeError with newforms.form_for_model()...
On 25 Mai, 01:03, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > On Thu, 2007-05-24 at 07:50 -0700, jedie wrote: > > I found a UnicodeError with newforms.form_for_model() and > > LANGUAGE_CODE = 'de': > > However, this is (a) a known bug and (b) fixed on the Unicode branch, so > there's no need to take it any further. Yes. I test it with the unicode branch. It seems to work fine. Here a generalized test file: #!/usr/bin/env python # -*- coding: utf-8 -*- import os from django.core import management from examples import settings os.environ["DJANGO_SETTINGS_MODULE"] = "examples.settings" settings.DATABASE_ENGINE = "sqlite3" settings.DATABASE_NAME = ":memory:" settings.LANGUAGE_CODE = 'de' settings.INSTALLED_APPS = ( 'django.contrib.auth', 'django.contrib.contenttypes', ) print "init django, create tables...", management.setup_environ(settings) # init django management.syncdb(verbosity=0, interactive=False) # Create Tables print "OK\n" #__ # Test: from django.contrib.auth.models import User from django import newforms as forms UserForm = forms.form_for_model(User) form = UserForm() html_code = form.as_p() print repr(html_code) Hope the unicode branch would be merged soon ;) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
UnicodeError with newforms.form_for_model()...
I found a UnicodeError with newforms.form_for_model() and LANGUAGE_CODE = 'de': Traceback (most recent call last): File "/home/jens/workspace/PyLucid0.8(django)/PyLucid/dev/ local_test2.py", line 29, in html_code = form.as_p() File "/home/jens/workspace/PyLucid0.8(django)/django/newforms/ forms.py", line 162, in as_p return self._html_output(u'%(label)s %(field)s%(help_text)s', u'%s', '', u' %s', True) File "/home/jens/workspace/PyLucid0.8(django)/django/newforms/ forms.py", line 136, in _html_output help_text = help_text_html % field.help_text UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 86: ordinal not in range(128) Some local vars from the Web-Traceback: field: label: u'Passwort:' Here a small testscript to reproduce the error (You should use your own settings file): from django.core import management os.environ["DJANGO_SETTINGS_MODULE"] = "PyLucid.settings" from PyLucid import settings settings.DATABASE_ENGINE = "sqlite3" settings.DATABASE_NAME = ":memory:" settings.LANGUAGE_CODE = 'de' print "init django, create tables...", management.setup_environ(settings) # init django management.syncdb(verbosity=0, interactive=False) # Create Tables print "OK\n" #__ # Test: from django.contrib.auth.models import User from django import newforms as forms UserForm = forms.form_for_model(User) form = UserForm() html_code = form.as_p() print html_code (Sorry, if this is a double posting.) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: #3527 - better debug traceback with code executing...
Whats about INTERNAL_IPS [1] ? The special debugger is only available if... ...settings.DEBUG is ON (or a seperate Variable) and ...the request IP is in INTERNAL_IPS [1] http://www.djangoproject.com/documentation/settings/#internal-ips --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
syncdb should cleanup tables?!?!
I have Problems with old entries in "django_content_type". I described it here: http://groups.google.com/group/django-users/browse_thread/thread/4f74fc5a98f7c8fe/1b542eff91614ab8 I get the error "ContentType matching query does not exist." if i create a new user group. The Problem is: I had content types in my db without the corresponding model class. This happens, when you remove applications from your project or if you delete some model class in your app. There is a more detailed description in the german python-forum: http://www.python-forum.de/topic-10510.html I've hacked a standalone script to delete old entries in the tables "django_content_type" and "django_content_type": http://paste.pocoo.org/show/1482/ This it not enough. Other tables must be still updated: "auth_user_user_permissions", "auth_group_permissions", etc. Should that not do syncdb? Perhaps with an additional parameter, e.g.: "django-admin.py syncdb --cleanup=true" --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Version 1.0 feature???
Sorry, this should be related to the discussion here: http://groups.google.com/group/django-developers/browse_thread/thread/cca45aa7c9106b88 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Version 1.0 feature???
Is there any change, that the interactive traceback debugger is a feature for django v1.0 ??? http://code.djangoproject.com/wiki/VersionOneFeatures?action=diff&version=67 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: empty PATH_INFO env var
On May 3, 7:18 pm, Brian Rosner <[EMAIL PROTECTED]> wrote: > I wanted to bring up some discussion here about an empty PATH_INFO > value. The ticket #3414 also reports this problem. There is the same problem with CGI. Please look at: http://code.djangoproject.com/ticket/2407 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: The locmem patch and development progress
On Apr 25, 9:50 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > use a kernel or gcc-like terminology for the branches. +1 User can use a stable SVN version (with bugfix state) and there exist a heavy dev branch for experimentals. This branch can have a "feature freeze state". In this time the branch stabilized and a new release can be born ;) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
#3527 - better debug traceback with code executing...
Why has django not a interactive AJAX traceback debugger? Using a interactive debugger you can play with objects at any point in the error traceback. I known, a web shell is a open security hole. But the interactive debugger should only running with the development Web server and if debugging is on. The development server is not for production use. So there is IMHO no problem. Here a example pictures from Pylons: http://pylonshq.com/img/screenshots/doctraceback.gif There exist some very nice modules: http://pylonshq.com/docs/interactive_debugger.html http://pythonpaste.org/module-paste.evalexception.html http://trac.pocoo.org/browser/colubrid/trunk/colubrid/debug.py See also: http://blog.ianbicking.org/ajaxy-exception-catching.html Here you can see a screencast, how paste evalexception works: http://pythonpaste.org/screencasts/evalerror-screencast.html Existing django ticket: http://code.djangoproject.com/ticket/3527 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---