Re: dbsettings, and user configurable app settings

[jedie]

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.

[jedie]

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...

[jedie]

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...

[jedie]

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

[jedie]

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

[jedie]

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...

[jedie]

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=.

myuser.user_permissions.add("whoops, a string here?!?")

[jedie]

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...

[jedie]

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

[jedie]

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]

[jedie]

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]

[jedie]

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?

[jedie]

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...

[jedie]

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...

[jedie]

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: Bug: Underscores in primary keys and quote/unquote...

[jedie]

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...

[jedie]

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
-~--~~~~--~~--~--~---

"@cache_page" bug...

[jedie]

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()...

[jedie]

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()...

[jedie]

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...

[jedie]

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?!?!

[jedie]

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???

[jedie]

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???

[jedie]

Is there any change, that the interactive traceback debugger is a
feature for django v1.0 ???

http://code.djangoproject.com/wiki/VersionOneFeatures?action=diff=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

[jedie]

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

[jedie]

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...

[jedie]

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
-~--~~~~--~~--~--~---