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+unsubscribe@googlegroups.com<django-users%2Bunsubscribe@google groups.com>
> > <django-users%2Bunsubscribe@google groups.com>
> > > > <django-users%2Bunsubscribe@google groups.com>
> > > > > > <django-users%2Bunsubscribe@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+unsubscribe@googlegroups.com<django-users%2Bunsubscribe@google groups.com>
> > <django-users%2Bunsubscribe@google groups.com>
> > > > <django-users%2Bunsubscribe@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+unsubscribe@googlegroups.com<django-users%2Bunsubscribe@google groups.com>
> > <django-users%2Bunsubscribe@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+unsubscribe@googlegroups.com<django-users%2Bunsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
No comments:
Post a Comment