Re: Ticket #650 - render_to_response uses Context instead DjangoContext
No, this is meant to go at the end of a long view function
def index(request):
# Lots of code
render_to_response_with_req(request, 'home/index.html', {'a': 'dict'})
etc.
On 6/27/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
>
> On 6/26/07, Paul Bowsher <[EMAIL PROTECTED]> wrote:
> >
> > render_to_response is a great shortcut, however in my opinion it's let
> > down by not supporting request. I see this has been discussed a bit on
> > the ticket, however that's more in respect to replacing the existing
> > shortcut.
>
> Isn't this just the 'direct_to_template' generic view?
>
> Yours,
> Russ Magee %-)
>
> >
>
--
Paul Bowsher
--~--~-~--~~~---~--~~
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: Request for Model History to be merged into trunk (updated code supplied)
Some time ago I overviewed model history and I realized that I don't like a general idea - one model that logs everything. At that time Django was studied how to create models dynamically (http:// code.djangoproject.com/wiki/DynamicModels) and I wrote small history app for our purposes (of course, we had Napoleonic plan to include it in Django :-) ). You can find it here http://code.google.com/p/django-history/ Our plan was to show code when it'll be well documented and have all that additional features (diff, revert, etc), but I have seen this thread and decided to show it as is. I think, that it can stand a test under much more heavy load than one-model history. And all that features can be written - it shouldn't get too many time to write them. To get the history working you need to include it to your INSTALLED_APPS and: import history history.create_history_for_models(Album, Artist, Song) Main code is in base.py. What can you say about my idea and code? --~--~-~--~~~---~--~~ 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: Ticket #650 - render_to_response uses Context instead DjangoContext
On Jun 27, 8:46 pm, "Paul Bowsher" <[EMAIL PROTECTED]> wrote:
> No, this is meant to go at the end of a long view function
> def index(request):
> # Lots of code
> render_to_response_with_req(request, 'home/index.html', {'a': 'dict'})
Firstly, you should be `return`ing this request. ;)
Secondly, it looks like the direct_to_template function does exactly
this (albeit with a tiny bit of overhead in checking for and calling
callable context items).
--~--~-~--~~~---~--~~
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: Status of contrib.comments rewrite?
2007/6/26, Jacob Kaplan-Moss <[EMAIL PROTECTED]>: > > On 6/26/07, David Larlet <[EMAIL PROTECTED]> wrote: > > I'm just curious, I've read somewhere (maybe here) that the > > contrib.comments package need to be rewritten in order to allow more > > flexibility (like user.get_profile) and to use newforms. I thought > > that's the main reason why this part is not documented. > > > > What's the status of this update? Did someone is already on this? > > I'm working on it; pretty close to a call-for-comments (sorry :) stage. > > Stay tuned, > There is some kind of magic stuff in django development that make things happens just when I need it. Thank you all devs, definitely. David --~--~-~--~~~---~--~~ 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: Shared memory across processes
Marty Alchin wrote: > Regardless though, I think Jacob makes the best point so far: Django's > cache system is robust enough to handle it if you pick a decent > backend. And if there's a need to make the built-in options more > robust, we can deal with that when the need arises. > What about registering to watch for a signal given to the web server process and invalidate the cache when that is received ? That way someone who really wants to clear the dbsettings across multiple processes can force it via a "kill -s" system script. Just an idea, Rob :) --~--~-~--~~~---~--~~ 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: Ticket #650 - render_to_response uses Context instead DjangoContext
Yes, sorry, I missed the return, was hastily typed as an example. Hadn't
seen direct_to_template, that does indeed seem like a good way to go. Thanks
for the pointer :)
On 6/27/07, SmileyChris <[EMAIL PROTECTED]> wrote:
>
>
> On Jun 27, 8:46 pm, "Paul Bowsher" <[EMAIL PROTECTED]> wrote:
> > No, this is meant to go at the end of a long view function
> > def index(request):
> > # Lots of code
> > render_to_response_with_req(request, 'home/index.html', {'a':
> 'dict'})
>
> Firstly, you should be `return`ing this request. ;)
>
> Secondly, it looks like the direct_to_template function does exactly
> this (albeit with a tiny bit of overhead in checking for and calling
> callable context items).
>
>
> >
>
--
Paul Bowsher
--~--~-~--~~~---~--~~
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: Shared memory across processes
On Jun 26, 11:28 am, "Marty Alchin" <[EMAIL PROTECTED]> wrote: > The biggest hurdle to dbsettings at this point is that it caches > settings in a standard Python module, which only exists within a > single process. This was all well and good while developing it, but > people are now starting to try it under mod_python, which (depending > on the Apache MPM) creates multiple processes, each with their own > dbsettings cache. This is fine except when editing settings, since it > can only update the cache in the current process. Stop me if you've heard this: This is not a bug, it's a feature. Really, though, that's what it is. mod_python is chosen for deployment environments where a person does _NOT_ want a check to occur for updates because it impacts performance, instead choosing to push updates to the server explicitly. An easy way to do this for developers is a command like this: apache[2]ctl graceful|restart Do NOT do your development under mod_python! That is _NOT_ what it's intended for. --~--~-~--~~~---~--~~ 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: Shared memory across processes
On Wed, Jun 27, 2007 at 02:41:15PM -, Donny wrote: > > On Jun 26, 11:28 am, "Marty Alchin" <[EMAIL PROTECTED]> wrote: > > The biggest hurdle to dbsettings at this point is that it caches > > settings in a standard Python module, which only exists within a > > single process. This was all well and good while developing it, but > > people are now starting to try it under mod_python, which (depending > > on the Apache MPM) creates multiple processes, each with their own > > dbsettings cache. This is fine except when editing settings, since it > > can only update the cache in the current process. > > Stop me if you've heard this: > > This is not a bug, it's a feature. > > Really, though, that's what it is. mod_python is chosen for deployment > environments where a person does _NOT_ want a check to occur for > updates because it impacts performance, instead choosing to push > updates to the server explicitly. An easy way to do this for > developers is a command like this: > > apache[2]ctl graceful|restart > > Do NOT do your development under mod_python! That is _NOT_ what it's > intended for. I think you've misunderstood Marty. He is not talking about modifying settings.py, he is talking about his dbsettings django app, which stores some parameters in the database. These parameters are intended to be changed by non-developers, and shouldn't require an apache restart to take effect. -Forest signature.asc Description: Digital signature
Re: Edit inline in newforms-admin branch (ATTN: Joseph Kocherans)
On 6/26/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > On 6/20/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > > > Yep. None of the javascript stuff really works right now. The calendar > > and picker widgets for date and time fields, for instance, are broken. > > Sounds like a good opportunity to plug ticket #4418 - widget level > support for specifying media (javascript/css) requirements. > > I haven't gone back to retrofit this into newforms-admin (or even had > a chance to look at the new edit-inline stuff), but I'd be interested > on any feedback on how the edit-inline changes would affect this > approach. Thanks for bringing this up Russ. The problem at the moment is that the admin doesn't look at any of the inlines when figuring out what javascript to load, so if your inlines have date fields, the js doesn't get loaded unless the parent has a date field. I don't think #4418 causes any problems for the new edit inline stuff. In fact it makes it easier. I was going to have to solve the duplicate problem, but I forgot about #4418. I think the widgets for each inline model just need to be included with the widgets from them main form when combining each widget.media together. Joseph --~--~-~--~~~---~--~~ 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: Shared memory across processes
> > The biggest hurdle to dbsettings at this point is that it caches > > settings in a standard Python module, which only exists within a > > single process. This was all well and good while developing it, but > > people are now starting to try it under mod_python, which (depending > > on the Apache MPM) creates multiple processes, each with their own > > dbsettings cache. This is fine except when editing settings, since it > > can only update the cache in the current process. > > Stop me if you've heard this: > > This is not a bug, it's a feature. At no point did I claim this was a bug. I merely stated that it adversely affected my app. Given the post-mortem, it became clear that I was taking the wrong approach, so if there are any bugs to be blamed here, they're in my own code, not mod_python. I freely admit that. > > Do NOT do your development under mod_python! That is _NOT_ what it's > > intended for. > > I think you've misunderstood Marty. He is not talking about modifying > settings.py, he is talking about his dbsettings django app, which stores some > parameters in the database. These parameters are intended to be changed by > non-developers, and shouldn't require an apache restart to take effect. To be even more accurate, the app is in fact specifically targeted to production environments which would normally require programmers and administrators to get involved in the most trivial of changes, where no real code is even changing, just a setting value here or there. Hopefully that makes some sense. -Gul --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Template tag render method never called
Hi, I'm using Django 0.91 More or less, this is what I'm doing: from django.core.template import Library, Node register = Library() class MyNode(Node): def __init__(self, foo): self.foo = foo print 'foo' * 100 def render(self, context): print 'bar' * 100 return 'bar' * 100 @register.tag def accounts_form_field(parser, token): return MyNode(0) When I run this using the development server, 'foo' * 100 is printed, but 'bar' * 100 is not. That is, it looks like render is never being called? Is there anything obviously wrong with what I'm doing? On another note, I tried stepping through the code with pdb, but it was ignoring my breakpoints. I tried running the server with -- noreload too, but 0.91 doesn't seem to support that. Any advice would be greatly appreciated, thanks. Kevin --~--~-~--~~~---~--~~ 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: Template tag render method never called
On 6/27/07, Kevin Tonon <[EMAIL PROTECTED]> wrote: > I'm using Django 0.91 Hi, Kevin. Please ask this question on django-users. The django-developers list is for people developing Django itself rather than using Django for a project. When you do, it'd help to include the template you're testing with as well. http://dpaste.com/ is good for that. ... > On another note, I tried stepping through the code with pdb, but it > was ignoring my breakpoints. It sounds like you're modifying code that isn't running. Perhaps try deleting .pyc files and ensure that any changed symlinks aren't cached (Mac and BSD seem to do that). --~--~-~--~~~---~--~~ 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: Template tag render method never called
Thanks. On Jun 27, 1:31 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote: > On 6/27/07, Kevin Tonon <[EMAIL PROTECTED]> wrote: > > > I'm using Django 0.91 > > Hi, Kevin. Please ask this question on django-users. The > django-developers list is for people developing Django itself rather > than using Django for a project. > > When you do, it'd help to include the template you're testing with as well. > > http://dpaste.com/is good for that. > > ... > > > On another note, I tried stepping through the code with pdb, but it > > was ignoring my breakpoints. > > It sounds like you're modifying code that isn't running. Perhaps try > deleting .pyc files and ensure that any changed symlinks aren't cached > (Mac and BSD seem to do that). --~--~-~--~~~---~--~~ 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: Shared memory across processes
Marty Alchin wrote: > I remembered seeing that FastCGI can not only run as prefork, Thank goodness. > but defaults to it. Thank *goodness*. One day mutable-shared-state, preemptive multithreading will be looked down on as the ugly, awful, historical accident that it is. The signs are good already. -- Nicola Larosa - http://www.tekNico.net/ Q: Aside from Dojo, what is your favorite Ajax framework? A: MochiKit. YUI is great code too, but MochiKit has it beat for clarity of vision and implementation quality. Bob Ippolito gets the constraints of the web. That, and I'm a Python guy at heart. -- Alex Russell, August 2006 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Tests 'datatypes' fail
Hi, it seems I'm the only one to run the test suite with mysql ;-) Ticket #4711 - http://code.djangoproject.com/ticket/4711 Currently the tests break because mysql returns 0 or 1 for a BooleanField, not False or True. Postgresql returns False or True, and for Oracle there's some special code to make it return False or True (ironically, that's how the broken test case appeared ...) So--what shall be done? Clean it up in a slightly backwards incompatible way and make the mysql backend return proper boolean values, or remove the test case? So long, Michael --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
no attribute 'get_max_name_length'
This just came up - let me know if you need more info. im CarlFK in #django Carl K [EMAIL PROTECTED]:~/django/django-src$ ... Updated to revision 5556. [EMAIL PROTECTED]:~/django$ django-admin.py startproject foo [EMAIL PROTECTED]:~/django$ cd foo [EMAIL PROTECTED]:~/django/foo$ python manage.py runserver 8080 Validating models... django.contrib.auth: 'module' object has no attribute 'get_max_name_length' 1 error found. Django version 0.97-pre, using settings 'foo.settings' Development server is running at http://127.0.0.1:8080/ Quit the server with CONTROL-C. --~--~-~--~~~---~--~~ 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: no attribute 'get_max_name_length'
Carl Karsten wrote: > This just came up - let me know if you need more info. > im CarlFK in #django > > Carl K > > [EMAIL PROTECTED]:~/django/django-src$ > ... > Updated to revision 5556. > > > [EMAIL PROTECTED]:~/django$ django-admin.py startproject foo > [EMAIL PROTECTED]:~/django$ cd foo > [EMAIL PROTECTED]:~/django/foo$ python manage.py runserver 8080 > Validating models... > django.contrib.auth: 'module' object has no attribute 'get_max_name_length' > 1 error found. > looks like it is this: http://code.djangoproject.com/ticket/4689 Dummy backend is missing get_max_name_length I'll patch and only report any problems. Carl K --~--~-~--~~~---~--~~ 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: Tests 'datatypes' fail
On 6/27/07, Michael Radziej <[EMAIL PROTECTED]> wrote: > Hi, > > it seems I'm the only one to run the test suite with mysql ;-) > > Ticket #4711 - http://code.djangoproject.com/ticket/4711 > > Currently the tests break because mysql returns 0 or 1 for a BooleanField, > not False or True. Postgresql returns False or True, and for Oracle there's > some special code to make it return False or True (ironically, that's how > the broken test case appeared ...) > > So--what shall be done? Clean it up in a slightly backwards incompatible way > and > make the mysql backend return proper boolean values, or remove the test > case? Hmm, the test seems to pass for me in mysql. I know that Malcolm edited those test cases specifically to make them pass in mysql when he did the merge -- maybe you've somehow gotten an old version of the file? In any event, looking back at the test case, it should probably just be dropped. The reason we finagled Oracle into returning True/False rather than 1/0 was for consistency because we thought that all the other backends returned True/False, and because we already had similar code in place to convert datetimes. Thanks, Ian --~--~-~--~~~---~--~~ 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: Shared memory across processes
On Jun 27, 8:07 pm, Robert Coup <[EMAIL PROTECTED]> wrote: > Marty Alchin wrote: > > Regardless though, I think Jacob makes the best point so far: Django's > > cache system is robust enough to handle it if you pick a decent > > backend. And if there's a need to make the built-in options more > > robust, we can deal with that when the need arises. > > What about registering to watch for a signal given to the web server > process and invalidate the cache when that is received ? That way > someone who really wants to clear the dbsettings across multiple > processes can force it via a "kill -s" system script. This wouldn't be a good idea if using Apache to host the application as Apache uses a lot of the signals for its own purposes and you would most likely interfere with its operation if you were to register a signal handler for a signal it uses. Because of the problems caused by applications registering signal handlers under Apache, mod_wsgi actually substitutes signal.signal() with a dummy function which logs a warning that signal registration is disabled for Python applications and otherwise ignores the request. See "Registration Of Signal Handlers" in: http://code.google.com/p/modwsgi/wiki/ApplicationIssues There has been some discussion in respect of WSGI applications registering signal handlers on the Python WEB-SIG of late and general consensus seems to be that no WSGI application should be relying on UNIX signals directly, only the underlying web server should be allowed to. This discussion was part of another discussion on somehow providing a form of event notification bus for applications. Feasibly, if a way was found of injecting an event into the process from outside, the bus being described could be a way of triggering the sort of action you are talking about in an application. Graham --~--~-~--~~~---~--~~ 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: Edit inline in newforms-admin branch (ATTN: Joseph Kocherans)
On 6/27/07, Joseph Kocherhans <[EMAIL PROTECTED]> wrote: > > Thanks for bringing this up Russ. The problem at the moment is that > the admin doesn't look at any of the inlines when figuring out what > javascript to load, so if your inlines have date fields, the js > doesn't get loaded unless the parent has a date field. I don't think > #4418 causes any problems for the new edit inline stuff. In fact it > makes it easier. I was going to have to solve the duplicate problem, > but I forgot about #4418. I think the widgets for each inline model > just need to be included with the widgets from them main form when > combining each widget.media together. Thats pretty much what I figured. I'm starting to get a handle on my backlog of mail and news, so I should be able to take a look at the new edit inline stuff in the next day or so, get the existing #4418 patch up to date with trunk, and have a look at newforms-admin integration. Yours, Russ %-) --~--~-~--~~~---~--~~ 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: Tests 'datatypes' fail
On Wed, 2007-06-27 at 14:12 -0600, Ian Kelly wrote: > On 6/27/07, Michael Radziej <[EMAIL PROTECTED]> wrote: > > Hi, > > > > it seems I'm the only one to run the test suite with mysql ;-) > > > > Ticket #4711 - http://code.djangoproject.com/ticket/4711 > > > > Currently the tests break because mysql returns 0 or 1 for a BooleanField, > > not False or True. Postgresql returns False or True, and for Oracle there's > > some special code to make it return False or True (ironically, that's how > > the broken test case appeared ...) > > > > So--what shall be done? Clean it up in a slightly backwards incompatible > > way and > > make the mysql backend return proper boolean values, or remove the test > > case? > > Hmm, the test seems to pass for me in mysql. I know that Malcolm > edited those test cases specifically to make them pass in mysql when > he did the merge -- maybe you've somehow gotten an old version of the > file? Yeah, the code in that bug report looks old (boulder-sprint branch, not trunk code). It was fixed when merged into trunk. It looks like you had a failed "svn switch" somehow or something else has gnoe worng, Michael. The lines of code in your traceback were never part of trunk (they were part of the Oracle branch, though). > In any event, looking back at the test case, it should probably just > be dropped. The reason we finagled Oracle into returning True/False > rather than 1/0 was for consistency because we thought that all the > other backends returned True/False, and because we already had similar > code in place to convert datetimes. It would be nice to be consistent. Unfortunately, I can't see how to do it reliably with MySQL's type coercions. However, I like having the tests there. That is the only place we test a few of those field types (as you noticed initially) and as somebody who relies on the test suite *a lot* as I make changes, I'd be in favour of leaving them. Regards, Malcolm -- Plan to be spontaneous - tomorrow. http://www.pointy-stick.com/blog/ --~--~-~--~~~---~--~~ 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: Tests 'datatypes' fail
On Wed, Jun 27, Ian Kelly wrote: > Hmm, the test seems to pass for me in mysql. grmbl, it happened *again* I use git-svnimport to sync the svn with my git repository, and it seems to fail around every 6 months under unknown circumstances (probably something with merges), only when I don't expect it any more! (Jacob would write: Making note to myself to check with real svn checkout when the testsuite fails). Sorry for the hiccup :-( @Malcolm: Yeah, the test looks a bit strange, and I particularily find the name misleadimg. Michael -- noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg - Tel +49-911-9352-0 - Fax +49-911-9352-100 http://www.noris.de - The IT-Outsourcing Company Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel, Hansjochen Klenk - Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
