Re: Decision for ticket #6362 - Remove blank spaces with strip when validating the data
On Wed, May 13, 2009 at 2:36 AM, julianb wrote: > Since the ticket is one year old, that time had come and passed. The ticket's age is irrelevant. *right this minute*, everyone is focused on 1.1, so making a design decision for this ticket is not important right now. Once 1.1 is out, it can be revisited. Even if you got a decision right now, it would never have a chance of making it in to 1.1, so rushing the decision would be pointless anyway. -- Collin Grady --~--~-~--~~~---~--~~ 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: Debugging unit test?
You probably want django-users, since this list is about the development of django itself, not other topics. On Sun, May 10, 2009 at 11:39 AM, Joshua Russo wrote: > > What do you use to debug the unit tests? I've been using Netbeans 6.5 > with the Python plugin but it's a bit buggy still and the unit tests > seem to have real issues with the debugger at the moment. > > > -- Collin Grady --~--~-~--~~~---~--~~ 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: Use RequestContext if possible in default 500 error view
Perhaps the default 500 view could just include a few simple things like MEDIA_URL on its own? Alternatively, one can make a custom 500 handler with whatever info they want, instead of using django's default :) -- Collin Grady --~--~-~--~~~---~--~~ 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: #3182 -- model instance update() method and QuerySet update_or_create() method
On Mon, Mar 23, 2009 at 12:44 AM, Ivan Sagalaev wrote: > I'd like to chime in with another point of view. Not my own, I was just > in a discussion about it in our local forums and I don't want the idea > to vanish. > > A person there wanted an `update()` method too but not behaving like you > show. Instead he wanted it to update *just* the fields passed as > arguments. I.e. it should be equivalent to this: So more like http://code.djangoproject.com/ticket/4102 then ? :) -- Collin Grady --~--~-~--~~~---~--~~ 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: Multiple admin forms
Usage questions belong on the django-users mailing list. This list is for the development of django itself. -- Collin Grady --~--~-~--~~~---~--~~ 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: Creating objects with references together
Usage questions like this belong on the django-users list - this list
is for the development of django itself.
On Mon, Mar 16, 2009 at 9:38 AM, Yaniv Haber wrote:
>
> hi,
>
> I need to create 2 objects, one containing a reference to the other,
> in one shot. I get an IntegrityError exception while trying to do so,
> claiming that the foreign key is None on creation. Hope someone can
> help...
> (when I refresh the browser and rePOST the data it works as the
> Product object is already there and is not created at the same time)
>
> Thanks, Yaniv
>
> I have the following models:
>
> Class Product
> productId = models.AutoField(primary_key=True)
> name = models.CharField(max_length=200, unique=True)
> description = models.CharField(max_length=200, blank=True)
>
> Class Manufacturer
> manId = models.AutoField(primary_key=True)
> product = models.ForeignKey(Product)
> contact = models.ForeignKey(User)
> price = models.PositiveIntegerField()
>
> I created a form containing fields for both, with a 'save' function:
>
> class ProductForm(forms.Form):
> name = forms.CharField(max_length=200)
> description = forms.CharField(max_length=200)
> price = forms.IntegerField(min_value=0)
>
> def save(self):
> prod = Product(name=self.cleaned_data['name'],
> description=self.cleaned_data['description'])
> prod.save()
>
> ma = Manufacturer(product=prod,
> contact=self.data
> ['user'], # this is being passed by
> the view
> price=self.cleaned_data['price'])
> ma.save();
>
> The problem: the new product is being saved but on the
> manufacturer.save() I get the following exception:
>
> Exception Type: IntegrityError
> Exception Value: (1048, "Column 'product_id' cannot be null")
> Exception Location: C:\Development\Python25\Lib\site-packages\django
> \db\backends\mysql\base.py in execute, line 88
>
> Environment:
>
> Request Method: POST
> Request URL: http://localhost:8000/addproduct/
> Django Version: 1.0.2 final
> Python Version: 2.5.4
> Installed Applications:
> ['django.contrib.auth',
> 'django.contrib.contenttypes',
> 'django.contrib.sessions',
> 'django.contrib.sites',
> 'django.contrib.admin',
> 'django.views.generic',
> 'mysite.myapp',
> 'registration']
> Installed Middleware:
> ('django.middleware.common.CommonMiddleware',
> 'django.contrib.sessions.middleware.SessionMiddleware',
> 'django.contrib.auth.middleware.AuthenticationMiddleware',
> 'django.middleware.doc.XViewMiddleware')
>
>
> Traceback:
> File "C:\Development\Python25\Lib\site-packages\django\core\handlers
> \base.py" in get_response
> 86. response = callback(request, *callback_args,
> **callback_kwargs)
> File "C:\Development\Python25\Lib\site-packages\django\contrib\auth
> \decorators.py" in __call__
> 67. return self.view_func(request, *args, **kwargs)
> File "C:\Development\googleapp_projects\busa\..\mysite\myapp\views.py"
> in registerProduct
> 63. f.save()
> File "C:\Development\googleapp_projects\busa\..\mysite\myapp\forms.py"
> in save
> 76. ma.save();
> File "C:\Development\Python25\Lib\site-packages\django\db\models
> \base.py" in save
> 311. self.save_base(force_insert=force_insert,
> force_update=force_update)
>
>
> >
>
--
Collin Grady
--~--~-~--~~~---~--~~
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: Cache related values without needing to hit database twice
I think you should look at select_related() to solve most of those cases. -- Collin Grady --~--~-~--~~~---~--~~ 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: My case for #9006
Of course not - you can do .order_by() to clear ordering if you really don't want a default ordering somewhere, but all your examples sound like you do :) On Sat, Feb 28, 2009 at 3:02 PM, PauloS wrote: > > On Feb 27, 5:28 pm, Collin Grady wrote: >> One could also set a default ordering on a model and have a consistent >> order everywhere :) > > This way you have to pay the ORDER BY price for every query? > > > -- Collin Grady --~--~-~--~~~---~--~~ 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: My case for #9006
One could also set a default ordering on a model and have a consistent order everywhere :) -- Collin Grady --~--~-~--~~~---~--~~ 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: Creating "lazy" foreign keys
Well he'd have to use an IntegerField, not a ForeignKey, but the same
idea applies - he can do his own validation/etc in the property
handlers.
On Mon, Feb 23, 2009 at 7:27 PM, Jerome Leclanche wrote:
>
> Sounds like that wouldn't work. Django fails on __init__ with invalid
> foreignkeys.
>
> On Tue, Feb 24, 2009 at 3:24 AM, join.toget...@gmail.com
> wrote:
>>
>> On Feb 22, 10:30 pm, Adys wrote:
>>> Not sure I follow you. You mean overriding the set property of a
>>> ForeignKey/IntegerField?
>>>
>>> On Feb 23, 6:23 am, "join.toget...@gmail.com"
>>>
>>> wrote:
>>> > What about something like a property()? The set method would act like
>>> > normal, but the get method would have some extra logic built into it
>>> > that would take care of everything.
>>
>> Something like the following:
>>
>> _other=models.ForeignKey('Other')
>>
>> def _set_other(self, o):
>> _other=o
>>
>> def _get_other(self):
>> try:
>> return _other
>> except Other.DoesNotExist:
>> return None
>>
>> other=property(_get_other,_set_other)
>>
>> When someone tries to access "other", it will call the _get_other()
>> method automagically, so you can have whatever logic you need in there
>> without forcing anything but the model to deal with it.
>> >
>>
>
>
>
> --
> Adys
>
> >
>
--
Collin Grady
--~--~-~--~~~---~--~~
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: Creating "lazy" foreign keys
You completely misread the tone of the email - that *was* my pointer for how to do it - instead of trying to shoehorn it into ForeignKey where it doesn't belong, just use an IntegerField, possibly with model functions to do the querying (which could be made properties to act like fields) to get the info from the other table and return the default you want if the other row is missing. On Sun, Feb 22, 2009 at 2:51 AM, Adys wrote: > > Except... I'm not expecting anything. > > I'm going to work on this regardless, I'm just proposing to share my > work in exchange for a few pointers here and there. Sarcasm, and > blaming the user, is a very tasteless way of saying no. > > > On Feb 22, 10:52 am, Collin Grady wrote: >> Seems you could just use an IntegerField and do it yourself, instead >> of expecting django to adapt itself to your bad db design :) >> >> >> >> On Sat, Feb 21, 2009 at 5:16 PM, Adys wrote: >> >> > I see what you mean. I agree to an extent - data needs to stay as >> > clean as possible. But this isn't the goal in every situation, and >> > doesn't always mean that data is erroneous - it can simply be lacking. >> >> > Simplified use case: >> > I've got for example a table that contains foreignkeys to another >> > "additional_names" table no longer maintained publicly. What I want to >> > do in this case is use the few hundred rows I gathered from the last >> > public versions, and leave the other ones blank. That way, in my app, >> > I can display "This object has an additional name, but I don't know >> > which". Having listings like that allows me to present data that would >> > need post-update manual work, should there ever be enough references >> > to a specific lacking row in additional_names to figure it out and >> > stub it properly. >> >> > When nulling out the foreign keys is an option, I already do that, >> > it's not a problem. The problem hits when I have to keep the fkey IDs >> > intact. >> >> > On Feb 22, 1:48 am, Killian wrote: >> >> Sorry for the previous one, accidentally pressed alt-s >> >> >> What I meant to say was: as far as I can see your problem is mostly >> >> covered >> >> by faulty db-design or maintenance, which is not something django should >> >> cover in my opinion, it seems logically you do a cleaning of your database >> >> to set all non-existing foreignkeys to NULL. >> >> >> 2009/2/22 Killian >> >> >> > Hi >> >> >> > 2009/2/21 Adys >> >> >> >> Hi there >> >> >> >> I've been thinking for the past couple of days of a simple "lazy" >> >> >> ForeignKey design (or whichever name would fit better). It's something >> >> >> I've tried really hard to find in Django, unsuccessfully. Some >> >> >> explanation first... >> >> >> > Lazy is imho not a decent name indeed, 'lazy' usually means >> >> > relationships >> >> > aren't fetched prematurely (foreignkey object isn't fetched >> >> > automatically), >> >> > which django does by default if I'm not mistaken. >> >> >> >> I tried to get some background on django-users, cf >> >> >>http://groups.google.com/group/django-users/browse_thread >> >> >> >> /thread/caec53feb0ddb43a# >> >> >> To make it short: My project reuses imported data. This data is *very* >> >> >> faulty and a lot of ForeignKeys point to deleted/non-existing rows. I >> >> >> can't afford checking integrity constantly (cf link). >> >> >> > As far I c >> >> >> >> A lazy ForeignKey would assume the data is valid, and return >> >> >> "something else" if it's not. I'm not sure what the best value >> >> >> returned would be. It could be a row with placeholder/default values, >> >> >> it could be an exception, etc. I haven't worked deeply with Django's >> >> >> codebase, I'm unsure about design details. >> >> >> The idea here is to be able to offer something "valid or unknown". I >> >> >> hope I'm not too unclear... >> >> >> > First of all, imho this isn't about "lazy", lazy usually means >> >> > relationships aren't fetched
Re: Creating "lazy" foreign keys
Seems you could just use an IntegerField and do it yourself, instead of expecting django to adapt itself to your bad db design :) On Sat, Feb 21, 2009 at 5:16 PM, Adys wrote: > > I see what you mean. I agree to an extent - data needs to stay as > clean as possible. But this isn't the goal in every situation, and > doesn't always mean that data is erroneous - it can simply be lacking. > > Simplified use case: > I've got for example a table that contains foreignkeys to another > "additional_names" table no longer maintained publicly. What I want to > do in this case is use the few hundred rows I gathered from the last > public versions, and leave the other ones blank. That way, in my app, > I can display "This object has an additional name, but I don't know > which". Having listings like that allows me to present data that would > need post-update manual work, should there ever be enough references > to a specific lacking row in additional_names to figure it out and > stub it properly. > > When nulling out the foreign keys is an option, I already do that, > it's not a problem. The problem hits when I have to keep the fkey IDs > intact. > > On Feb 22, 1:48 am, Killian wrote: >> Sorry for the previous one, accidentally pressed alt-s >> >> What I meant to say was: as far as I can see your problem is mostly covered >> by faulty db-design or maintenance, which is not something django should >> cover in my opinion, it seems logically you do a cleaning of your database >> to set all non-existing foreignkeys to NULL. >> >> 2009/2/22 Killian >> >> > Hi >> >> > 2009/2/21 Adys >> >> >> Hi there >> >> >> I've been thinking for the past couple of days of a simple "lazy" >> >> ForeignKey design (or whichever name would fit better). It's something >> >> I've tried really hard to find in Django, unsuccessfully. Some >> >> explanation first... >> >> > Lazy is imho not a decent name indeed, 'lazy' usually means relationships >> > aren't fetched prematurely (foreignkey object isn't fetched automatically), >> > which django does by default if I'm not mistaken. >> >> >> I tried to get some background on django-users, cf >> >>http://groups.google.com/group/django-users/browse_thread >> >> >> /thread/caec53feb0ddb43a# >> >> To make it short: My project reuses imported data. This data is *very* >> >> faulty and a lot of ForeignKeys point to deleted/non-existing rows. I >> >> can't afford checking integrity constantly (cf link). >> >> > As far I c >> >> >> A lazy ForeignKey would assume the data is valid, and return >> >> "something else" if it's not. I'm not sure what the best value >> >> returned would be. It could be a row with placeholder/default values, >> >> it could be an exception, etc. I haven't worked deeply with Django's >> >> codebase, I'm unsure about design details. >> >> The idea here is to be able to offer something "valid or unknown". I >> >> hope I'm not too unclear... >> >> > First of all, imho this isn't about "lazy", lazy usually means >> > relationships aren't fetched prematurely (foreignkey object isn't fetched >> > automatically), which django does by default. >> >> > Secondly, the NULL value in databases is actually defined originally as >> > Unknown, so it seams normal in your situation to default to None if your >> > relationship is undefined (and allow null=True in your model). >> >> >> I'm sure there's a better solution - I have yet to find it - but I >> >> would first like to hear feedback on a feature like that. If you feel >> >> it's a good idea I'm interested in working on it. If you feel >> >> otherwise, well... I'm still looking for a better suggestion. >> >> >> Cheers >> >> >> JL > > > -- Collin Grady --~--~-~--~~~---~--~~ 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: #10244 FileFields can't be set to NULL in the db
It will only store NULL if you set it to None - if you leave the field
blank in a form or admin, there's still an empty string posted for
most string field types, so it stores that empty string.
On Fri, Feb 20, 2009 at 4:57 AM, oyvind.salt...@gmail.com
wrote:
>
> If a FileField with null=True is set to None, the db stores '' in the
> db and not NULL as I would expect.
>
> Also, if a FileField has both blank=True and null=True a ModelForm
> without a file will save '' in the db, not sure if this is the desired
> behaviour.
>
> So the question is should the behaviour be as-is and if not is the
> correct place to solve it in get_db_prep_value?
>
> Example of code that this issue affects:
>
> Model.objects.filter(filefield=u'') seems wrong as compared to
> Model.objects.filter(filefield__isnull=True)
>
> Model.objects.aggregate(Count('filefield')) i would expect this to
> count objects with a file and not those without a file.
>
> This may relate to other fields aswell, if a field has both blank=True
> and null=True should it not store NULL in the db?
> >
>
--
Collin Grady
--~--~-~--~~~---~--~~
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: Problem with ORM
On Thu, Jan 15, 2009 at 2:09 PM, Jan Bednařík wrote: > That should not happen. > > instance.delete() > instance.save() > > should raise ObjectDoesNotExist exception. Any other behavior is bug. Why? You have a perfectly valid object instance, and you're then saving it. Just like if you had instantiated it. If you want it to fail if the object is gone, use force_update=True as you were told before. This is not an ORM bug, no matter how much you would like it to act otherwise. -- Collin Grady --~--~-~--~~~---~--~~ 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: Problem with ORM
On Wed, Jan 14, 2009 at 9:51 AM, Sebastian Bauer wrote: > how orm can save second instance of the same row when its deleted? Deleting an object won't magically remove all references to it - the instance_2 variable still has a perfectly valid object, so saving it just reinserts a new copy of it. This is not a bug, as everything is working as intended :) -- Collin Grady --~--~-~--~~~---~--~~ 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: view permission for contrib.admin
On Thu, Dec 18, 2008 at 8:30 AM, gert wrote: > Which was definitely what was intended on day one when the CHANGE, > ADD, DELETE permissions were created. Says you. Admin is for admins. Not limited users. Write your own views. -- Collin Grady --~--~-~--~~~---~--~~ 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: test failures when CACHE_BACKEND is 'dummy:///'
On Wed, Dec 17, 2008 at 8:45 PM, Tai Lee wrote: > Is this a bug? If not strictly a bug, would it be worth changing this > behaviour to allow developers to more easily run tests on their > applications as they develop? I told you in channel that it's normal - dummy does not cache anything - the tests rely on caching, since they test the cache session backend. There is no way to make them not fail unless you either do not test that, or make the dummy cache backend /not/ a dummy cache backend anymore. -- Collin Grady --~--~-~--~~~---~--~~ 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: Additional Fields in Core
Make app. Post on Google Code (or other site) Profit! :) These shouldn't need to be in core to be used. -- Collin Grady --~--~-~--~~~---~--~~ 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: RequestContext rarely used (branched from Feature reviews for 1.1)
On Tue, Nov 18, 2008 at 4:43 PM, Ludvig Ericson <[EMAIL PROTECTED]> wrote: > And that's very doable, and I'm with you on this. I hate having to > pass context_instance. Long lines. Although nothing stops someone from writing their own wrapper if they don't like direct_to_template for some reason :) http://www.djangosnippets.org/snippets/3/ -- Collin Grady --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Suggestion for doc search
Would it be possible to have the doc search add a "-inurl:olddocs" to all search queries? Anytime you search for something without it right now, you always hit the redirect warning, even though there was no redirect, and it was confusing a few users today in IRC, since they thought they hit an out of date doc page. -- Collin Grady --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: login_required
On Mon, Nov 10, 2008 at 11:49 AM, Sebastian Bauer <[EMAIL PROTECTED]> wrote: > Hello, i think login_required should check that user is not only > authenticated, but also if is active. What do you think about this change? I think you can write your own decorator to do that, and it would be a backwards-incompatible change, so it isn't likely to happen :) -- Collin Grady --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: problem with inlineformset_factory
Usage questions belong on the django-users list - this list is for the development of django itself :) -- Collin Grady --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Model inheritance question
Usage questions belong on django-users, not django-developers - this list is for the discussion of the development of django itself. -- Collin Grady --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Proposal: remove auth context processor dependancy for Admin
On Sun, Nov 2, 2008 at 8:57 AM, bo <[EMAIL PROTECTED]> wrote: > Yes, that may be true. > > But why does the 'default' behavior impose these dependencies when > they are not required? As that context processor has this other 'side > effect' of making an entire site "Vary" under a cookie, hit the > session and hit the DB. I think you're confused - the context processor doesn't set a cookie, so it isn't causing any Vary behavior, and admin *does* currently depend on it - it needs the info the processor provides. Unless admin was rewritten to add them to context manually on every view, it will continue to need it. > and one would need to override every other function that calls > "template.RequestContext' which is most of the meat of sites.py. Uh, no you wouldn't - if you tell admin not to check for that context processor, you could replace the auth processor with a custom one that only works in admin's path and as such wouldn't add any db hits to the rest of the site. So if your goal is to make only admin do the queries for that data, it's entirely possible. -- Collin Grady --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Proposal: remove auth context processor dependancy for Admin
On Sat, Nov 1, 2008 at 9:45 AM, bo <[EMAIL PROTECTED]> wrote: > One aid in this area would be to remove the dependancy of > context_processor.auth in the Admin world (which most certainly needs > the user, messages and perms in the context) You can already do this - simply make your own subclass of AdminSite and override check_dependencies -- Collin Grady --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: "things are ready" signal?
On Wed, Oct 1, 2008 at 2:04 PM, Marc Fargas <[EMAIL PROTECTED]> wrote: > So, would a signal there be useful? (no ticket filled yet) And, where > can one hook code for that? :) I don't think any such place exists, so there's nothing you can do for it. -- Collin Grady --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Postgresql transaction aborts, despite being in autocommit mode
This is related to http://code.djangoproject.com/ticket/3460 -- Collin Grady --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: 'unicode' object has no attribute 'user'
On Thu, Sep 18, 2008 at 4:31 AM, laspal <[EMAIL PROTECTED]> wrote: > I am trying to send mail using sendmail. Getting the error 'unicode' > object has no attribute 'user' This question belongs on django-users, not django-development - this list is for the development of django itself, not usage questions or errors like this :) -- Collin Grady --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: RFC: Raise an Exception to return a Response
Wouldn't it be easier to use process_exception instead of process_view ? -- Collin Grady --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: bug in forms
On Tue, Sep 16, 2008 at 4:40 PM, Diego Andrés Sanabria Martin (diegueus9) <[EMAIL PROTECTED]> wrote: > sorry, you have reason, my english is bad and i am tired, but i have this > error: >>>> form.clean() > Traceback (most recent call last): > File "", line 1, in ? > File "/home/felipecastel/django1.0_src/django/forms/models.py", line > 208, in clean >self.validate_unique() > File "/home/felipecastel/django1.0_src/django/forms/models.py", line > 236, in validate_unique >if name in self.cleaned_data and f.unique and not is_null_pk: > AttributeError: 'IdeaForm' object has no attribute 'cleaned_data' >>>> > and i read the doc over and over again and i cant use the forms. This sounds like more of a usage question then (for instance I see you calling form.clean() manually for some reason), so you should take it to django-users :) -- Collin Grady --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: bug in forms
On Tue, Sep 16, 2008 at 4:33 PM, Diego Andrés Sanabria Martin (diegueus9) <[EMAIL PROTECTED]> wrote: > i found this: > Changed in Django 1.0: The cleaned_data attribute was called > clean_data in earlier releases. > > in http://docs.djangoproject.com/en/dev/topics/forms/#topics-forms-index > > I make a mistake? That line also says what I said - it *used to be* clean_data in 0.96, but it *is* cleaned_data now. So if the line of code had clean_data, it would be wrong, but it has cleaned_data, so it is right. -- Collin Grady --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: bug in forms
On Tue, Sep 16, 2008 at 4:27 PM, Diego Andrés Sanabria Martin (diegueus9) <[EMAIL PROTECTED]> wrote: > if name in self.cleaned_data and f.unique and not is_null_pk: > and in the doc, the variable self.cleaned is now self.clean_data You are incorrect. The variable was clean_data in 0.96 but changed to cleaned_data shortly after to avoid conflicts with validation functions for a field named "data" - you are reading old examples and/or docs. -- Collin Grady --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
newforms-admin and urls (reverse/etc)
I know it's kind of late to bring this up, but I haven't been using the branch, so it hasn't been at the front of my mind at all :) newforms-admin currently uses a url match of ^admin/(.*) which sort of kills reversing - you can't just pass the parts in, you have to manually build the string for the rest of the URL. Would it be feasible to change that back to separate url matches like the current admin, or would that take too long at this close date? Or perhaps another method would be to give newforms-admin its own helper to generate URLs? It's nice to be able to link back to admin for staff members, so you can quickly go and edit a page, so I think any fix along these lines would be very useful :) -- Collin Grady "I only touch base with reality on an as-needed basis!" -- Royal Floyd Mengot (Klaus) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: ManyToManyField in Admin list_display
Please send usage questions to django-users - this list is for the development of django itself. -- Collin Grady --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django newforms RadioSelect issue
Questions of this nature should go on django-users, not django-developers - this list is for the development of Django itself, not usage questions :) -- Collin Grady Sentimentality -- that's what we call the sentiment we don't share. -- Graham Greene --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: MySQL exact/iexact lookups change
George Vilches said the following: > As of http://code.djangoproject.com/changeset/7798 in the MySQL > DatabaseWrapper.operations, Malcolm has changed the "__exact" filter > to use '= BINARY' to force case-sensitive comparisons, which is > appropriate. > > I therefore propose that operations."__iexact" should be changed from > 'LIKE %s' to '= %s', which performs much better, and gives the same > results for the cases which the documentation specifically describes: > "Case-insensitive exact match". There's no reason to be using LIKE > here when the database gives us a better built-in option for the same > behavior. Actually, based on what I remember of my testing for #3575[1], = and LIKE were about the same when using a case insensitive collation (though I don't seem to have mentioned that in the ticket, since it didn't really matter there) [1] http://code.djangoproject.com/ticket/3575 -- Collin Grady --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: More secure user password reset
[EMAIL PROTECTED] said the following: > It sounds like what you are advocating is changing the password reset > to work similar to the way activation works in James Bennett's django- > registration, is that correct? Similar to that is what it sounds like - I'm definitely +1 on this - a lot of sites do it like this where you must confirm a password change to prevent this kind of thing - they could initiate as many requests as they wanted without actually changing anything. I'd suggest making the code to change the password a one-use-only item though, so that even if someone did sniff the code, it'd be useless after that. -- Collin Grady Abstainer, n.: A weak person who yields to the temptation of denying himself a pleasure. -- Ambrose Bierce, "The Devil's Dictionary" --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Spam detection
Mike Scott said the following: > Maybe the page after the block submission needs to be changed. And > maybe you could output a copy of the submitted text too just incase > you didn't have a copy written elsewhere. Something wrong with your browser's back button? :) -- Collin Grady Stay together, drag each other down. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: RegexURLResolver.resolver can fall through and return None
Andreas Klöckner said the following: > Well, then the web site should hint at this fact, too. I was fairly close to > just abandoning the effort of trying to tell you about the issue I > encountered. It does. Quite clearly at the top of the 'new ticket' page, there are several notes about filing tickets, including this one: # If you're getting rejected by the spam filter, we apologize! The best way to avoid that is to register for an account and make sure you're logged in. -- Collin Grady --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: more DDN Tickets
Jeff Anderson said the following: > #4118 Do you have the wrong # here? That ticket is closed: duplicate :) -- Collin Grady It was a brave man that ate the first oyster. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: List of DDN Tickets
AmanKow said the following: > Actually, 'required' is an argument to the *Model* field constructor, > and models are *not* always initialized from html forms. The field > certainly doesn't have to be represented as a checkbox in a form, > either. This is incorrect. Model fields have null and blank arguments, form fields have required. -- Collin Grady A chicken is an egg's way of producing more eggs. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: List of DDN Tickets
Can I recommend http://code.djangoproject.com/ticket/4102 for the list? :) -- Collin Grady Bumper sticker: All the parts falling off this car are of the very finest British manufacture. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Bug in mod_python
Peter Melvyn said the following: > I see - is there a way how to pass such URL via Google interface? http://tinyurl.com ? :) -- Collin Grady If at first you don't succeed, you're doing about average. -- Leonard Levinson --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Latest Comments
Usage questions belong on the django-users list, not here - this list is for discussion of the development of django itself :) -- Collin Grady --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: django.db.connection request - add a key
hiwd said the following: > 'index': self.db.queries.__len__() Shouldn't that be len(self.db.queries) ? :) -- Collin Grady We are not anticipating any emergencies. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Request for review
Not sure exactly how to phrase this, but James told me to bring these tickets up here to get some feedback on them - such as what exactly needs done to bring them to 'ready for checkin' as myself and others would like to get them in :) I did the basics of making sure the patches were updated, but feedback would be appreciated. Minor, quick performance enhancements: http://code.djangoproject.com/ticket/3460 http://code.djangoproject.com/ticket/3461 http://code.djangoproject.com/ticket/3575 Slightly larger, but also a good enhancement: http://code.djangoproject.com/ticket/4102 The first three are the big ones I'd like to help finish, but 4102 would also be very nice :) -- Collin Grady "We came. We saw. We kicked its ass." -- Bill Murray, _Ghostbusters_ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Is there a django meta model ?
Jean-Christophe Kermagoret said the following: > I need this meta model to generate automatically django code from models. > > If there is no meta model, is there presently some code which would > permit to have code automatically generated from xml (or properly > properties) configuration files ? Usage questions like this belong on the django-users list :) This list is for the development of django itself. -- Collin Grady --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Response to "Shortcutting render_to_response"
Nathaniel Whiteinge said the following: > Either way, this is a bike-shed issue. In fact, he can simply do this: from django.views.generic.simple import direct_to_template as render_response and get the name he wants without patching anything :) -- Collin Grady --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Probable bug in templates - default tags not always loading properly
[EMAIL PROTECTED] said the following: > Yep, I just did it, how are you guys starting the python interpreter? python no manage.py, no ipython, nothing special, except my env has DJANGO_SETTINGS_MODULE set right -- Collin Grady I had the rare misfortune of being one of the first people to try and implement a PL/1 compiler. -- T. Cheatham --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Probable bug in templates - default tags not always loading properly
Trevor Caira said the following: > Are you sure you're importing both Template and Context? I get the > same error as OP. I don't have to import Context to trip this, only Template -- Collin Grady Since a politician never believes what he says, he is surprised when others believe him. -- Charles DeGaulle --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Probable bug in templates - default tags not always loading properly
User reported an issue, http://code.djangoproject.com/ticket/7377 Alex keeps closing it, but this appears to be a valid bug, which I can duplicate every time I open a python shell: http://dpaste.com/55054/ As posted in the ticket, it appears that the default tags are not loaded until the file loader.py is parsed - so if you import Template and Context, they don't work, yet the moment you import loader, they do - is this an intentional decision, or a valid issue? -- Collin Grady ...[Linux's] capacity to talk via any medium except smoke signals. -- Dr. Greg Wettstein, Roger Maris Cancer Center --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: ERROR:cannot import name Post -- while using django signals
Usage questions belong on django-users - this list is for the development of django itself. -- Collin Grady --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Object list with values to ForeignKey and ManyToMany
Usage questions such as this should go to the django-users mailing list. The django-developers list is for the development of django itself, not just for developers who use django. -- Collin Grady Some people live life in the fast lane. You're in oncoming traffic. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: document based database
bedros said the following: > are you guys aware of any document based database open source > implementation in Python such as strokeDB for Ruby This question does not belong on this list - this list is for the discussion of the development of django itself, not for other questions. -- Collin Grady The nation that controls magnetism controls the universe. -- Chester Gould/Dick Tracy --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django vs. Oracle application
Arif Chowdhury said the following: > I am newbe here and for Django as well. I wanna upgreade my previous > applications that are built on php/oracle into dgango. could you > please anybody guide me the real life gui application development > steps by dgango/oracle. This question would fit better on django-users - the django-developers list is for development of django itself, not general topics regarding developing with django. -- Collin Grady And ever has it been known that love knows not its own depth until the hour of separation. -- Kahlil Gibran --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: On aggregates
David Cramer said the following: > DISTINCT and GROUP BY are both annotating the results. Taking many rows, > and turning them into a single row based on a key. DISTINCT would be the > same as GROUP BY every, field, in, the, select. But forcing people to group by every field they select in order to get distinct is absolutely idiotic, so why even suggest it? .distinct() maps to DISTINCT, and even if in some way its identical, there's no harm leaving it for the ease of use. -- Collin Grady "If you don't want your dog to have bad breath, do what I do: Pour a little Lavoris in the toilet." -- Comedian Jay Leno --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: On aggregates
David Cramer said the following: > If that is the case, then annotate would replace GROUP BY, and should > also be able to replace distinct(). Why would replacing distinct() ever make any sense? -- Collin Grady --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Paginator Backwards Compatibility Post
SmileyChris said the following: > You were using a new feature (albeit the wrong one) so that's not > really a backwards incompatible issue, is it? The old ObjectPaginator class is going away though, isn't it? That sounds like backwards incompatible to me ;) -- Collin Grady Computer programmers never die, they just get lost in the processing. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django port on OpenVMS - Oracle/Rdb backend
Steve Holden said the following: > PS: Completely off-topic apart from the "Teach Me Google", can anyone > tell me why Google Groups/Gmail isn't sending me my own messages? AFAIK it just doesn't do that - I just set my client to copy my replies to django-dev into my inbox so that they're threaded in. -- Collin Grady Measure with a micrometer. Mark with chalk. Cut with an axe. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django port on OpenVMS - Oracle/Rdb backend
Steve Holden said the following: > If you want considered opinions you would do well to wait longer than 51 > minutes! You should check the date as well as the time; he sent the first email *two days* before the second. -- Collin Grady BOFH excuse #244: Your cat tried to eat the mouse. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: QSRF Related
David Cramer said the following: > If I update from python 2.4 to 2.5 I can expect some trouble unless I know > what has changed. If I update trunk, which is what is considered the only > real version to use right now, I may encounter problems that I wasn't > expecting, especially since the closest thing to a changelog is svn log. You just need to correct your understanding of tracking trunk - you can not expect to be able to update blindly and have things not break. Until 1.0 lands, backwards incompatible changes *will* happen, so you must expect that "svn up" may break your code, especially if you're using undocumented internals. -- Collin Grady A professor is one who talks in someone else's sleep. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: QSRF Related
David Cramer said the following: > 3) Most importantly. Is there a shiny new page in the documentation > that I don't see tagged somewhere that explains the new functionality? > If so, can we tag it as "Updated" or whatever is appropriate :) The doc pages were updated with qsrf, so when it merged, all the new docs were merged in also, just mixed in with the normal db-api and model-api pages, among others. -- Collin Grady Give a man a fish, and you feed him for a day. Teach a man to fish, and he'll invite himself over for dinner. -- Calvin Keegan --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Newforms DateField/DateTimeField initial value rendering
Simon Litchfield said the following: > Tad ugly though, don't you think? Most platforms/languages/frameworks > handle the MDY/DMY situation relatively elegantly using some kind of > setting. Well I wasn't pitching it as the best solution, just *a* solution :p -- Collin Grady Of all forms of caution, caution in love is the most fatal. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Newforms DateField/DateTimeField initial value rendering
Simon Litchfield said the following: > No control is given over how initial date/datetime values are > rendered, using DateField/DateTimeField. > > Clients don't like -MM-DD; who can argue? > > At the very least, I propose we at least allow an optional > display_format string, kinda like input_formats. I haven't tried to use it, but couldn't a DateTimeInput widget with those fields solve the problem? It accepts a format arg which is how it will render its data - combined with the right input_formats in the field, it stands to reason that would work :) -- Collin Grady We reject: kings, presidents, and voting. We believe in: rough consensus and working code. -- Dave Clark --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: django.contrib.sessions problems
Mike Axiak said the following:
> Let me reiterate a position that I posted on #6941. After reviewing, I
> actually *don't* think we're all that muddled. A session is
> {{{request.session}}} and is represented by the browser's session.
> Whereas a user is {{{request.user}}} and is completely separate.
Except request.user is loaded by using a user id stuffed in session, so they
are
definitely tied together right now :)
--
Collin Grady
The reward of a thing well done is to have done it.
-- Emerson
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Pick a value from list variable in templates
Matthew Marshall said the following:
> What's wrong with ``{{ foo[bar] }}`` ?
>
> That's how it's done in python, javascript, php, and others. Most people
> writing html templates will be somewhat familiar with at least Javascript.
To keep things consistent though, you'd then likely have to change normal
access
to work like that as well, so instead of foo.bar to look up the key "bar" you'd
have to change it to use foo["bar"], which would be backwards incompatible -
otherwise you'd end up with two syntaxes for the same action, just one being a
variable and the other a string.
--
Collin Grady
Albrecht's Law:
Social innovations tend to the level of minimum tolerable well-being.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Pick a value from list variable in templates
vcc said the following: > I got another ID: foo.(bar) > It's clear and no conflict, also can use nested, for example > foo.(one.(tow.(three))). > or maybe: foo(bar) is look better. But that suffers the same issue as the __bar__ syntax - it's already used by function calls - you need to stop trying to use things with double meanings :) -- Collin Grady War is peace. Freedom is slavery. Ketchup is a vegetable. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Pick a value from list variable in templates
vcc said the following:
> How about: {{ foo.__bar__ }} ?
Except you can't use _ as the first character in a template lookup like that,
and the __foo__ naming method is already taken by existing things like __get__,
__contains__, and other such methods/attributes :)
--
Collin Grady
Necessity is the plea for every infringement of human freedom.
It is the argument of tyrants; it is the creed of slaves.
-- William Pitt, 1783
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: Ticket #6705
Dj Gilcrease said the following: > On Tue, Mar 4, 2008 at 10:59 AM, James Bennett <[EMAIL PROTECTED]> wrote: >> Thoughts? > > he cant do something like http://dpaste.com/38006/ ? Should probably be field.label instead of field.label_tag, no? :) -- Collin Grady "I don't think so," said Descartes. Just then, he vanished. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Pick a value from list variable in templates
Luke Plant said the following:
> It is already in core. See:
> http://www.djangoproject.com/documentation/templates/#variables
No, it isn't - {{ foo.bar }} is the same as foo['bar'] not foo[bar], so it
won't
do what they're talking about - they want to have a variable bar as, say, 3,
and
have a way to do foo.bar where it's really doing foo.3
Hence the filter looking it up by the value of the variable, not as a string.
--
Collin Grady
"Fantasies are free."
"NO!! NO!! It's the thought police"
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: ADMIN_MEDIA_PREFIX default value (#2891)
Collin Grady said the following: > The ticket is still "Closed: wontfix" which looks ignored to me :) It's been pointed out to me that the tone of my messages could come off a bit rude - I did not intend that, and I apologize if that is the case. -- Collin Grady The reader this message encounters not failing to understand is cursed. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: ADMIN_MEDIA_PREFIX default value (#2891)
Malcolm Tredinnick said the following: > It's hardly been ignored. There was quite a spirited thread last time it > came up. The ticket is still "Closed: wontfix" which looks ignored to me :) -- Collin Grady Just remember, wherever you go, there you are. -- Buckaroo Bonzai --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
ADMIN_MEDIA_PREFIX default value (#2891)
I wanted to bring this issue[1] up again, as it's still constantly causing issues for people - I seem to help at least 1 or 2 people every single week having problems with their media because they tried to setup static.serve to the same URL as ADMIN_MEDIA_PREFIX I still believe that this will not impact many people at all if changed, since the default settings.py files generated for at least a year had ADMIN_MEDIA_PREFIX hard-coded in it, so a change to the default couldn't hurt anything. People have posted before that we shouldn't be focusing on this while larger issues are open, but we're only focusing on it because it's been ignored, and it's wasting far more time for the users who constantly hit the issue due to the poor default setting. [1] http://code.djangoproject.com/ticket/2891 -- Collin Grady Matter will be damaged in direct proportion to its value. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Form as Table
Django-fan said the following: > Is there a way in Django to generate webforms from a simple Database > table so that we can "submit" the user inputs to update a database > table. In other words, I would like to create a webform on an existing > database table. Questions of this nature should be directed to the django-users list. This list is for the discussion of the development of django itself, not on how to do things using it :) -- Collin Grady BOFH excuse #101: Collapsed Backbone --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: newsform Addition
Rock said the following:
> Some thoughts:
>
> Inplementing form.as_items returning a list of form lines would be
> nice.
> This allows a variety of custom formatting options. Examples:
>
>
> {% for item in forms.as_items }}{{ item }} , {% endfor %}
> <...submit directive...>
>
>
>
> {{ item[0] }} -- {{ item[1] }} -- {{ item[2] }}
> {{ item[3] }}
> {{ item[4] }}
>
These can already be done, just loop over the form, or use the manual
items like {{ form.fieldname }}, {{ form.fieldname.label_tag }},
{{ form.fieldname.errors }}, etc
--
Collin Grady
Two wrongs don't make a right, but they make a good excuse.
-- Thomas Szasz
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: [7084] extends headaches
David Larlet said the following: > I'd just updated my local version of django and it raises errors due > to 7084 changeset (extends should be the first tag). I put all my > extends tags above all my load tags in every templates and I realize > that it raises errors for comment tags too... I used to keep svn infos > at the top of every file and now I need to put extends tag at the top > of every templates, a bit annoying. I understand that it avoids some > errors but I think that we could make an exception for comment tags > and maybe load tags too. Any thoughts? The extends tag was always supposed to be the first tag in a file - this has been documented for many versions now. If it happened to work before, *that* was the bug, and so there's no change in expected behavior, merely a bugfix that let you break it before :) As such, I don't see that this is a backwards incompatible change, myself. -- Collin Grady All celebrity voices impersonated. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: #django registration
Jeremy Dunck said the following: > On Dec 28, 2007 11:35 AM, Adrian Holovaty <[EMAIL PROTECTED]> wrote: >> I'm happy to take care of this -- I just don't know what's involved in >> registering a channel. Could you provide some more information on whom >> to talk to about getting it done? > > http://freenode.net/group_registration.shtml Monthly bump ;) -- Collin Grady --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Unicode usernames?
John Hensley said the following: > What's the consensus on Unicode usernames? Personally, I'd love to see the username validation expanded - unicode, email addresses, etc, are all fair game in my opinion :) Registration forms could easily be limited if people wanted to restrict allowed characters, but you can't really go the other direction :) -- Collin Grady Pause for storage relocation. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
ModelForms w/no pre-set model
In a previous thread [1], there was talk of allowing ModelForm to work
without a model hard-coded, so it would base it off the instance passed
to the form.
However, on trying to make that work, it seems that something may have
been left out of the previous patch - if I don't include a model, it
never creates any fields, regardless of whether or not I specify fields
or exclude, and if I leave out model and don't pass instance, I get the
previously discussed "NoneType is not callable error", which should've
been fixed by the previous patch if I'm reading the thread right :)
Did something get left out of that last fix, or has it broken recently?
Alternatively, am I simply doing it wrong? :)
My simple test is merely this:
class NameEditForm(ModelForm):
class Meta:
fields = ('name',)
and I then try to use it on a model with a 'name' field, but nothing works.
[1]http://groups.google.com/group/django-developers/browse_thread/thread/8774da1fd5b77eb1
--
Collin Grady
Anyone can make an omelet with eggs. The trick is to make one with none.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
#django registration
I've never bothered bringing this up before as it's never really been needed, but tonight we had someone with a rogue script in their IRC client which prevented them from closing their client, and flooded the channel with "hello world" for a minute and a half solid :) It would've been very helpful to have ops in the channel to boot him after it started until he fixed it, but as the channel is currently unregistered, we had to just wait it out :) I understand that people are likely still on vacation right now, and it isn't urgent that it be done soon, I just wanted to bring it to mind so maybe it could be dealt with in the new year if someone has some spare time :) -- Collin Grady "If anything can go wrong, it will." -- Edsel Murphy --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Simple Generic Views, Login_Required
kevinski said the following: > That is most definitely the smartest way to do it, however we are > still stuck on Python 2.3 at my work. I suppose I may need to rely on > my hack until the powers that be see fit to upgrade to 2.5 or 3.0 or > whatever. That changes nothing except the syntax used. However, with svn, you can inline the login_required right in urls.py; from django.views.generic import simple #... (r'^foo/$', login_required(simple.direct_to_template), info_dict), -- Collin Grady Hearts will never be practical until they can be made unbreakable. -- The Wizard of Oz --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Odd MySQL bug
AmanKow said the following: > Well, the value of this can be accessed via: > SELECT @@session.sql_auto_is_null; > which gets you the result of 1 > If you then perform a > SET SESSION sql_auto_is_null=0; > and perform the above query again, the value is. 1 > As I mentioned earlier, it isn't dynamic anyway, so even if it changed > to 0 the default behavior wouldn't change. Why are you including the "SESSION" in your SET statement? mysql> SELECT @@SESSION.SQL_AUTO_IS_NULL; ++ | @@SESSION.SQL_AUTO_IS_NULL | ++ | 1 | ++ 1 row in set (0.00 sec) mysql> SET SQL_AUTO_IS_NULL=0; Query OK, 0 rows affected (0.00 sec) mysql> SELECT @@SESSION.SQL_AUTO_IS_NULL; ++ | @@SESSION.SQL_AUTO_IS_NULL | ++ | 0 | +--------+ 1 row in set (0.00 sec) -- Collin Grady (1) Never draw what you can copy. (2) Never copy what you can trace. (3) Never trace what you can cut out and paste down. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Odd MySQL bug
AmanKow said the following: > Any mysql gurus out there with some advice as to how to turn off this > behavior? The mysql docs and several things I've found online (including code from Rails) indicates that simply "SET SQL_AUTO_IS_NULL=0" should work, unless they broke it :) -- Collin Grady The past always looks better than it was. It's only pleasant because it isn't here. -- Finley Peter Dunne (Mr. Dooley) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Reconsider ADMIN_MEDIA_PREFIX default?
Malcolm Tredinnick said the following: > I'm basically -0 on the change (maybe a bit more than that) and since > it's not mountain-out-of-molehills month, I figure we can live with > things as they are and not imposing unnecessary breakage on our > userbase. With respect, I think it should be necessary. Using poor defaults that cause problems when people try to use the common sense path for media mapping is worse than a one time tiny change that requires the rare person to add one more setting. Seeing as how 'django-admin.py startproject' creates a default settings.py template that includes a value for ADMIN_MEDIA_PREFIX, I think you're overestimating how many people would actually be impacted, since I think most of them would be using a file based on that :) -- Collin Grady In space, no one can hear you fart. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Better Support for static file serving via django
Mike Scott said the following: > Is this an approach the bulk of the Django community are interested in > taking or is it something that we should leave to the things that do it > best, ie: Apache and the like. -1 to handling media through Django, that's the job of the webserver :) -- Collin Grady --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Models to keep a copy of their last saved values?
http://code.djangoproject.com/ticket/4102 -- Collin Grady If condition persists, consult your physician. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: ModelForm.__init__() argument signature versus other newforms forms
Joseph Kocherhans said the following: > I'm close to checking this in and adding a note to > BackwardsIncompatibleChanges, but I'm still a little uneasy about > generating the form fields at form instantiation time. It just feels > weird to me, but I can't really come up with any actual reasons why. I > mean, I think the functionality is neat, but I'm not comfortable with > the syntax. Looking at the latest patch, I don't think it ended up supporting that - it instead only uses the fields defined in the common form, no fields/exclude args required. Though admittedly, I don't know ModelForms very well yet, so I could be missing something :) -- Collin Grady Earth is a beta site. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: django and plesk vhosts.conf
Use/setup/etc questions should be directed to django-users, as django-developers is for the discussion of the development of django itself :) -- Collin Grady Paranoia is heightened awareness. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Best way to update only certain fields on a model instance?
Johann C. Rocholl said the following: > I have come up with this kludge: > http://www.djangosnippets.org/snippets/479/ > Should I turn this into a patch and submit it? No, this will be covered by 4102. > What's the status of ticket 4102? > (Allow UPDATE of only specific fields in model.save()) It's still open and we're still working on getting some form of it included, which would solve your issue :) One of the first two patches on 4102 would likely allow you to do what you're after without the kludge involving manual sql - the first two are the explicit form where you tell it what to save, while the later ones auto-detect modified fields. -- Collin Grady --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Getting Images to display in Development Environment
Don Spaulding said the following: > into the irc channel (#python on irc.freenode.net) to get the help I think you mean #django on irc.freenode.net :) -- Collin Grady --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Python history won't work in Django shell (maybe found bug?)
Deryck Hodge said the following: > It's the variable that says whether or not the option --plain was > used. It determines whether the normal Python shell is used or > iPython. iPython is used if available unless --plain is set. Hmm, that sounds like a bug then, as this happens even when ipython isn't present, so it should be parsing the normal stuff in that case, right? -- Collin Grady A robin redbreast in a cage Puts all Heaven in a rage. -- Blake --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Model post_save doesn't play well with Model.save overriding
Jeremy Dunck said the following: > I feel OK about having to manually call post_save when I override > Model.save, but adding it now just results in post_save being called > twice. Couldn't you just fire your own signal? :) -- Collin Grady --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: DecimalField returns default value as unicode string.
[EMAIL PROTECTED] said the following: > Not sure why, but when I tried to submit a ticked for this it was > rejected repeatedly as suspected spam. If you register for a trac account it should avoid that issue. -- Collin Grady Academic politics is the most vicious and bitter form of politics, because the stakes are so low. -- Wallace Sayre --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Overriding a Model's save() method does not allow proper creation of ManyToMany related objects
Dmitri Fedortchenko said the following: > Well django does recommend using the admin for everything admin-related, > if I stop using the admin for editing an article, then I would have to > write a whole bunch of code just to edit a single article. Suddenly the > benefit of a unified admin interface is lost and I have to deal with > permissions, UI, validation, forms.. it seems like a nightmare for > something should work in the first place... ( i.e. overriding the save() > method to add extra functionality) > > From the django features list: > A dynamic admin interface: it's not just scaffolding it's the whole house > [The philosophy here is that your site is edited by a staff, or a > client, or maybe just you and you don't want to have to deal with > creating backend interfaces just to manage content.] > > The message seems clear to me. ;) It's not meant to do absolutely everything though - trying to hack it to do something it doesn't is usually harder than writing a really simple custom view :) -- Collin Grady If I had any humility I would be perfect. -- Ted Turner --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Overriding a Model's save() method does not allow proper creation of ManyToMany related objects
Dmitri Fedortchenko said the following: > Still, the most logical course is to override the save method. I'd say the more logical course is to stop using admin for this ;) -- Collin Grady QOTD: "If I'm what I eat, I'm a chocolate chip cookie." --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Overriding a Model's save() method does not allow proper creation of ManyToMany related objects
Are you seeing this behavior in admin? If so, I believe that is what is actually at fault, since it hard-sets m2ms, which would clear anything set in save(). Also, you don't need to call save() again after adding to an m2m, since it does not edit the model instance itself, but the related table. -- Collin Grady Haste makes waste. -- John Heywood --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Proposal: shortcut to display one field from newforms
[EMAIL PROTECTED] said the following:
> 1) just form.FIELDNAME. It's quite obvious and is not occupied by
> anything.
Uh, yes it is :)
{{ form.foo }} prints the input for the foo field
> 2) form.show_FIELDNAME
> 3) form.show(FIELDNAME), where FIELDNAME is a string. But this one
> can't be used from templates, can it?
>
> Maybe there should be options for a person to choose from different
> methods to render the form, like:
> form.show_as_p_FIELDNAME
Seems like this would make more sense acting like the form generators if
anything, so it'd be {{ form.foo.as_p }} or such, instead of trying to
shove magic methods into the form class, it could just belong to the field.
> I think that this feature will be extremelly useful for people, who
> want their application to be ready as soon as possible, and who don't
> want to either insert chunks of repeating code into their templates or
> write custom inclusion tags.
On the other hand, it's kind of an edge case, since if you're using the
same set of tags for every field, it quite limits the amount of
customized layout you can do :)
--
Collin Grady
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: OverflowError: mktime argument out of range
Please don't post questions to both django-users and django-dev. Django-users is for general help questions such as this, while django-dev is for discussion of the development of django itself, not help questions :) -- Collin Grady --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Another urlpatterns proposal (add method column)
tonnzor said the following: > As far as I see, reversing url is getting URL for a view. Then, if > view has only one route, there's no need to provide HTTP method. But > if there are > 0 routes to the same view, we can add optional METHOD > option. Or just make people use named URLs, which is already the solution for multiple routes to the same view :) -- Collin Grady When a person goes on a diet, the first thing he loses is his temper. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Display name for Models in admin
sixpackistan said the following: > i apologize ahead of time if this seems like a stupid question- but i > have tried repeatedly to find an answer without having to post. > In any event, i have a model defined called 'ItemStatus' which is > displayed in the django admin as "Item statuss"- is there a way, short > of renaming my model class, to change how the model name appears in > the admin? This question is more suited for django-users - this list is for the development of django itself, not general help questions :) -- Collin Grady --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
