I see what you are saying, thanks for the advice! On Sep 13, 12:10 pm, "nick.l...@gmail.com" <nick.l...@gmail.com> wrote: > The problem I see with creating a model for each data type is that you have > LOTS of clutter in the admin...and what happens if you want to change the > value from a string to an int? You'd have to delete it one, then recreate it > in another...just a lot of steps. Also it means more models to maintain...if > you find yourself wanting to change a field on a data type model...and you > realize that would be a good change across the board...then your stuck with > running multiple migrations...(or I suppose you could sublclass the model > too...but that sounds yucky as well! :) > > I know it's more work up front to create a validator, but I also think it's > cleaner in the end to have just one model for Environmental Variables with a > type field. By creating the custom validation in the admin, you can give the > users a bit of help too when they are creating/changing variables. (ie > helping them along saying you chose data type int, and gave me a string...) > > n > > On Mon, Sep 13, 2010 at 6:55 PM, pixelcowboy <pixelcowbo...@gmail.com>wrote: > > > > > > > Yes, it totally does! Thanks again for your help. Another work around > > might be just creating different models for each data type that I want > > to validate, as in your first example maybe... but create a different > > model for each different data type possibility? What do you about this > > approach? > > > On Sep 13, 9:27 am, "nick.l...@gmail.com" <nick.l...@gmail.com> wrote: > > > hmm ok I'm thinking out loud here :) > > > > So you want your users to have the ability to create env variables > > through > > > the Django admin. You also want these variables to be validated (ie you > > > don't want people to put 123 in a char var). > > > > I still see this solution as being at least a starting ground. You would > > > just have to add some customization to the admin. Read: > >http://docs.djangoproject.com/en/dev/ref/contrib/admin/#adding-custom... > > > > Then in your form you can validate the data (ie check to make sure that > > the > > > value for the variable is of type what ever type they picked.) > > > > Then if your user attempted to put an int in a string you can have the > > > django admin raise errors to the user saying something to the effect "You > > > dingdong, the number 1 is not a string. If you want the number 1 to be a > > > string please put it in quotes" > > > > as an aside: You could also add a foreign key to the project (if you have > > a > > > project model) > > > > re: adding arbitrary models to django would be difficult, though i think > > you > > > can do it. The problem there is that each time you add a new model you'd > > > have to sync the database again. If you remove a model django won't > > remove > > > the tables in the DB you'd have to go and remove that table manually. > > > > The problem with validating an env-var pythonically in a database > > is..well > > > the database isn't python and vice versa. The way I think your're > > thinking > > > about it is you want to have a dynamic database where you can create > > > variables and destroy variables and change variable types the way you do > > in > > > python (ie a = 1, a= "1", del a, etc...) > > > > I think you're problem needs some creative thinking to create an > > environment > > > to create variables that replicates the way you can create variables in > > > Python. > > > > I hope I made some sense! :) > > > > n > > > > Once in there you can > > > On Mon, Sep 13, 2010 at 3:56 PM, pixelcowboy <pixelcowbo...@gmail.com > > >wrote: > > > > > The only reason I dont share the information is that I dont want to > > > > bore you to death. The application will need to provide (via a > > > > database) per project environment variables for use in external client > > > > applications. However, those variables might, or might not change from > > > > project to project. > > > > > The only problem that I see with your solution above is that it would > > > > not validate for type (in a pythonic sense). What way would there be > > > > to add an arbitrary number of a diverse set of django model types? > > > > Thanks again for your help. > > > > > On Sep 13, 6:40 am, "nick.l...@gmail.com" <nick.l...@gmail.com> wrote: > > > > > That's fine...well for data types ad a field for types say an integer > > > > field > > > > > and when youcome across a new type you need just increment your > > integer > > > > > count by one... > > > > > > ie: > > > > > > STRING = 1 > > > > > INT = 2 > > > > > CHAR = 3 > > > > > TYPE_CHOICES = ( > > > > > (STRING, 'string'), > > > > > (INT, 'integer'), > > > > > (CHAR, 'character'), > > > > > ) > > > > > > Then add the field to your model: > > > > > data_type = models.IntegerField(choices=TYPE_CHOICES) > > > > > > Then in your admin view there will be filds the user needs to fill > > 'in' > > > > > > name > > > > > value > > > > > type > > > > > > I understand your lack of depth of information on the topic (this > > > > solution > > > > > isn't making me any happier than it's making you! :) > > > > > > I'm sure there is a slicker solution out there, I'm just trying to > > give > > > > you > > > > > something to think about and hopfully come up with something more > > elegant > > > > > that fits your business needs! :) > > > > > > n > > > > > > On Mon, Sep 13, 2010 at 4:37 AM, pixelcowboy < > > pixelcowbo...@gmail.com > > > > >wrote: > > > > > > > Of course! But what about different field types? How would you pair > > > > > > the variable name with the variable value for multiple types in the > > > > > > same class? Or would you need a separate model class for each > > > > > > different value type? example integers, strings, etc > > > > > > > Sorry for the lack of information, but my application structure > > > > > > requires that users are able to add arbitrary variables to a > > > > > > model.Thanks for your help! > > > > > > > On Sep 12, 8:24 pm, "nick.l...@gmail.com" <nick.l...@gmail.com> > > wrote: > > > > > > > without knowing any context of what you want...or are going to > > do...I > > > > > > would > > > > > > > say create a similar model and run with it: > > > > > > > > class UserVariables(models.Model): > > > > > > > variable_name = models.CharField(max_length=100) > > > > > > > variable_value = models.TextField() > > > > > > > > THOUGH like I said, I have no idea what you're trying to do or > > > > why...but > > > > > > > this is by far the simplest way :) > > > > > > > > n > > > > > > > > On Sun, Sep 12, 2010 at 9:42 PM, pixelcowboy < > > > > pixelcowbo...@gmail.com > > > > > > >wrote: > > > > > > > > > What would be the best way to enable a user to create arbitrary > > > > > > > > variables through the django admin? This could be either > > numbers, > > > > text > > > > > > > > or paths to files. Thanks for your advice! > > > > > > > > > -- > > > > > > > > You received this message because you are subscribed to the > > Google > > > > > > Groups > > > > > > > > "Django users" group. > > > > > > > > To post to this group, send email to > > django-users@googlegroups.com > > > > . > > > > > > > > To unsubscribe from this group, send email to > > > > > > > > django-users+unsubscr...@googlegroups.com<django-users%2bunsubscr...@google > > > > > > > > groups.com> > > <django-users%2bunsubscr...@google groups.com> > > > > <django-users%2bunsubscr...@google groups.com> > > > > > > <django-users%2bunsubscr...@google groups.com> > > > > > > > > . > > > > > > > > For more options, visit this group at > > > > > > > >http://groups.google.com/group/django-users?hl=en. > > > > > > > > -- > > > > > > > Guadajuko! Vamos a correr! > > > > > > > -"Cool! we are going to run!" > > > > > > > -- > > > > > > You received this message because you are subscribed to the Google > > > > Groups > > > > > > "Django users" group. > > > > > > To post to this group, send email to django-users@googlegroups.com > > . > > > > > > To unsubscribe from this group, send email to > > > > > > django-users+unsubscr...@googlegroups.com<django-users%2bunsubscr...@google > > > > > > groups.com> > > <django-users%2bunsubscr...@google groups.com> > > > > <django-users%2bunsubscr...@google groups.com> > > > > > > . > > > > > > For more options, visit this group at > > > > > >http://groups.google.com/group/django-users?hl=en. > > > > > > -- > > > > > Guadajuko! Vamos a correr! > > > > > -"Cool! we are going to run!" > > > > > -- > > > > You received this message because you are subscribed to the Google > > Groups > > > > "Django users" group. > > > > To post to this group, send email to django-us...@googlegroups.com. > > > > To unsubscribe from this group, send email to > > > > django-users+unsubscr...@googlegroups.com<django-users%2bunsubscr...@google > > > > groups.com> > > <django-users%2bunsubscr...@google groups.com> > > > > . > > > > For more options, visit this group at > > > >http://groups.google.com/group/django-users?hl=en. > > > > -- > > > Guadajuko! Vamos a correr! > > > -"Cool! we are going to run!" > > > -- > > You received this message because you are subscribed to the Google Groups > > "Django users" group. > > To post to this group, send email to django-us...@googlegroups.com. > > To unsubscribe from this group, send email to > > django-users+unsubscr...@googlegroups.com<django-users%2bunsubscr...@google > > groups.com> > > . > > For more options, visit this group at > >http://groups.google.com/group/django-users?hl=en. > > -- > Guadajuko! Vamos a correr! > -"Cool! we are going to run!"
-- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
