Re: New additions to django.contrib?
About your topic on adding South to Django core. Andrew is working on that: https://www.djangoproject.com/weblog/2013/mar/22/kickstarting-schema-migrations-django/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: GitHub migration done!
Could you make tags out of stable releases. It would help a lot :} -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/NzF2b8Xl9wUJ. 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.
Re: GitHub migration done!
On Saturday, April 28, 2012 5:08:09 AM UTC+2, Adrian Holovaty wrote: > > OK, it's live! > https://github.com/django/django > Great news! Therefore probably you should update this site: https://www.djangoproject.com/download/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/VbYNgiYgClwJ. 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.
Re: Proposal: drop Python 2.5 support in Django 1.5
Me too. + 1 -- Matt Harasymczuk http://www.matt.harasymczuk.pl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/4b6tOPU9xjMJ. 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.
Re: Cleaning up manage.py and import paths
I suggest naming it src, and then having example.com - contrib - docs - public - src - manage.py - myapp - __init__.py - settings.py - urls.py - virtualenv -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/PbsyqJj4jOcJ. 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.
Re: django tests fails!
#urls.py
url(r'^', include('rm.urls', namespace="rm"), name="rm"),
#rm/urls.py
url(r'progress/$', ProgressView.as_view(), name='progress'),
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/rzSmmSfi9VkJ.
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.
Re: django tests fails!
> python manage.py test
Creating test database for alias 'default'...
E...E..E.
==
ERROR: test_middleware_disabled
(django.contrib.messages.tests.cookie.CookieTest)
--
Traceback (most recent call last):
File
"C:\Python27\Lib\site-packages\django\contrib\messages\tests\base.py", line
251, in test_middleware_disabled
data, follow=True)
File "c:\Python27\lib\unittest\case.py", line 471, in assertRaises
callableObj(*args, **kwargs)
File "C:\Python27\Lib\site-packages\django\test\client.py", line 455, in
post
response = super(Client, self).post(path, data=data,
content_type=content_type, **extra)
File "C:\Python27\Lib\site-packages\django\test\client.py", line 256, in
post
return self.request(**r)
File "C:\Python27\Lib\site-packages\django\test\client.py", line 387, in
request
response = self.handler(environ)
File "C:\Python27\Lib\site-packages\django\test\client.py", line 84, in
__call__
response = self.get_response(request)
File "C:\Python27\Lib\site-packages\django\core\handlers\base.py", line
169, in get_response
response = self.handle_uncaught_exception(request, resolver,
sys.exc_info())
File "C:\Python27\Lib\site-packages\django\core\handlers\base.py", line
218, in handle_uncaught_exception
return callback(request, **param_dict)
File "C:\Python27\Lib\site-packages\django\utils\decorators.py", line 91,
in _wrapped_view
response = view_func(request, *args, **kwargs)
File "C:\Python27\Lib\site-packages\django\views\defaults.py", line 31, in
server_error
return http.HttpResponseServerError(t.render(Context({})))
File "C:\Python27\Lib\site-packages\django\template\base.py", line 124, in
render
return self._render(context)
File "C:\Python27\Lib\site-packages\django\test\utils.py", line 66, in
instrumented_test_render
return self.nodelist.render(context)
File "C:\Python27\Lib\site-packages\django\template\base.py", line 747, in
render
bits.append(self.render_node(node, context))
File "C:\Python27\Lib\site-packages\django\template\debug.py", line 73, in
render_node
result = node.render(context)
File "C:\Python27\Lib\site-packages\django\template\loader_tags.py", line
127, in render
return compiled_parent._render(context)
File "C:\Python27\Lib\site-packages\django\test\utils.py", line 66, in
instrumented_test_render
return self.nodelist.render(context)
File "C:\Python27\Lib\site-packages\django\template\base.py", line 747, in
render
bits.append(self.render_node(node, context))
File "C:\Python27\Lib\site-packages\django\template\debug.py", line 73, in
render_node
result = node.render(context)
File "C:\Python27\Lib\site-packages\django\template\loader_tags.py", line
64,in render
result = block.nodelist.render(context)
File "C:\Python27\Lib\site-packages\django\template\base.py", line 747, in
render
bits.append(self.render_node(node, context))
File "C:\Python27\Lib\site-packages\django\template\debug.py", line 73, in
render_node
result = node.render(context)
File "C:\Python27\Lib\site-packages\django\template\loader_tags.py", line
64, in render
result = block.nodelist.render(context)
File "C:\Python27\Lib\site-packages\django\template\base.py", line 747, in
render
bits.append(self.render_node(node, context))
File "C:\Python27\Lib\site-packages\django\template\debug.py", line 73, in
render_node
result = node.render(context)
File "C:\Python27\Lib\site-packages\django\template\base.py", line 1008,
in render
return self.nodelist.render(new_context)
File "C:\Python27\Lib\site-packages\django\template\base.py", line 747, in
render
bits.append(self.render_node(node, context))
File "C:\Python27\Lib\site-packages\django\template\debug.py", line 73, in
render_node
result = node.render(context)
File "C:\Python27\Lib\site-packages\django\template\defaulttags.py", line
449, in render
raise e
TemplateSyntaxError: Caught NoReverseMatch while rendering: u'rm' is not a
regis
tered namespace
==
ERROR: test_middleware_disabled
(django.contrib.messages.tests.fallback.FallbackTest)
--
Traceback (most recent call last):
File
"C:\Python27\Lib\site-packages\django\contrib\messages\tests\base.py", line
251, in test_middleware_disabled
data, follow=True)
File "c:\Python27\lib\unittest\case.py", line 471, in assertRaises
callableObj(*args,
Re: django tests fails!
I am sorry, my bad. I was not sure that this one is a bug too, therefore I have asked at django-users: https://groups.google.com/forum/#!topic/django-users/S_4IuKw_e2U however I think it is, and it should be reported to trac. What do you think? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/EGl6rLU2vQEJ. 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.
django tests fails!
I have found two bugs in tests django.contrib.auth https://code.djangoproject.com/ticket/16412 https://code.djangoproject.com/ticket/16413 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/Vg15tT63Y6MJ. 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.
Re: Django Error Display Page
Why not to give ability to chose by the developer? if settings.VERBOSE_DEBUG: as it is else: tabbed view or DEBUG_VIEW = 'tabbed' DEBUG_VIEW = 'default' etc... IMHO: DEBUG_VIEW is better and more extensible in future. -- Matt Harasymczuk http://www.matt.harasymczuk.pl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/DCJeGXfO8s0J. 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.
Re: Deprecation policy for IE6
Totally agree, If someone moved out of the IE 6, then he/she move out of the IE 7, too. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/fAHtqn9esigJ. 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.
Odp: Re: Django Error Display Page
Colored output of the trackeback does not solve my problem of scrolling few screens in order to find whats happening, or use cmd-F key to quick jump. I think this is not a good way to do this. What's I am thinking is a tabs at the top which manipulates with visibility of certain divs of error page. A quick temporary fix, before complete redesign of error page. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/d0F2R2NvWkJNQ3NK. 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.
Django Error Display Page
Hi, I have been thinking about this for quite a long time. Can you make an error display page less verbose? I mean not to exclude those useful information, but to initially fold (hide) them. Fold those items: - Python path at the top yellow background. - (Hide or fold) django traceback entries When I have a problem I have to scroll down (passing django calls) few pages until I am able to find which MY action caused an error. I know looking at django callback may be useful, but in my case, hardly ever, and probably for newcommers also. I am imagining this like that: At the top of the error page, there are tabs. Summary, Traceback, Request, Settings, and copy-paste view (feedback view). Summary tab, contains this yellow background information with PYTHON_PATH initially folded, and traceback filtered out to include only information from project not calls from django itself. Traceback, request and settings tabs as it is right now, but separated for easy of view. copy-paste (feedback) - a standardize view for easy of copy-and-paste to the Internet message boards, groups and so on... It would need a template refactor and some more js involved, should not be a hard thing to do. I read that there is a plan to redesign an error page, but since then, those modifications should do the job. What do you think? -- Matt Harasymczuk http://www.matt.harasymczuk.pl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/b0pKaV9JR2gzXzRK. 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.
admin.site.register decorator
Recently, I had to make more than one admin class in admin.py file.
I have never had a situation like this before.
I keept my admin classes in separate files in admin module.
It came to me that after each class definition you have to make
admin.site.register(Class, AdminClass)
Hence:
- Where is the best place to put this call?
after a AdminClass definition?
Try it, it looks ugly
- At the end of file with other registers?
it is similar to signals connect and template_tag registering.
Therefore it should be similarly decorated by decorator.
@register_admin(class=ModelName)
class ModelAdmin:
pass
what do you think?
BTW:
This one is even more ugly than previous one!
How about changing:
model_method.allow_tags = True
model_method.short_description = _( 'Model Method' )
into:
@options(allow_tags=True, short_description=_('Model Method'))
or:
@allow_tags
@short_desctiption(_('Model Method'))
?
--
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.
Re: templates block prepend and append
This should solve my problems, therefore my question is no longer valid.
I missed that in the documentation.
Probably I should ask at django-users first.
Although
{% extends "admin/index.html" after "blockname" %}
would be a nice shorthand.
or
{% from "admin/index.html" import "blockname" %}
to import only one block from a template file.
--
Matt Harasymczuk
http://www.matt.harasymczuk.pl
--
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.
templates block prepend and append
I have recently fought with extending templates.
Plenty of my usecases are almost the same: append some html before or after
admin templates blocks.
To do so, I have to take template, copy the contents and save modified file
as a html in my templates dir.
What happens if django contrib.admin pages gets an update?
I have to take templates and do my job once again.
I suggest adding templatetag
- {% prepend "blockname" %}{% endprepend %}
- {% append "blockname" %}{% endappend %}
or "before/after" blocks
or even modification to extends
{% extends "admin/index.html" "after" "blockname" %}
What do you think?
--
Matt Harasymczuk
http://www.matt.harasymczuk.pl
--
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.
Odp: Re: model fields options
In my opinion Meta class may contain this kind of information, and it would simplify the process of designing models. Especially handling fields which contains a lots of data inserted via arguments. However, I think that the Meta class properties should be an alias or a handy shortcut, not one and only one way of setting those options. -- 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.
model fields options
I had an idea.
To move model fields options, such as:
- blank=BOOL
- null=BOOL
- auto_add=BOOL
- auto_add_now=BOOL
- db_index=BOOL
and others boolean options to Meta class of this model.
It would make model fields more readable and human friendly.
However I am not convinced, that it would be a good idea, thou.
I am just giving an discussion topic.
it works for unique_together
why not to add:
unique = ('name', 'login', 'ssn')
db_index = ('name', 'login')
auto_add = ('signup_date', )
auto_add_now = ('last_mod', )
null = ('comment', 'first_name')
... and so on ...
What do you think?
--
Matt Harasymczuk
http://www.matt.harasymczuk.pl
--
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.
countries model or list like settings.LANGUAGES
I have to agree with this guy:
http://code.djangoproject.com/ticket/5446
There should be a model to hold country name and language:
{% quote %}
The idea is to have something like:
country = models.CountryField()
language = models.LanguageField()
Instead of:
lang = models.CharField ( max_length=5, choices=settings.LANGUAGES)
and
COUNTRIES = (
('fr', _('France')),
('de', _('Germany')),
...
)
country = models.CharField(max_length=10, choices=COUNTRIES)
which requires redoing the translation work and which is tedious to manually
maintain.
{% endquote %}
However this is 4 years old and still not resolved.
How about making such dict:
{
'ISO-2 letter code': {
'fullname': _('Country full name'),
'iso-3 letter code': 'ISO',
'languages': [
('is_O1', _('lang native name')),
('is_O2', _('lang native name2')),
},
... and so on ...
}
This is only a suggestion how it may look like.
However this topic seems to be a pretty important for I think lots of
developers.
At least provide a COUNTRIES list like LANGUAGES list.
--
Matt Harasymczuk
www.matt.harasymczuk.pl
--
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.
