Re: dbsettings, and user configurable app settings

This was the initial question: On Feb 26, 8:11 am, Jared Forsyth wrote: > I have been looking around for a way of managing user-configurable > application settings In this discussion we must IMHO different between "low-level settings", "admin configurable settings" and "user configurable settin

Re: dbsettings, and user configurable app settings

On Wed, Mar 10, 2010 at 6:31 PM, Matt Boersma wrote: > On Wed, Mar 10, 2010 at 7:51 AM, Brian Rosner wrote: >> >> On Mar 10, 2010, at 7:16 AM, Joan Miller wrote: >> >>> It's a disaster from the maintenance view point. If it were not so, >>> then people would not be proposing to refactor the setti

Re: dbsettings, and user configurable app settings

Feb 26, 7:11 am, Jared Forsyth wrote: > I have been looking around for a way of managing user-configurable > application settings, and the only solution I have found is dbsettings, > which looks like it hasn't been touched in 3 years. > So, I would like to know: is dbsettings dead? Or

Re: dbsettings, and user configurable app settings

On Wed, Mar 10, 2010 at 7:51 AM, Brian Rosner wrote: > > On Mar 10, 2010, at 7:16 AM, Joan Miller wrote: > >> It's a disaster from the maintenance view point. If it were not so, >> then people would not be proposing to refactor the settings as has >> been made in Pinax, or from multiple posts so m

Re: dbsettings, and user configurable app settings

As far as a solution that "magically solves everyone's problem nicely", that's what django-appsettingsis trying to be :). It handles quite nicely the issues of scoping and maintainability that you discussed, organizing everything in a pythonic manner.

Re: dbsettings, and user configurable app settings

On Mar 10, 2010, at 7:16 AM, Joan Miller wrote: > It's a disaster from the maintenance view point. If it were not so, > then people would not be proposing to refactor the settings as has > been made in Pinax, or from multiple posts so many times. Like I mentioned in the post you made to the pina

Re: dbsettings, and user configurable app settings

On Wed, Mar 10, 2010 at 10:16 PM, Joan Miller wrote: > It's a disaster from the maintenance view point. If it were not so, > then people would not be proposing to refactor the settings as has > been made in Pinax, or from multiple posts so many times. > > This is nothing new. Many people dislikes

Re: dbsettings, and user configurable app settings

1) In implementation, how is a YAML configuration file any different than the Java/XML example that you offered? Syntactical differences between XML and YAML aside, both systems define settings in markup languages (which by definition have minimal capability for logic) that are eventually parsed (b

Re: dbsettings, and user configurable app settings

I really don't see how your YAML file is any more maintainable than Django's settings.py approach? If anything, I would argue that it is less maintainable, as you would have to maintain not only your YAML files moving forward, but also the code which transposes it into a settings.py. On Wed, Mar 1

Re: dbsettings, and user configurable app settings

It's a disaster from the maintenance view point. If it were not so, then people would not be proposing to refactor the settings as has been made in Pinax, or from multiple posts so many times. This is nothing new. Many people dislikes that kind of configuration, of the same that many people hates

Re: dbsettings, and user configurable app settings

On Wed, Mar 10, 2010 at 6:18 PM, Joan Miller wrote: > Whatever configuration system using variables of a language is a > disaster and it's going not maintainable as has been showed in Django. That's a pretty wild assertion to make without any evidence, and it's completely contrary to my personal

Re: dbsettings, and user configurable app settings

7:11, Jared Forsyth wrote: > I have been looking around for a way of managing user-configurable > application settings, and the only solution I have found is dbsettings, > which looks like it hasn't been touched in 3 years. > So, I would like to know: is dbsettings dead? Or is th

Re: dbsettings, and user configurable app settings

a) is probably what i would personally leave in settings.py, or in a conf/settings.py MEDIA_URL, projectname, etc... a bit behind on a project, ill take a look at appsettings this weekend :) On Mar 7, 12:03 am, Jared Forsyth wrote: > It seems like the best place for "project settings"(a) would b

Re: dbsettings, and user configurable app settings

It seems like the best place for "project settings"(a) would be applicable is through some ./manage.py command, perhaps "installapps" or something along those lines. This would probably be the place to do database modifications between versions. (b) could be served by a "readonly" flag in the setti

Re: dbsettings, and user configurable app settings

Sorry Carl, I agree with pretty much everything you said. I was talking a bit too abstract and I had misunderstood. I will concentrate on a few use cases: with a app level settings.py file i didnt really refer to automatic import, as that can easily be done now. I had more like a admin.register in

Re: dbsettings, and user configurable app settings

I think there are some settings which are for the developer, and some which are appropriate for an admin user, who is not necessarily the developer, to have access to. In addition, there are some settings which should be modifiable without necessitating a server restart. There is value in having co

Re: dbsettings, and user configurable app settings

I don't think that settings are for users. They are for the developer. The type of settings you are looking for really should be set up as part of your application. Users can't choose a DB password or your server's time zone, or which apps are installed. If you're creating an SAAS you'd be better t

Re: dbsettings, and user configurable app settings

For PyLucid i have made http://code.google.com/p/django-dbpreferences/ """ A django app defines a form with initial values. The form cleaned data dict would be stored serialized into the database. The app can easy get the current preference dict and the user can easy edit the values in the django

Re: dbsettings, and user configurable app settings

behavior for (AFAICS) no gain. I've certainly > had the need for something like dbsettings or livesettings, though > I've often addressed it with a separate app/model rather than trying > to shoehorn django.conf.settings into a role it wasn't intended for. I > also agree th

Re: dbsettings, and user configurable app settings

e helpful to focus on specific problems and possible solutions. My critique was specifically of the suggestion you made for an automatic import of app-level settings.py, which introduces magical behavior for (AFAICS) no gain. I've certainly had the need for something like dbsettings or lives

Re: dbsettings, and user configurable app settings

> I've never understood the desire for more magical behavior here. My > apps have a settings.py that imports django.conf.settings and provides > any necessary defaults for unset settings; the rest of my app imports > from there. Works great, easy to look and see what settings my app > consumes and

Re: dbsettings, and user configurable app settings

On Feb 27, 1:53 pm, stuff4ash wrote: > b) easy way to register, override, configurations for apps. > a settings.py in an app folder that is "magically" loaded the same way > other things are would suffice, but there has to be a way to: I've never understood the desire for more magical behavior

Re: dbsettings, and user configurable app settings

We use something called livesettings in Satchmo. Bruce has published the code on bitbucket so it can be used outside of Satchmo. I believe at one point it was a fork of dbsettings but I may be wrong on that account. Check it out here - http://bitbucket.org/bkroeze/django-livesettings/overview

Re: dbsettings, and user configurable app settings

ones have been deprecated... d) as mingus kevin points out, we need a conventional way of registering settings that are to be accessible via the admin and do not require an apache restart... damn, battery down, and stil want to write a new post. :D On Feb 26, 7:53 pm, Jared Forsyth wrote:

Re: dbsettings, and user configurable app settings

If you look at dbsettings (which again, might be dead - i don't know) it solves a lot of those problems; settings are tied into the "sites" module, and are presented to the user in a very friendly way. The problem of db migration is still there, but I can envision an import/ex

Re: dbsettings, and user configurable app settings

n looking around for a way of managing user-configurable > application settings, and the only solution I have found is dbsettings, > which looks like it hasn't been touched in 3 years. > So, I would like to know: is dbsettings dead? Or is there a different > generally accepted me

dbsettings, and user configurable app settings

I have been looking around for a way of managing user-configurable application settings, and the only solution I have found is dbsettings, which looks like it hasn't been touched in 3 years. So, I would like to know: is dbsettings dead? Or is there a different generally accepted method for h

dbsettings and #2438

During the sprint, Malcolm informed me about #2438, and that it was the reason some models were disappearing from the admin when using dbsettings. I've spent some time trying to figure it out, since I had a setup that was exhibiting the problem, but so far I haven't come up with anythin

An update on dbsettings

I just thought I'd give a quick heads-up to those few of you who are paying attention to my dbsettings project[1]. I've finally gotten a comprehensive test suite written and checked in. So, barring any major features that are request or bugs reported, it's now as complete as i

dbsettings update

Thanks to suggestions from this list, I made several updates to dbsettings[1] so that it uses Django's existing cache framework rather than trying to invent an alternative. In my limited tests, it seems to retain existing funcitonality, but I don't have a working installation of mod

Re: dbsettings

On 6/5/07, Ilya Semenov <[EMAIL PROTECTED]> wrote: > I run into the problem that the module doesn't seem to work well with > Apache+mod_python. The new values are actually saved to the db, but > not used until I restart Apache (neither as class members nor in the > admin settings panel). I think t

Re: dbsettings

Marty, Thanks for your work! I run into the problem that the module doesn't seem to work well with Apache+mod_python. The new values are actually saved to the db, but not used until I restart Apache (neither as class members nor in the admin settings panel). I think that's because of the per-pro

dbsettings

There's a new episode in the contiuing saga of django-values! Per Jacob's recent dictatorial decision (and given a lack of opposition thus far), I've renamed it to dbsettings, though the URL remains unchanged.[1] Other notable changes in this latest update: * Removed assumptions