The testserver command doesn't currently allow you to set the port for
the server to run on. I teach high school in a Linux thin client lab, so
all of my students are running on the same server and each needs his/her
own port, unfortunately. (Interestingly, having 10-15 Django dev servers
running simultaneously on a quad-core Opteron with 8GB of memory while
it's busy serving 30 Gnome desktops isn't really a problem.)
I can see two ways to add the ability:
1. (the easy and clean but hackish way)
Check the first arg to see if it's an integer and, if so, assume it's
the port specification. This only involves adding an if inside
testserver's handle method. But it means that you can't list a fixture
with a name that happens to be an integer as the first fixture after the
testserver command.
2. (the more robust, but more involved way)
Add a --port option that testserver could use. The problem is that this
means adding another option to django.core.management.ManagementUtility
since each option currently has to be added globally. Adrian has a
comment that it would be ideal to allow each command to register its own
options, but that optparse checks for conflicts, so that doesn't work so
well.
Here's a suggestion to pull the options out of
django.core.management.ManagementUtility: What if we just read the
command after manage.py/django-admin.py and then passed the rest of the
parsing to a separate execute method for each Command subclass. I'm
envisioning something like
class Command(BaseCommand):
options = { 'option_name': dict_for_kwargs_to_add_option }
In the execute method of Command, we'd build up the options for the
particular command, including any options from superclasses (like
--settings, which I think every command can use).
Since this would pull apart all the options, it seems like it would
allow you to do something like what svn does. Have a 'help' command that
lists each possible command and then for 'help foo' print the usage for
that particular command, including options, etc.
If this seems like an elegant solution and is something people would be
interested in, I can probably code it up this afternoon. (I teach until
about 1:00 Eastern when my planning period starts.)
If this seems too involved, I'm open to other ideas!
Todd
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
