Re: Admin Site appending letter "s" to end of each model\table name
Dnia 2011-09-10, sob o godzinie 14:50 -0700, Christian Ramsey pisze: > def __unicode__(self) > return 'Name you'd like without the s' > for each model and this will be used instead. That's obviously not what he's after. > On 10 Sep 2011, at 14:40, Gillwill wrote: > >Apparently the Django default is to append the letter "s" to the end > > of the model name for each listed under a given application on the > > Site Administration page. (It does this in the tutorial sample site > > as > > well - e.g. naming "poll" "polls", etc...) > > > > Is there any way to get rid of that? First, why is that a problem? If you're using localized model names and that's where that doesn't fit - you shouldn't, really. You should use english names for the models and use the i18n infrastructure [1] to translate the names properly. Either way [2] and [3] is what you need. [1] https://docs.djangoproject.com/en/1.3/howto/i18n/ [2] https://docs.djangoproject.com/en/1.3/ref/models/options/#verbose-name [3] https://docs.djangoproject.com/en/1.3/ref/models/options/#verbose-name-plural Cheers, -- Michał (Saviq) Sawicz signature.asc Description: This is a digitally signed message part
Re: Constructing / rendering a complex
Dnia 2011-08-03, śro o godzinie 10:34 +1000, Sam Walters pisze: > Hi i dont see what is complex about this. --8<-- > The view 'rendering' as much as possible. So i assume you would rather > have an initial template rendered. then perhaps have views that > deliver data via JSON or something? AJAX+JSON No, I mean I want to have the view only prepare the data, not describe its visual properties like col/rowspan. > I cant see why it would be impossible to change. Use javascript to > change the table col and rowspans. (why do visual formatting work on > the serverside if you can do it clientside) > at the very least you can have style="display:None" and variious other > CSS rules to help with any dynamic changes to the table. I'm not going into JS at all at the moment. I'd like the table to be rendered static in the template. > I dont quite understand this one. If you are comparing data > server-side then submitting data via a form would be recommended. > Where is the data being changed that requires the comparison anyway? I mean comparing forloop.counters with column/row/header/whatnot count and rendering differently. No forms involved here, just a dynamic dataset. > use multiple classes eg jse a javascript library to > add remove classes select child elements of the DOM im sure the > information doesnt have to be partitioned down the a super fine level > of granularity requiring individual id's for every element does it? Yes I'll probably try and run with that approach, I'll prepare the whole grid within the view, and then "merge" cells that I need spanning in the template. > What javascript library do you use? jquery, prototype, dojo etc all > good options to simplify manipulation of DOM elements. Yes, I use jQuery, but as stated before I need to create the table in HTML without client-side tweaks. Thanks for the comments, keep 'em coming ;) -- Michał (Saviq) Sawicz signature.asc Description: This is a digitally signed message part
Constructing / rendering a complex
Hi all, I'd like to pick your brainz about how would you approach constructing and rendering a complex table with headers, row/colspanning cells in a most clean way that rids the view of rendering as much as possible. Here's roughly what I'm after (incomplete, but you should see what I mean): http://imageshack.us/f/845/zrzutekranuqv.png/ There are three approaches I can think of: 1. Construct a complete grid in the view, along with row/colspans that I would simply iterate over and render in the template, but that would make it virtually impossible to change the appearance. 2. Count the cells / rows and compare them with data from the view to decide on how that particular cell should behave, but that makes the template a nightmare. 3. ID all the cells and change the attributes accordingly, but for rowspanning cells I wouldn't know in the consecutive rows that there in fact was a cell and I might want to repeat it. Maybe I could fill in the complete grid but make the ones that get spanned ignorable in the template through a class. I'll take all thoughts :) -- Michał (Saviq) Sawicz signature.asc Description: This is a digitally signed message part
Re: Class-Based Generic Views (CreateView) - field exclusions and defaults
Dnia 2011-07-15, pią o godzinie 16:07 +0530, Kenneth Gonsalves pisze: > caveat - I have never used generic views, class based or otherwise, > but > I was under the impression that if one wants customised forms or > views, > generic is not the way to go. Why not? The model edit views use the ModelFormMixin, which has a get_form_class that can be overriden [1] to taste. You can simply get the form from super().get_form_class and put it through modelform_factory [2] again to only get the form for the fields you want. The classy generic views are really flexible like that. Sadly docs aren't that great, so reading the code is probably best to get the hang of it. [1] https://code.djangoproject.com/browser/django/trunk/django/views/generic/edit.py#L66 [2] https://code.djangoproject.com/browser/django/trunk/django/forms/models.py#L370 Cheers -- Michał (Saviq) Sawicz signature.asc Description: This is a digitally signed message part
Re: Extending User model with Inheritance - Attribute Error
Dnia 2011-07-11, pon o godzinie 09:48 -0700, Brent pisze: > How do I use a foreign key, though? In other words, how do I tell my > code to look at UserProfile rather than just user? https://docs.djangoproject.com/en/1.3/topics/auth/#storing-additional-information-about-users -- Michał (Saviq) Sawicz signature.asc Description: This is a digitally signed message part
Re: Django admin - how to hide some fields in User edit?
Dnia 2011-07-06, śro o godzinie 14:40 -0700, galgal pisze:
> Full code:
> class UserProfileAdmin(UserAdmin):
> inlines = [UserProfileInline,]
> list_filter = ('userprofile__type','userprofile__cities',)
> search_fields = ['userprofile__type', 'username',
> 'userprofile__cities__name', 'email', 'first_name', 'last_name',]
Use tuples instead of lists, they're cheaper. And lists don't require
the trailing comma.
--8<--
> def get_fieldsets(self, request, obj=None):
> if obj:
> if request.user.id == 1:
> return self.declared_fieldsets
> else:
> if obj.get_profile().type==1:
> return (
> (None, {'fields': ('username', 'password')}),
> (_('Personal info'), {'fields': ('first_name',
> 'last_name', 'email')}),
> (_('Important dates'), {'fields':
> ('last_login', 'date_joined')}),
> )
> else:
> return (
> (None, {'fields': ('username', 'password')}),
> (_('Personal info'), {'fields': ('first_name',
> 'last_name', 'email')}),
> (_('Permissions'), {'fields': ('is_active',
> 'is_staff', 'user_permissions')}),
> (_('Important dates'), {'fields':
> ('last_login', 'date_joined')}),
> )
> else:
> return self.add_fieldsets
Why not using super().get_fieldsets() when there is no object or your
user isn't 1?
> def get_form(self, request, obj=None, **kwargs):
> if obj:
> if obj.get_profile().type==1:
> self.exclude = ('user_permissions',)
> return super(UserProfileAdmin, self).get_form(request,
> obj=None, **kwargs)
Should be obj=obj, not obj=None, you're always getting a new user form.
--
Michał (Saviq) Sawicz
signature.asc
Description: This is a digitally signed message part
Re: Django admin - how to hide some fields in User edit?
Dnia 2011-07-06, śro o godzinie 13:16 -0700, galgal pisze:
> Any idea how to overwrite it dynamically?
> def get_form(self, request, obj=None, **kwargs):
> self.exclude = ('user_permissions',)
> return super(UserProfileAdmin, self).get_form(request,
> obj=None, **kwargs)
> Throws:
> TemplateSyntaxError at /admin/auth/user/2/
> Caught KeyError while rendering: "Key 'password' not found in Form"
That exception is irrelevant to the code you provided. Paste full code
and full backtrace.
--
Michał (Saviq) Sawicz
signature.asc
Description: This is a digitally signed message part
Re: Django admin - how to hide some fields in User edit?
Dnia 2011-07-06, śro o godzinie 00:31 -0700, galgal pisze:
> Ok but like I said in previous post, exclude = ('groups',) etc doesn't
> work :/
It does, you just need to override both exclude / fields _and_
fieldsets.
The exception you've mentioned resulted from the fact that you've
excluded the field from the form, but the fieldsets still defined it as
one of the elements, so the form failed.
--
Michał (Saviq) Sawicz
signature.asc
Description: This is a digitally signed message part
Re: Django admin - how to hide some fields in User edit?
Dnia 2011-07-05, wto o godzinie 15:13 -0700, galgal pisze: > I made it in that way, and it works: Remember that you need to exclude the field from the form, too, if you don't want malicious attempts to inject the groups to work. -- Michał (Saviq) Sawicz signature.asc Description: This is a digitally signed message part
Re: Django admin - change permissions list
Dnia 2011-07-05, wto o godzinie 15:16 -0700, galgal pisze: > Is there any possibility to change permissions list in user edit page? > I don't wan't to show all of permissions for example admin log entry > or auth group etc. How can I modify a main queryset to exclude some of > it? Override ModelAdmin.get_form(), get form_class from super() and modify form_class.base_fields['fieldname'].queryset. -- Michał (Saviq) Sawicz signature.asc Description: This is a digitally signed message part
Re: Odp: Re: Django admin - how to hide some fields in User edit?
Dnia 2011-07-04, pon o godzinie 15:20 -0700, galgal pisze:
> Yes I read it. exclude = ('groups',) throws:
> Caught KeyError while rendering: "Key 'groups' not found in Form"
That's because the stock UserAdmin defines fieldsets in which 'groups'
is a field, you need to modify the fieldsets, too. [1]
[1]
https://code.djangoproject.com/browser/django/trunk/django/contrib/auth/admin.py#L27
--
Michał (Saviq) Sawicz
signature.asc
Description: This is a digitally signed message part
Re: Django admin - how to hide some fields in User edit?
Dnia 2011-07-04, pon o godzinie 15:13 -0700, galgal pisze: > That's my code now - how to hide groups for example? Have you tried reading the Django Admin docs? [1] [2] [1] https://docs.djangoproject.com/en/1.3/ref/contrib/admin/ [2] https://docs.djangoproject.com/en/1.3/ref/contrib/admin/#django.contrib.admin.ModelAdmin.exclude P.S. please fix your e-mail client not to translate "Re:" in responses' subjects. -- Michał (Saviq) Sawicz signature.asc Description: This is a digitally signed message part
Re: url problems
Dnia 2011-07-04, pon o godzinie 16:50 -0500, charles pisze: > The current URL, , didn't match any of these. And the current URL was? -- Michał (Saviq) Sawicz signature.asc Description: This is a digitally signed message part
Re: Django admin - hide remove link
Dnia 2011-07-04, pon o godzinie 14:15 -0700, galgal pisze: > How can I hide remove link in Django admin? I need to hide it in my > code, not in permissions (only user with id=1 can see it no matter if > any users are superusers) Override has_delete_permission [1] on your ModelAdmin. https://docs.djangoproject.com/en/1.3/ref/contrib/admin/#django.contrib.admin.ModelAdmin.has_delete_permission -- Michał (Saviq) Sawicz signature.asc Description: This is a digitally signed message part
Re: Odp: Re: Django admin - how to hide some fields in User edit?
Dnia 2011-07-04, pon o godzinie 14:19 -0700, galgal pisze: > I'm rather searchung the way to do that in my admin.py file not in > core files. Obviously the proposal was... fundamentally wrong. Create your own UserAdmin, unregister the one registered by django.contrib.admin and register your own. > admin.site.unregister(User) > admin.site.register(User, MyUserAdmin) -- Michał (Saviq) Sawicz signature.asc Description: This is a digitally signed message part
Re: getting objects unique in several ways (annotate?)
Dnia 2011-06-29, śro o godzinie 16:31 -0700, elliot pisze:
> Book.objects.annotate(mostrecent = Max('transaction__start_date'))
.values('pk')
Or whatever values you want.
--
Michał Sawicz
signature.asc
Description: This is a digitally signed message part
Re: how to display form data with original values after validation failure?
Dnia 2011-06-22, śro o godzinie 13:44 -0700, snfctech pisze: > Which passes the form with the same post data and some error messages > back to the user. Maybe you could just reinstantiate a clean RegistrationFormSet without passing request.POST to it? Maybe copying errors from the original, bound one. Just my c2. Cheers -- Michał (Saviq) Sawicz signature.asc Description: This is a digitally signed message part
Re: templatetags and refresh
Dnia 2011-06-22, śro o godzinie 06:32 -0700, Wim Feijen pisze:
> Our query is:
>
> newsitems = NewsItem.objects.filter(Q(expires_at__gt = datetime.now())
> | Q(expires_at__isnull = True), effective_at__lte = datetime.now(),
> is_active=True).order_by('-news_timestamp')
>
> Or is datetime.now() fixed to the past?
You're probably gonna have to elaborate on your code, but did you try
datetime.now without calling it? IIUC that helps here and there, not
sure it will in your particular case.
--
Michał (Saviq) Sawicz
signature.asc
Description: This is a digitally signed message part
Re: Possible interest in a webcast/presentation about Django site with 40mil+ rows of data??
Dnia 2011-06-22, śro o godzinie 14:15 +0100, Cal Leeming [Simplicity Media Ltd] pisze: > If you're interested, please reply on-list so others can see. Sure, I'd attend. -- Michał (Saviq) Sawicz signature.asc Description: This is a digitally signed message part
Re: QuerySet .annotate().extra() issues
Dnia 2011-06-21, wto o godzinie 14:31 -0300, Andre Terra pisze: > I'm not sure this has anything to do with your issue, but it's easy to > miss when reading the docs. It's kind of related, but not directly. The similarity to the issue mentioned above is that the default ordering field is added to the GROUP BY clause, too. Not exactly my issue, but good input nevertheless, since that kind of confirms that the behavior is "on purpose". Any way to circumvent that in that case? Cheers, -- Michał (Saviq) Sawicz signature.asc Description: This is a digitally signed message part
QuerySet .annotate().extra() issues
Hi all,
I'm not sure it's actually supposed to work, but looks like a common
enough approach that it should.
Say you have an aggregate query:
> Model.objects.values('field').annotate(Sum('count'))
that results in an aggregate query that follows:
> SELECT "models_model"."field", SUM("models_model"."count") AS
> "count__sum" FROM "models_model" GROUP BY "models_model"."field"
And that's all fine, but if you want to get additional fields:
> Model.objects.values('field').annotate(Sum('count')).values('field',
> 'field2', 'count_sum')
the additional fields get added to the GROUP BY clause:
> SELECT "models_model"."field", "models_model"."field2",
> SUM("models_model"."count") AS "count__sum" FROM "models_model" GROUP
> BY "models_model"."field", "models_model"."field",
> "models_model"."field2"
That doesn't, in itself, pose any problems. "field" is added twice, but
that's probably optimized down within SQL itself. I'm only afraid that
grouping by "field" and "field2" is slower than grouping by "field" is.
Maybe my approach here is wrong? What would you do to group by "field",
annotate with SUM("count") and retrieve "field2", too?
Now, if you want to leverage some more advanced queries:
> Model.objects.values('field').annotate(Sum('count')).values('field',
> 'field2', 'count_sum').extra({'value': 'SUM("models_model"."field3" *
> "models_model"."count")'})
that breaks with:
> DatabaseError: aggregate functions are not allowed in the GROUP BY
> clause
because the resulting query looks like this:
> SELECT (SUM("models_model"."field3" * "models_model"."count")) AS
> "value", "models_model"."field", "models_model"."field2",
> SUM("models_model"."count") AS "count__sum" FROM "models_model" GROUP
> BY "models_model"."field", "models_model"."field",
> "models_model"."field2", (SUM("models_model"."field3" *
> "models_model"."count"))
As you can see, the field definitions from extra() gets added to the
GROUP BY clause, and fails.
If I drop the last added GROUP BY element (or even all of them, bar
"field"), the query is working fine, and the results are as expected.
Is this an eccentric enough usecase that I should forget about that? Or
is my approach simply wrong?
Best regards,
--
Michał (Saviq) Sawicz
signature.asc
Description: This is a digitally signed message part
