On 5/31/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > Every single piece of code that caches anything based on having read > something from settings would then have to query settings every time > (and recompute whatever it cached). There is code that relies on the > current behaviour and the assumption that settings will never change > once you access them makes this a useful pattern. Having to change this > to "some settings will change" means there is always some flipping back > and forth checking which set of assumptions you are operating under when > developing. Feels error prone. I'm pretty stupid, so I'm a big fan of > things behaving as expected with consistency.
I'm starting to see this. In my testing there is an inconsistency from time to time in the results and/or the caching. > An alternative approach to a solution for a problem that requires this > question (can I change a setting?) is to work out whether it makes sense > to move the "feature" away from being a setting (since it's no longer a > user-configured setting, but the user setting can still act as a hint). Agreed. Hence the reason I try to make sure to provide the full story as I see it so that a little Root Cause Analysis can be performed. > > I would like to see something as > > simple as adding a middleware to support dynamic Sites > > That's the problem that might be interesting to solve! All the stuff > about settings changes flows from your particular solution. Don't > misunderstand me here: I'm not trying to dismiss on your solution -- I > just want to distinguish between real barriers on the way to the goal > and barriers imposed by other decisions. I'm not married to my solution and opening this discussion was precisely what I saw as finding a much better solution. I realize that I'm not an everyday Django coder and I've very rarely used Django's source as anything other than a reference when I have a question as a consumer of the framework, so I certainly realize that my first instincts might not be the best. > Two alternatives spring to mind. Neither of these are fully thought-out > yet, but let's see how they sound: > > (1) We introduce a formal thread-local settings feature as well. > (2) We come up a with a more dynamic site object. (1) sounds more generally useful. If you've been thinking about it for some time and it looks like it might solve/alleviate some other things along the line it might be the better approach. (2) does seem like a lot of work for a single (contrib) application, but having fewer checks against SITE_ID could be a nice benefit (reducing some over-reliance on django.conf.settings). > I realise your original question was motivated by not wishing to make > any changes to the code at all and instead *just completely violate one > of our most sacred, honorable and historic assumptions* (alright, you > may not have viewed that way). I just thought I might have found a simple minimal solution in a few lines of code. I don't mind realizing that my solution created more side problems than it was worth. It was a learning experience... I had assumed that the functionality didn't exist because few had thought about it and fewer used the sites application rather than roll their own thing. Now I know that I was wrong and the problem is a bit bigger than I first thought it was. I personally think that Dynamic Sites support of one form or another should be provided sometime by 1.0, just because I don't think django.contrib.sites is complete without. It's the sort of functionality a new person might assume it contains... It took me a while to get used to the idea that sites didn't bother to check the address at all and simply took SITE_ID for face value. > I'd like to solve the problem in a slightly more intrusive way, though, > just because I like viewing the settings module as a static thing. Which > conflicts massively with my "I don't like random backwards incompat > changes" inner child, but that's something I have to work out. I have no problem for seeing it solved the intrusive way if that's what makes the most sense for the problem set. Hopefully something like this can even be done without breaking too many backward compatibility eggs... -- --Max Battcher-- http://www.worldmaker.net/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
