Oops! Just saw that you were talking about 'testserver' and not
'runserver.' Sorry about that :D
Clint
On 8/28/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
>
> 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
>
>
> >
>
--
Clint Ecker
Sr. Web Developer - Stone Ward Chicago
p: 312.464.1443
c: 312.863.9323
---
twitter: clint
skype: clintology
AIM: idiosyncrasyFG
Gtalk: [EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
