Re: Suggestion: Better way to extend user table
> This is actually pretty much exactly what I had before, it was horribly
> slow! And somehow not nice since you always have to wrap the users
> around and can't just use request.user...
When you say that it was "horribly slow," does that mean you weren't
using caching to skip the DB, or was it slow in some other way?
As far as not using request.user, that means your current solution
isn't James' solution. With the merged_user middleware, request.user
does exactly what you'd expect. Using that or a similar middleware
with some basic caching, it seems you can get exactly what you're
looking for already (and with no monkeypatching).
-Wes
On Aug 17, 2:53 pm, Jonas Obrist wrote:
> James Bennett wrote:
> > On Mon, Aug 17, 2009 at 10:57 AM, Jonas Obrist wrote:
>
> >> Thanks for your opinion on this, didn't know django had this feature
> >> once. But I just can't get it out of my head that there's gotta be a
> >> better solution than this profile-extending... It just seems ridiculous
> >> to me that half of the user properties is in one table and the other
> >> half in the other one. And I don't like the template variables looking
> >> like {{ request.user.user.someproperty }} and {{
> >> request.user.some_other_property }}. Especially since my designer isn't
> >> a coder and got all confused over which was where.
>
> >> So any thoughts on implementing my idea in a better way? To me (at least
> >> in my code) my version seems pretty elegant... And unless I find a
> >> better solution I'll continue using it for my own projects.
>
> > Well, now that you've described the actual problem you're trying to
> > solve, here's my five-minutes'-worth-of-coding solution:
>
> > from django.contrib.auth.models import AnonymousUser
> > from django.core.context_processors import PermWrapper
>
> > class MergedUser(object):
> > def __init__(self, user):
> > self.user = user
> > self.profile = self.user.get_profile()
>
> > def __getattr(self, name):
> > if hasattr(self.user, name):
> > return getattr(self.user, name)
> > else:
> > return getattr(self.profile, name)
>
> > def merged_user(request):
> > if hasattr(request, 'user'):
> > user = MergedUser(request.user)
> > else:
> > user = AnonymousUser()
> > return {
> > 'user': user,
> > 'messages': user.get_and_delete_messages(),
> > 'perms': PermWrapper(user),
> > }
>
> > Drop this somewhere, disable the auth context processor and enable the
> > 'merged_user' processor above. Authenticated users will appear in
> > template context as an object which transparently passes attribute
> > access to either the User object or the related profile object,
> > depending on where the required attribute actually exists.
>
> This is actually pretty much exactly what I had before, it was horribly
> slow! And somehow not nice since you always have to wrap the users
> around and can't just use request.user...
--~--~-~--~~~---~--~~
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
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: media -> admin_media Prefix Change
> Given that both MEDIA_PREFIX and ADMIN_MEDIA_PREFIX are easily set in > settings.py, I can't see the issue. Having sensible default settings is a worthy goal for a lot of reasons. > My standard setup sets > ADMIN_MEDIA_PREFIX to /admin-media/ As this exemplifies, having something other than /media/ for the ADMIN_MEDIA_PREFIX makes a lot of sense. It takes someone new to Django quite a while to form an opinion on that, though. if / admin_media/ really is a better default, then it's not worth discounting simply because it's possible to change the value yourself. -wes On Sep 11, 11:51 am, Brett Parker wrote: > On 11 Sep 06:33, drozzy wrote: > > > > > Reference: > >http://docs.djangoproject.com/en/dev/howto/static-files/#how-to-do-it > > > I propose we change the admin's media prefix from "media" to > > "admin_media". > > When I was just starting out with Django, this was a major problem, as > > I could not figure out why my static media did not display correctly. > > > Admin should stay out of the way as much as possible, and it's media > > is currently very tightly bound with django. But that is another > > discussion... > > Given that both MEDIA_PREFIX and ADMIN_MEDIA_PREFIX are easily set in > settings.py, I can't see the issue. My standard setup sets > ADMIN_MEDIA_PREFIX to /admin-media/, the runserver will happily use this > setting, and my live environment knows what to serve for that too. Can't > see why you'd need to change the django default... > > -- > Brett Parker --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Looking for a project
django-schedule is a backend and frontend, just not a CalDAV backend. The app is definitely more oriented to being stand-alone right now though, but that's more because of where work has been done than a design choice I think. There's been some work lately around adding a slicker UI (JQuery Fullcalendar) for viewing calendars and it would be wonderful for someone to add CalDAV support. If you're interested in CalDAV and the constraints that Russell outlined don't make something else more attractive, then CalDAV for django-schedule seems like a great project. It's up on github, so fork and hack :) -Wes On Sep 20, 7:31 pm, Daniel Watkins wrote: > On Sun, 2009-09-20 at 16:26 -0700, Richard wrote: > > django-schedule is under active developement and is a great > > calendaring app. > > Looking at django-schedule's website, it only seems to do the front-end > part of what I was suggesting. Is my understanding correct? > > Dan --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Patch: adding a msg parameter to assertContains and similar methods in the test client
I haven't looked at the proposed patch, but I'd like very much to be able to add a ``msg`` argument to assertContains and assertRedirects at least. The point of the msg argument in normal asserts is to give the person running the tests a quick, high-level indication of what went wrong or what was supposed to happen. I think this holds just as strongly to the django TestCase asserts as they do to normal UnitTest asserts. For example: > self.assertTrue(Foo.objects.count(), 7) Would fail and I would know that some count didn't equal 7. The actual problem of course was that it was supposed to be 7 because in the line above it I called a function that was supposed to delete one of my Foo's. > self.assertTrue(Foo.objects.count(), 7, msg="Calling removeDuplicates() > should have removed the duplicate Foo") When I see that error message in the client, I know I must have busted removeDuplicates() somehow and it gives me very useful information before I even step in to the test code. We've all used this I'm sure. The same things that makes the msg nice in that case, is doubly nice in say, assertContains: > self.assertContains(response, '', 7) This might fail for the same reason as above, because I clicked the "remove duplicates" button and the next page still showed the same list of "Foo" objects. Even worse, it's a bit harder to figure out what is even supposed to represent. > self.assertContains(response, '', 7, msg="Submitting the > remove duplicates form didn't remove the duplicate foo") This gives me a nice little summary. I know that there were more foo's displayed on the page than there should have been. > Looking at the ticket, it appears that your actual problem is that > some of the messages raised by Django aren't meaningful enough. If > this is the case, then the solution is to fix the actual error message > in question. Feel free to suggest specific improvements. For my case, improving Django error messages where they can be improved would obviously be good, but it wouldn't address why I'd like a message argument. The stack trace and error message is great when actually trying to fix whatever the problem was, but the message argument gives the application developer the ability to provide information specific to what the assert was actually supposed to be testing. That message is useful for alleviating the need for the person running the test to get in to the code to see what really went wrong. Sometimes, I just need to know that the printed version didn't have all of the links or that adding a foo didn't actually display a foo. If a message argument can be added without breaking any backwards compatibility and especially if it can be added with minimal changes (the underlying asserts already support a message), is there a reason not to support the standard UnitTest assert's message ability? Thanks -Wes On Oct 7, 8:48 pm, Russell Keith-Magee wrote: > On Wed, Oct 7, 2009 at 11:15 PM, Christian Oudard > > > > > > wrote: > > > I wanted to get some feedback from the mailing list about a patch I > > wrote. There are two approaches I tried, and attached them both to > > this ticket: > > >http://code.djangoproject.com/ticket/10314 > > > Quick explanation: Basically, the assertFoo methods in the python > > stdlib test case class accept a "msg" parameter, to customize the > > failure message given. The methods like this in django do not accept > > this parameter to pass it along. I think they should, and I gave an > > example in the ticket. > > > The ticket was originally closed as invalid by sebleier. The reason he > > gave is that the django assertFoo methods can fail in a variety of > > ways, whereas the python assert methods can only fail in one way. > > While this is an important thing to keep in mind when writing test > > cases, I still think that it is useful to be able to customize the > > error message, so I wrote the patch. > > I'm inclined to agree with sebleier here - for the simple reason that > your patch won't work. If your patch had a comprehensive test suite, > you would discover this very quickly. > > Consider your patch2 on the ticket, and a call to assertFormError(). > > Line 117 - 5 arguments, (field, form, i, err, field_errors) > Line 124 - 3 arguments, (form, i, field) > Line 135 - 4 arguments, (form, i, err, non_field_errors) > Line 140 - 1 argument, (form) > > There is no way for you to provide a msg argument that will meet all > these argument lists. One solution might be to use keyword > substitution rather than positional substitution (i.e., format errors > like "There was an error on %(form)s"), but that doesn't address the > problem of having a single error message string that is meaningful > across 4 different uses. > > I've picked on assertFormError here, but similar arguments apply to > the other Django assertions. > > Looking more philosophically - there is a significant difference > between assertTrue and assertFormError. assertTrue is a general > logical pri
Re: Patch: adding a msg parameter to assertContains and similar methods in the test client
I love the prefix idea. Seems like the best of both worlds. I also
agree that changing the name to either ``prefix`` or ``msg_prefix``
would probably be preferable, to explicitly indicate that the behavior
is different than the standard msg argument.
This would certainly satisfy my use case.
-wes
On Oct 11, 4:52 pm, Sean Bleier wrote:
> > > def assertFormError(self, response, form, field, errors, msg=None):
> > > ...
> > > self.fail(msg or "The field '%s' on form '%s' in context %d"
> > > " contains no errors" % (field, form, i))
>
> > would become:
>
> > prefix = msg and "%s: " % msg or ""
> > self.fail("%sThe field '%s' on form '%s' in context %d"
> > " contains no errors" % (prefix, field, form, i))
>
> > This preserves the best of both worlds - a rich failure message, plus
> > the ability to add user-specific context to help identify the source
> > of the problem in the test suite. This does differ from the behavior
> > of the assert* functions in the standard library, but hopefully in a
> > way that makes sense under the circumstances. Opinions?
>
> > Yours,
> > Russ Magee %-)
>
> I like Russ's prefix idea. I believe Christian's concern is that the
> django's error messages do not give enough context for the programmer when
> debuging. Adding the prefix allows programmers to add that context without
> blindly overridding the error message that django throws.
>
> Karen is right about the name of msg if it is going to serve as a prefix to
> the msg given to Python's assert* methods. Something like msg_prefix or
> prefix would be more appropriate IMO
>
> Using Christian's example, I might change it to:
>
> class TemplateTestCase(ClientTestCase):
> def testTemplateError(self):
> urls = [
> '/',
> '/home/',
> '/admin/',
> # etcetera ...
> ]
> for url in urls:
> response = self.client.get(url, follow=True)
> self.assertNotContains(
> response,
> settings.TEMPLATE_STRING_IF_INVALID,
> msg_prefix='Error in url %s' % url)
>
> This way for the two cases in which assertNotContains can fail, you can have
> errors messages like:
> "Error in url /home/: Couldn't retrieve page: Response code was 404
> (expected 200)"
> or
> "Error in url /home/: Response should not contain
> 'TEMPLATE_STRING_IF_INVALID"
>
> --Sean
--~--~-~--~~~---~--~~
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
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: Decision for ticket #6362 - Remove blank spaces with strip when validating the data
The common use case on my projects is definitely to trim whitespace. The autostrip decorator I found on djangosnippets (http:// www.djangosnippets.org/snippets/956/) is pretty awesome, but I'd prefer not to import that into every project and it would be nice to not call: > MyForm = autostrip(MyForm) on practically every form I have with a CharField What's the common use case for allowing a user to add a space at the end of a datetime field or email field, or pretty much any text field? It seems like that those situations are in the minority and the strip argument would make things simpler for the simple case while remaining backwards compatible. -Wes On Oct 10, 5:47 pm, Taylor Marshall wrote: > I'd love to see this change get put in. I think the most common case > for forms is to trim whitespace, not the other way around. I'd rather > have the extra work come in for the rare case (when you wanted to > preserve leading/trailing spaces). > > -Taylor > > On Oct 10, 11:37 am, Barry Pederson wrote: > > > > > On May 13, 2:56 am, Russell Keith-Magee > > wrote: > > >On Wed, May 13, 2009 at 7:48 AM, thebitguru wrote: > > > >> Hi, > > > >> What do we need to make a decision for ticket 6362 (http:// > > >> code.djangoproject.com/ticket/6362)? > > > > We need to wait until we're not trying to get v1.1 out the door. > > > > We are well past the feature deadline for v1.1; the focus of the > > > community is on fixing bugs and finalizing the v1.1 release. Once that > > > happens, we will be in a position to concentrate on design decisions > > > again. > > > Now that we're talking about 1.2, I hope this can be looked at before > > the door closes again. Either this or the simpler patch from > > > http://code.djangoproject.com/ticket/4960 > > > Having extraneous spaces in user input is quite annoying and can cause a > > fair amount of trouble. Yes, you could write custom validation for > > every single one of your forms, but a global fix is potentially pretty > > trivial. > > > Some other tickets complaining about the same problem with specific > > field types are: > > > http://code.djangoproject.com/ticket/5714 > > http://code.djangoproject.com/ticket/11907 > > > Barry --~--~-~--~~~---~--~~ 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 django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: dbsettings, and user configurable app settings
I'd love to see a better way of managing settings in the core of django. It's a real pain point sometimes for writing and using pluggable applications and there's a wide range of ways that application developers try to tackle it. Some have basically no settings, some plan on users reading the documentation and defining all required settings, some have a way of using defaults that can be overridden and some have hacked together ways of using the database for some settings (I think ReviewBoard does something like this, or did). The problem I see is that the *best* way hasn't really bubbled to the surface as far as I can tell. Kind of like how database migrations are a hard problem, settings management seems kind of tricky. Are there things stopping someone from making a really good app for managing settings and letting that bubble up to the de facto solution like with South? If there are, maybe removing those things would be a good target before trying to build the actual solution in contrib. Of course, this is probably not the best time for discussing this since everyone is trying to get 1.2 out the door, but I'd love to see this area improved down the road. My specific pain points: * With a given app, it's a crapshoot to find where they define their internal settings (some use app/conf/settings.py, some app/conf/ default.py, some app/default.py etc) * It's hard to tweak settings on deployment for different environments. Using a settings_local.py that gets included is a workable solution, but it requires you to maintain a monolithic file. Something like the conf.d/*.conf debian style of configuration might Pinax is having a similar discussion right now. Maybe something will come out of that project that can be applied/adapted to some later version of django. That might be a place to apply some development if anyone is interested in working towards better settings management. http://groups.google.com/group/pinax-core-dev/browse_thread/thread/d9401468ea3c8edf -Wes On Feb 26, 2: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 is there a different > generally accepted method for having user-friendly app settings? (e.g. don't > require code modification) > > I think that this idea is pretty essential to django's ease of use; there > are many applications which have (or should have) settings which only effect > UI or minor behavioral issues, and shouldn't require a server restart to > effect (and imo shouldn't require server write access). It seems that the > most viable solution would be to have a database managed settings system (in > the form of a .contrib module) which would manage this. It also seems that > having such an infrastructure in place would really encourage app > maintainers to have more settings, thereby making the apps even more > portable. > > Any thoughts? > > Thanks, > Jared -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
