Re: Methods on related Managers
On 3/24/06, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote: I'm really asking about something more abstract, though -- is there(should there be) the ability to define manager methods availableonly in a related context?+1 to this idea. The managers used by object descriptors already have this problem, of a fashion: the first line in the __get__ and __set__ method for each descriptor is a check to restrict access to descriptors to instances only. I can see a generalised version of this being very useful, both in cleaning up the existing usage, and for use cases like Jacob is describing, even if it is just a decorator implementing exactly the same "if instance" type logic. Russ Magee %-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: magic-removal: plans/estimates for the trunk-merge?
This is a common thread :-) and one I am interested in, but you can search the forumn for the results. Bascially it will be done when its done it seems :-) S --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
MR: Bug with Class Meta verbose name
Hi I think I have found a bug in the MR branch with verbose name. According the (out of date) documentation verbose_name_plural will use verbose_name + 's'. However when I just set verbose_name, Admin still shows the wrong name. If I set the verbose_name_plural, it works. Example: Class TelDirEntry(): class Meta: verbose_name = 'Telephone Directory' In admin this shows 'TelDirEntrys' as the name. But Class TelDirEntry(): class Meta: verbose_name = 'Telephone Directory' verbose_name_plural = 'Telephone Directory Entries' will produce ''Telephone Directory Entries'' in admin. Any thoughts? Thanks, C --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: magic-removal: plans/estimates for the trunk-merge?
ChaosKCW wrote: > This is a common thread :-) and one I am interested in, but you can > search the forumn for the results. Bascially it will be done when its > done it seems :-) > i'm following the forums, and i knew that probably the answer would be when-its-done :-( just wanted to make sure, and maybe a little hoped for an answer with some "better" time-estimates. from the wikipage it seems that 2 things are missing yet: 1.Remove automatic manipulators, in favor of validation-aware models 2.Change subclassing syntax i know that for #1, Adrian has committed some stuff and for #2, there's a wikipage. based on this, and the current speed of development on magic-removal, the integration still seems to be months away :-( this was not meant to criticize anyone, it's just that i'm trying make myself some estimates for this issue :-) thanks, gabor --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Client-side hashing of passwords before logging in
I like these kind of solutions. Helps when you don't have SSL. Yahoo does something similar... On 3/24/06, SmileyChris <[EMAIL PROTECTED]> wrote: > > Oh what the heck, here's the patch: > http://code.djangoproject.com/ticket/1534. > > I'd still like to hear some comments. :) > -- Julio Nobrega - http://www.inerciasensorial.com.br --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Methods on related Managers
Jacob Kaplan-Moss wrote: > I can buy that... but it doesn't just return useless data, it returns > a potentially HUGE dataset -- every single EventTime in the system! > -- which an unwary template author might stumble across and bring the > site to its knees. Surely a template author couldn't do that, unless you put the 'Place' class or 'Place.objects' into the template context. Isn't this the same as the ability to execute any other method on the default manager (i.e. you can't in a template)? Luke --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: magic-removal: plans/estimates for the trunk-merge?
Hi I am very interested in starting aproject at my company in Django, but am not keen on starting one of 0.91. So I am hoping the MR will be merged soon too :-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: magic-removal: plans/estimates for the trunk-merge?
ChaosKCW wrote: > Hi > > I am very interested in starting aproject at my company in Django, but > am not keen on starting one of 0.91. So I am hoping the MR will be > merged soon too :-) > > actually, i'm in a similar situation. we have already developed something, which is for now quite simple (6-7 models, functionality is mostly only the default admin-stuff provided by django), which will be probably released next month. so i am waiting if i'll be able to change it to magic-removal :) gabor --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
dojo implementation
I have been using Dojo with Django and plan to do quite a bit more in the next little while. I am wondering if it is still planned to release some Dojo integration soon and if there is any idea what that will look like. I have not found any hint of if in the magic-removal branch. Some insight would greatly inform how I proceed, so that refactoring to the Django way might be easier when the time comes. Thanks, David S. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: dojo implementation
David S. <[EMAIL PROTECTED]> writes: > [snip] I am wondering if it is still planned to release some Dojo > integration soon and if there is any idea what that will look like. I have > not > found any hint of if in the magic-removal branch. Terribly sorry. I meant to post to django.user. But I won't bother cross-posting if it is all the same. I'll make it django.devel worthy by mentioning that I would like to contribute to the dojo work in any way I can. Thanks again, David S. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: dojo implementation
On 3/24/06, David S. <[EMAIL PROTECTED]> wrote:
> I am wondering if it is still planned to release some Dojo integration soon
> and if there is any idea what that will look like.
I've been working on the Dojo/Django integration, and I'm pretty close
to having something that works and that I can start showing off, but
there's still some work to be done -- more things are needing to be
refactored than I'd hoped.
Anyway, here's how I'm laying it out:
All of the packages provided by Django will live in a 'django'
namespace; so, for example, using package 'foo' from Django would mean
doing "dojo.require('django.foo');". On my test tree right now, the
'django' namespace looks like this:
* django.util -- mostly functions from the admin's 'core.js'. Some of
it can be replaced with functions Dojo provides, but that would
involve even more extensive rewriting and so my first public iteration
probably won't do that.
* django.string -- temporary home to the String extensions found in
core.js. They're separate from django.util mostly because I really
want to make them go away somehow.
* django.datetime -- all of the date- and time-parsing functions, the
Date object extensions, and a sub-package, django.datetime.calendar,
containing the calendar-generation code.
* django.rpc -- the mostly-finished JavaScript interface to a RESTful
Django web-service API that Jacob and I have been hammering out. I'll
try to put up a draft of that sometime soon, too.
* django.widget -- the Django widgets. To start with, we'll have three
packages here: django.widget.DateTime will provide the fancy date and
time shortcuts in the admin, and the combination of
django.widget.SelectBox and django.widget.SelectFilter will provide
the many-to-many selection interface. Or SelectBox.js may get demoted
from being a widget in its own right; I haven't quite made up my mind
on that yet.
Thoughts? Arguments? Tell me I'm on crack?
--
"May the forces of evil become confused on the way to your house."
-- George Carlin
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: dojo implementation
James Bennett <[EMAIL PROTECTED]> writes: > Thoughts? Arguments? Tell me I'm on crack? Sounds thorough. Are there plans for templates to support this, ala Rails helpers? It would be nice to use the events system to full effect so perhaps that sort of helper/template tag idea would not work very well. Anyhow, looking forward to testing. Best, David S. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: additional Admin option for fieldsets
On Thursday 23 March 2006 21:48, Wilson Miner wrote: > Too crufty to wrap it in a div class="description" so I can set it > off somehow in the styles? I'm not quite sure what you mean - I had already wrapped it in and added some padding - were you saying that was crufty? I've committed my changes now, so feel free to fix it up so it looks better. James: I thought about using , but some existing styling on p interfered, plus if you just use a div then it doesn't limit what HTML can be used (e.g. you could have multiple paragraphs). Luke -- "Adversity: That which does not kill me only postpones the inevitable." (despair.com) Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: dojo implementation
On 3/24/06, David S. <[EMAIL PROTECTED]> wrote: > Sounds thorough. Are there plans for templates to support this, ala Rails > helpers? It would be nice to use the events system to full effect so perhaps > that sort of helper/template tag idea would not work very well. I'm not planning to implement anything like that, but if others want to code it up and submit patches that'd be cool, and we could get some discussion going about whether that's something we want in Django. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: magic-removal: plans/estimates for the trunk-merge?
Have you guys tried the MR branch yet? for me, it seems quite stable since the pycon sprint. There is nothing saying you need to wait until somone 'blesses' it for you to use it. I've been using it on my open source forum app (http://zyons.com) which is doing some tricky things and I haven't run into a 'MR' bug for 2-3 weeks. On 3/25/06, gabor <[EMAIL PROTECTED]> wrote: > > ChaosKCW wrote: > > Hi > > > > I am very interested in starting aproject at my company in Django, but > > am not keen on starting one of 0.91. So I am hoping the MR will be > > merged soon too :-) > > > > > > actually, i'm in a similar situation. > > we have already developed something, which is for now quite simple (6-7 > models, functionality is mostly only the default admin-stuff provided by > django), which will be probably released next month. so i am waiting if > i'll be able to change it to magic-removal :) > > gabor > > > -- [EMAIL PROTECTED] -- blog: http://feh.holsman.net/ -- PH: ++61-3-9877-0909 If everything seems under control, you're not going fast enough. - Mario Andretti --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Client-side hashing of passwords before logging in
Meh. It's a "wontfix". --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Proposal: add context_processors args to admin views
I'd like to add a context_processor argument to the five admin views: add_stage, change_stage, delete_stage, history, and change_list This may seem pretty useless to most people, but I think the admin system would be a lot more useful if you could override default options like you can in the generic views. For now, I'd just wrap the admin views with my own custom code like so: from django.contrib.admin.views.main import change_stage def my_change_stage(request, app_label, model_name, object_id): return change_stage(request, app_label, model_name, object_id, request_processors=myprocs) It may be nice to add these as Admin options as well: class Book(models.Model): name = models.CharField(maxlength=255) class Admin: # these get applied to all 5 view contexts context_processors = my_processors # these get applied to add_stage's context add_stage_context_processors = other_processors That's just for convenience though. Will anyone scream if I start adding generic view style arguments to the admin views in magic-removal? Joseph --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Broken Filters in Template Conditional
when i try the following:
{% ifequal bar foo.id|stringformat:"d" %}
I get an error saying that:
VariableDoesNotExist at /foobars/
Failed lookup for key [id|stringformat:"d"] in foo
it's as if it strips anything that's before the '.'
please correct me if this is not a bug.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
results_per_page does not work properly
I have added a few extra_lookup_kwargs to my generic object_list and
when in {{ results_per_page }} in my template it always displays what I
paginate_by. I'm using 0.91.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Broken Filters in Template Conditional
On 3/25/06, bradford <[EMAIL PROTECTED]> wrote:
>
> when i try the following:
>
> {% ifequal bar foo.id|stringformat:"d" %}
>
> I get an error saying that:
> VariableDoesNotExist at /foobars/
> Failed lookup for key [id|stringformat:"d"] in foo
>
> it's as if it strips anything that's before the '.'
>
> please correct me if this is not a bug.
>
>
It seems that ifequal tag cann't deal with filter.
--
I like python!
My Blog: http://www.donews.net/limodou
NewEdit Maillist: http://groups.google.com/group/NewEdit
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: results_per_page does not work properly
On 3/25/06, bradford <[EMAIL PROTECTED]> wrote:
>
> I have added a few extra_lookup_kwargs to my generic object_list and
> when in {{ results_per_page }} in my template it always displays what I
> paginate_by. I'm using 0.91.
>
what do you want. I'v checked the source code about object_list, and
the docstring says that:
results_per_page
number of objects per page (if paginated)
So results_per_page is a integer but not a object list.
--
I like python!
My Blog: http://www.donews.net/limodou
NewEdit Maillist: http://groups.google.com/group/NewEdit
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: results_per_page does not work properly
i want the number of objects returned for that particular page. i guess what i want is results_on_page. when i go to page 2 (of my results), which only has 1 object listed it says that results_per_page is 2, i would like it to say 1. what would be even better is if there was a displaying_results_from and displaying_results_to. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: results_per_page does not work properly
On 3/25/06, bradford <[EMAIL PROTECTED]> wrote:
>
> i want the number of objects returned for that particular page. i
> guess what i want is results_on_page. when i go to page 2 (of my
> results), which only has 1 object listed it says that results_per_page
> is 2, i would like it to say 1. what would be even better is if there
> was a displaying_results_from and displaying_results_to.
>
There seems no such attribute existed in list_detail, but I think you
can count the number of the object_list, if you are using template, I
think you can do:
{{ object_list|length }}
to get the exactly number of the objects on the page.
--
I like python!
My Blog: http://www.donews.net/limodou
NewEdit Maillist: http://groups.google.com/group/NewEdit
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: results_per_page does not work properly
thanks. that seemed to do the trick. it would be nice to see the displaying_results_from/displaying_result_to feature implemented. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: results_per_page does not work properly
On 3/25/06, bradford <[EMAIL PROTECTED]> wrote: > > thanks. that seemed to do the trick. > > it would be nice to see the > displaying_results_from/displaying_result_to feature implemented. > I think you can write your own pagination process. I create one for me according to the core/paginator.py. -- I like python! My Blog: http://www.donews.net/limodou NewEdit Maillist: http://groups.google.com/group/NewEdit --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
