Re: attribute__isnull=True vs attribute__exact=None (Ticket 2737)
Russell Keith-Magee schrieb: > Ticket 2737 requests a feature where __exact=None would be interpreted > as __isnull=True. This would fix all three problems I have described. > The proposed patch isn't correct, but I feel the idea is valid. My brain has been wired in SQL mode, perhaps for too long, so I consider __exact=None as the equivalent of ... WHERE ...=NULL, which gives an empty result set. Perhaps this comes to a surprise for an SQL newbie, but it is seriously my intuitive expectation, being consistent with the SQL boolean algebra. Well. If it's only me, ignore me, it would still be an improvement above the current situation, and I probably can get over it ;-) Michael --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Re: attribute__isnull=True vs attribute__exact=None (Ticket 2737)
On 10/12/06, Michael Radziej <[EMAIL PROTECTED]> wrote: > > Russell Keith-Magee schrieb: > > Ticket 2737 requests a feature where __exact=None would be interpreted > > as __isnull=True. This would fix all three problems I have described. > > The proposed patch isn't correct, but I feel the idea is valid. > > My brain has been wired in SQL mode, perhaps for too long, so I > consider __exact=None as the equivalent of ... WHERE ...=NULL, > which gives an empty result set. Perhaps this comes to a surprise > for an SQL newbie, but it is seriously my intuitive expectation, > being consistent with the SQL boolean algebra. Sorry - I'm confused; Are you agreeing with the proposed change, or saying it contradicts your expectations? (I think you are agreeing - I just want to make sure) Yours, Russ Magee %-) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: attribute__isnull=True vs attribute__exact=None (Ticket 2737)
Russell Keith-Magee: > Sorry - I'm confused; Are you agreeing with the proposed change, or > saying it contradicts your expectations? (I think you are agreeing - I > just want to make sure) My highest preference is to make __exact=None behave like WHERE xxx=NULL, i.e. returning an empty set, against current behaviour *and* against your proposal. My middle preference is what you propose: making __exact=None a replacement for __isnull=True. My lowest preference is to keep it as it is: ignore __exact=None Please, excuse me for being so complicated today ;-) Michael --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Adding Polls to admin
I am having difficulty getting the Polls or any information to show in the admin while following the tutorial (2) on the django web site. I have re-installed the tables and verified the code. Any thoughts? Thank you, Josh --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Extract HTML code from FormFields to Templates
Hallo. I have noticed that in the django forms classes, for example django.forms.TextField there is HTML code embedded into the Python code. I thougt about extracting all this code to Django Templates. But since I don't know if this is useful I wanted to ask you. I see the following pros/cons. Pro: - Easier to customize form fields - Better separation of logic and view Con: - Maybe an overkill and to expensive The idea came while I wanted to add some Javascript functionality to my form fields. Thanks Pascal --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
looking for a django partner
Hi, I'm an application developer ( front end, presentation tier stuff ) who has recently learned and fell in love with python. I've been creating software for other ppl for many years and I'd like to start my own company. If you are a like minded python or django developer feel free to contact me at [EMAIL PROTECTED] for a partnership Thanks, jay --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: greater_than and less_than template filters
Here are some simple math functions that we found useful for templates as well: from django import template register = template.Library() @register.filter() def mul(value, arg): return value * arg @register.filter() def add(value, arg): return value + arg @register.filter() def div(value, arg): if arg is None: return 0 elif arg is 0: return 0 else: return value / arg @register.filter() def subtract(value, arg): return value - arg @register.filter() def percent(value): return str(round(value * 100, 2)) + " %" @register.filter() def floatformat2(text): """ Displays a floating point number as 34.2 (with one decimal place) -- but only if there's a point to be displayed """ try: f = float(text) except: return text m = f - int(f) if m: return '%.1f' % f else: return '%d' % int(f) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: greater_than and less_than template filters
On 10/11/06, Le Roux Bodenstein <[EMAIL PROTECTED]> wrote: > > I wrote some filters On 10/12/06, Tim <[EMAIL PROTECTED]> wrote: > > Here are some simple math functions that we found useful for templates > as well: > Both of you should post those in the cookbook [1] on the wiki so they don't get lost in the archives here on the list. [1]: http://code.djangoproject.com/wiki/CookBookTemplateFilters --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Find the Cookie owner
Hi, I'm writing a code for a media server and I want to serve static
files to authenticated users only. I check against Django's session
table (django_session) and that's ok (IMO) but in session_data there
isn't the userid and I need it for security reasons; So I sent you
what I'm doing so far and please, I'd really like that someone can
help me a bit if you please.
Many thanks!
PS: Greetings from Chile.
--
http://www.advogato.org/person/mgonzalez/
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
from mod_python import apache, Cookie
from os import environ
def accesshandler(req, **kwargs):
"""
(Was) Authentication handler that checks against Django's auth database.
(Is) Access handler that check agains Django's session table
"""
options = req.get_options()
settings_module = options.get('DJANGO_SETTINGS_MODULE', None)
if settings_module:
environ['DJANGO_SETTINGS_MODULE'] = settings_module
else:
return apache.HTTP_FORBIDDEN
cookies = Cookie.get_cookies(req)
if cookies.has_key('sessionid'):
django_sessionid = cookies['sessionid'].value
else:
return apache.HTTP_FORBIDDEN
from django import db
db.reset_queries()
cursor = db.connection.cursor()
sql = """
SELECT session_data
FROM django_session
WHERE expire_date > now()
AND session_key = '%s'
""" % django_sessionid
cursor.execute( sql )
session = cursor.dictfetchone()
sessionid_is_found = False
if len(session['session_data']) > 0:
sessionid_is_found = True
if not sessionid_is_found:
return apache.HTTP_FORBIDDEN
import base64
a = base64.decodestring( session['session_data'] )
#who is the owner of this cookie??!
#cause in session['session_data'], is not
req.write(a)
return apache.HTTP_UNAUTHORIZED
Re: Find the Cookie owner
You'll probably find it much easier to use Django to serve those static
files, rather than trying to duplicate Django functionality in
modpython.
--Ned.
Mario Gonzalez ( mario__ ) wrote:
Hi, I'm writing a code for a media server and I want to serve static
files to authenticated users only. I check against Django's session
table (django_session) and that's ok (IMO) but in session_data there
isn't the userid and I need it for security reasons; So I sent you
what I'm doing so far and please, I'd really like that someone can
help me a bit if you please.
Many thanks!
PS: Greetings from Chile.
from mod_python import apache, Cookie
from os import environ
def accesshandler(req, **kwargs):
"""
(Was) Authentication handler that checks against Django's auth database.
(Is) Access handler that check agains Django's session table
"""
options = req.get_options()
settings_module = options.get('DJANGO_SETTINGS_MODULE', None)
if settings_module:
environ['DJANGO_SETTINGS_MODULE'] = settings_module
else:
return apache.HTTP_FORBIDDEN
cookies = Cookie.get_cookies(req)
if cookies.has_key('sessionid'):
django_sessionid = cookies['sessionid'].value
else:
return apache.HTTP_FORBIDDEN
from django import db
db.reset_queries()
cursor = db.connection.cursor()
sql = """
SELECT session_data
FROM django_session
WHERE expire_date > now()
AND session_key = '%s'
""" % django_sessionid
cursor.execute( sql )
session = cursor.dictfetchone()
sessionid_is_found = False
if len(session['session_data']) > 0:
sessionid_is_found = True
if not sessionid_is_found:
return apache.HTTP_FORBIDDEN
import base64
a = base64.decodestring( session['session_data'] )
#who is the owner of this cookie??!
#cause in session['session_data'], is not
req.write(a)
return apache.HTTP_UNAUTHORIZED
--
Ned Batchelder, http://nedbatchelder.com
--~--~-~--~~~---~--~~
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 -~--~~~~--~~--~--~---
[Fwd: Re: more fun with custom fields]
forwarding to dev list from -users, since it fits dev better the original thread: http://groups.google.com/group/django-users/browse_thread/thread/fdc940db9fd9d7a0/4a966c68c0036854?lnk=raot --B --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- --- Begin Message --- ok, I made this change to the Model.__init__() method. at the very end: for i, arg in enumerate(args): + if hasattr(self._meta.fields[i], 'translate_from_db') and arg: + arg = self._meta.fields[i].translate_from_db(arg) setattr(self, self._meta.fields[i].attname, arg) this just checks to see if the field has a method to translate the value. In my case, I use it to change the value from '01012073203E403E40' to (30.0, 30.0) which I think is much nicer. So, is this something that could reasonably be put into Django? It would allow me (and others) to add more complex custom fields without having to modify the Django core code. --B --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users -~--~~~~--~~--~--~--- --- End Message ---
Re: greater_than and less_than template filters
For the first three, it would be simpler (and I guess faster) to do: (I haven't tested this, but it should work.) from django import template import operator register = template.Library() register.filter( 'mul', operator.mul ) register.filter( 'add', operator.add ) register.filter( 'div', operator.div ) register.filter( 'sub', operator.sub ) Adam. On 10/12/06, Tim <[EMAIL PROTECTED]> wrote: > > Here are some simple math functions that we found useful for templates > as well: > > from django import template > register = template.Library() > > > @register.filter() > def mul(value, arg): > return value * arg > > @register.filter() > def add(value, arg): > return value + arg > > @register.filter() > def div(value, arg): > if arg is None: > return 0 > elif arg is 0: > return 0 > else: > return value / arg > > @register.filter() > def subtract(value, arg): > return value - arg > > @register.filter() > def percent(value): > return str(round(value * 100, 2)) + " %" > > @register.filter() > def floatformat2(text): > """ > Displays a floating point number as 34.2 (with one decimal place) > -- but > only if there's a point to be displayed > """ > try: > f = float(text) > except: > return text > m = f - int(f) > if m: > return '%.1f' % f > else: > return '%d' % int(f) > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: Extract HTML code from FormFields to Templates
On Sat, 2006-10-07 at 15:40 -0700, Pascal Bach wrote: > Hallo. I have noticed that in the django forms classes, for example > django.forms.TextField there is HTML code embedded into the Python > code. I thougt about extracting all this code to Django Templates. > But since I don't know if this is useful I wanted to ask you. I see the > following pros/cons. > > Pro: > - Easier to customize form fields If you want to customize, you can subclass. > - Better separation of logic and view The form field classes are fairly heavily concerned with presentation. There comes a point when separating every little piece out becomes a bit of overkill. It becomes complex to maintain and the processing overhead increases. > Con: > - Maybe an overkill and to expensive Agreed. > The idea came while I wanted to add some Javascript functionality to my > form fields. I really don't think this is worth the downside. Subclassing is trivial. None of the render methods are more than a dozen lines long, so if you want to change one of them, you aren't wading into hundreds of lines of code to work out what you want to do. Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: [Fwd: Re: more fun with custom fields]
Hey Bryan, On Thu, 2006-10-12 at 20:29 -0400, Bryan L. Fordham wrote: > forwarding to dev list from -users, since it fits dev better Yes, probably does now. [...] > > ok, I made this change to the Model.__init__() method. at the very end: > > > > for i, arg in enumerate(args): > > + if hasattr(self._meta.fields[i], 'translate_from_db') and arg: > > + arg = self._meta.fields[i].translate_from_db(arg) > > setattr(self, self._meta.fields[i].attname, arg) > > > > this just checks to see if the field has a method to translate the value. > > In my case, I use it to change the value from > > '01012073203E403E40' to (30.0, 30.0) which > > I think is much nicer. > > > > So, is this something that could reasonably be put into Django? It would > > allow me (and others) to add more complex custom fields without having to > > modify the Django core code. This is exactly the sort of change I was thinking of (note that it took exactly two lines :-) ). Not sure if it covers all cases at the moment, but you're definitely on the right track. I'm not a huge fan of the method name. Remember that the __init__ method is also called when you initialise an instance from a program (e.g. during a form submission). The caller passes in a Python object of some description (string, integer, date, elephant, ...) and this method converts it to some other object instance. So we're not always converting from the database. If I was a professional, I would offer some alternatives, but I need to think about that. Analogies with the manipulator method names would mean we have "data2python" (urgh :( ) or "data_to_...", which might work. The other thing I had a mental note to check here is that it all works smoothly when saving back to the database and when passing through the serialisation framework. We need to work out what these classes need to offer in terms of a public API (the data-to-python-object method being one thing, but what else?). Without going through the code, my guess would be that a __str__ method that presents the data in a form appropriate for the underlying database field is enough. But people often want to use __str__ for more human-consumable purposes. So we need to think about that (if we don't use __str__, I have a bad feeling there might be multiple places needing changing). I don't have all the serialisation code in my head, so I'm not even going to guess at the requirements there. Performance is not to be ignored in all of this. I doubt that your two line change is going to have much effect on the common case (the case when you aren't using a custom field), but we should check it after progressing a bit further. Anyway, thanks a lot for looking at this (I realise you had some motivation). It's nice to have some confirmation that it might Just Work(tm), although we do need to get round-tripping working before it can go any further. And did I mention test cases and documentation? If you want to keep bashing away on this a bit, feel free to drop subsequent patches into a ticket (assign it to mtredinnick and I'll keep an eye on it). Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: [Fwd: Re: more fun with custom fields]
>This is exactly the sort of change I was thinking of (note that it took >exactly two lines :-) ). Not sure if it covers all cases at the moment, >but you're definitely on the right track. > > heh yeah, I did notice it was two lines. And it probably does not handle all the cases since I'm selfishly only thinking about what I need 8) >I'm not a huge fan of the method name. Remember that the __init__ method >is also called when you initialise an instance from a program (e.g. >during a form submission). The caller passes in a Python object of some >description (string, integer, date, elephant, ...) and this method >converts it to some other object instance. So we're not always >converting from the database. If I was a professional, I would offer >some alternatives, but I need to think about that. Analogies with the >manipulator method names would mean we have "data2python" (urgh :( ) or >"data_to_...", which might work. > > I'm not a fan of the name, either. But I had to call it something. >The other thing I had a mental note to check here is that it all works >smoothly when saving back to the database and when passing through the >serialisation framework. > I did not think about serialisation at all. In my case, I had to tie into the get_db_prep_save() method to translate (in my case) the tuple back to the format the database needs. I would assume anyone else could do that as well, but it wouldn't work with serialisation. I don't know if there's really a problem in my case, since it's just a tuple. But yeah, if you had a sudoku object you'd need a way to serialize it, since something like "<__main__.Sudoku instance at 0x00AE9A30>" wouldn't be too helpful >We need to work out what these classes need to >offer in terms of a public API (the data-to-python-object method being >one thing, but what else?). Without going through the code, my guess >would be that a __str__ method that presents the data in a form >appropriate for the underlying database field is enough. But people >often want to use __str__ for more human-consumable purposes. > Again, in my case, if I used __str__ for the database field, it would be pretty much unusable for anything else. But if it returned the tuple in string format, that would work for the user. My thought on this is that the database-fu should be transparent to the user. So I wouldn't want to use __str__ without a compelling reason. Not to say there aren't compelling reasons. what about the to_python method, in the Field class? I need to go through the code in more depth >So we need >to think about that (if we don't use __str__, I have a bad feeling there >might be multiple places needing changing). I don't have all the >serialisation code in my head, so I'm not even going to guess at the >requirements there. > > I'll have to look at it, though, if I want to pursue this. >Performance is not to be ignored in all of this. I doubt that your two >line change is going to have much effect on the common case (the case >when you aren't using a custom field), but we should check it after >progressing a bit further. > > definately. I don't know if the hasattr() call will have any real impact, but it will of course need to be tested. The hit the data-to-python method causes will depend on what it does, of course >Anyway, thanks a lot for looking at this (I realise you had some >motivation). It's nice to have some confirmation that it might Just >Work(tm), although we do need to get round-tripping working before it >can go any further. And did I mention test cases and documentation? If >you want to keep bashing away on this a bit, feel free to drop >subsequent patches into a ticket (assign it to mtredinnick and I'll keep >an eye on it). > > > documentation?! you act like I have a clue what I'm doing. I'll keep plugging away during lunch and breaks 8) I appreciate you looking at what I've got so far and letting me know I'm not completely off my rocker. I would like to see these issues worked out. As I've said before, I'd love to be able to support adding datatypes without making further changes to django itself. --B --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
order_with_respect_to bug
All my bug reports get classified as spam, so please accept this via email. There's a bug with the order_with_respect_to in that it uses count(*) to determine the value of _order, this works well until you delete more than one object from the middle of the list... in which case a new item which should be at the end isn't. A more correct approach would be to check what the current highest _order value is and increment it. eg. SELECT _order+1 FROM %s WHERE %s = %%s order by _order desc limit 1 I've tested it with mysql using the patch (modified to include the above sql) from http://code.djangoproject.com/ticket/1760 (incidentally, any chance we can have that patch incorporated into django?) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
