Suggestions for inclusion_tag (and a problem with #5034?)
I ran into a problem trying to use inclusgion_tag() in combination with a template that used the url tag with #5034 applied. First, #5034, which patches the url tag to use request.urlconf if it's been set, checks for an instance of RequestContext, rather than the key 'request'. This could be changed, with the assumption that context['request'] should always be a request object. Then, inclusion_tag, unlike the include tag, creates a new context to pass to template.render(), rather than passing the current context. You can pass a context_class to inclusiong_tag, but since RequestContext takes a request, you can't use that. I wonder why inclusion_tag is different than include in this respect. Can't the dict returned by the tag function be pushed onto the current context? That way the template gets the same context class, it behaves more like the include tag, and the code actually becomes simpler. Is there some reason I'm not seeing? Also, is there any chance of #5034 making it into 1.0? I don't know how many user set request.urlconf via middleware, but that is documented, and this patch is critical for using url and reverse(). Thanks, Justin --~--~-~--~~~---~--~~ 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: Bugs in Multi-table inheritance
On Sun, 2008-06-08 at 22:24 -0700, Russell Keith-Magee wrote: > > > On Jun 9, 12:53 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]> > wrote: > > Hi gang, > > > > I've been hunting down some bugs with serialization of multi-table > > inheritance, and I need a sanity check on something that I want to > > check in. > > Aargh. Ignore this message - problem exists between keyboard and > chair. I was reading some debug data from mid-model creation rather > than looking at the final output state of the model. The first > OneToOneField in an inherited model is set as the primary key; it just > happens a little later in the metamodel creation process. Yes, that's correct. It's a little messy flow-wise, but alternatives end up pretty jumbled to. OneToOneField shouldn't be a compulsory primary key, since (a) that's not a semantic requirement and (b) it rules out multi-parents. However, there's no need to add an extra field if we do have at least one-to-one, so the __new__ method does all the setup initially and then, when trolling to see if a primary key is needed, uses any existing parent links as candidates for promotion (it's transparent for the auto-created links, so shouldn't harm anybody). 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?hl=en -~--~~~~--~~--~--~---
Re: RWLock semantics (from ticket #6413)
On Wed, 2008-06-25 at 11:54 +0200, Tomas Kopecek wrote: > Hello, > In django.utils.synch is located RWLock. When you try enter the same > lock twice (probably in some subprocedure) you can't. I think that > correct semantics is that you had acquired this lock in this thread so > you should get it again with no problem. Other (but not preferred) > variant is to check lock if it is already locked for me. This is also > impossible now. What you are describing here is not a read-write lock, but a re-entrant lock. That already exists in Python (threading.RLock). They're separate concepts. 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?hl=en -~--~~~~--~~--~--~---
Re: The block tag has multiple meanings
On Fri, 2008-06-27 at 17:33 +0300, Antonis Christofides wrote: > Hi, > > There are essentially two things that you can do with a block: > (1) define it (or redefine it); and (2) insert it somewhere in a > template. The block tag thus performs different functions depending > on circumstances: > * If a block tag with the same name exists in an inherited >template, then the block tag merely (re)defines the block. > * If no block tag with the same name is inherited, then the block tag >at the same time defines the block AND inserts it in the template. I think this is a mischaracterisation. A block is *always* inserted at the place it is first declared. Its contents can be defined by a child template (via the 'extends' mechanism), but that's all. The base template specifies location and default content; child templates can replace the content. It's not really that confusing. I don't think a change is necessary here. 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?hl=en -~--~~~~--~~--~--~---
Re: More secure user password reset
On Fri, Jun 27, 2008 at 8:31 PM, Simon Willison <[EMAIL PROTECTED]> wrote: > I've got code for this lying round which I'd be happy to donate if > people agree this is the right approach. I personally much prefer this approach. I've worked in a couple communities where personal attacks were quite frequent, and a common tactic was to claim a password was lost on someone else's account. It didn't give them access to the account in question, but it would adequately lock the person out if they happened to visit the site prior to checking their email. Of course, sites like that also tended to have password change forms that accepted GET requests, and didn't have sufficient XSS protection. As you can imagine, wackiness ensued. -Gul --~--~-~--~~~---~--~~ 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
> > The problem with this is it requires state on the server, which means . . . I don't think it's necessary to implement this in such a way that additional server state is stored. Instead, you could let the confirmation token be a hash of the internal user state -- including, most importantly, the user password's salt and encrypted values. That way, the valid confirmation token is 1) known only to the server (the User 'password' field is not externalized), 2) able to be computed at any time without being stashed anywhere, 3) constant until the user changes their password, and 4) guaranteed to change whenever the password is actually changed. -- Scott On Fri, Jun 27, 2008 at 8:12 PM, Luke Plant <[EMAIL PROTECTED]> wrote: > > On Friday 27 June 2008 23:06:57 Collin Grady wrote: > > [EMAIL PROTECTED] said the following: > > 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. > > The problem with this is it requires state on the server, which means > extra database models, and on top of that those tables will need cron > jobs to clear them out or something. This is especially a problem > since hostile users can cause creation of rows in those tables - as > many as they like, just by making a web request - though maybe I'm > just being paranoid now. I wanted to keep the dependencies for this > down to the minimum, and you can always replace it with something > better. > > I'm not familiar with James Bennet's registration app, so I can't > comment on that front. > > Luke > > -- > "I have had a perfectly lovely evening. However, this wasn't it." > (Groucho Marx) > > Luke Plant || http://lukeplant.me.uk/ > > > > -- http://scott.andstuff.org/ | http://truthadorned.org/ --~--~-~--~~~---~--~~ 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
On Jun 28, 1:12 am, Luke Plant <[EMAIL PROTECTED]> wrote: > > [EMAIL PROTECTED] said the following: > > 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. > > The problem with this is it requires state on the server, which means > extra database models, and on top of that those tables will need cron > jobs to clear them out or something. Here's the way I usually solve this problem: send out a link that looks like this: https://example.com/reset/1214612777-34-7127f83ebf8ce7ed22bdc50a50572a30 There are three components to this link: the timestamp that the link was sent out, the user's ID and an md5 hash of (timestamp + user_id + SECRET_KEY). The timestamp is used to enforce a policy that says you must follow the link within 24 hours of it being sent out. The md5 hash guards against tampering. When the user clicks the link, they are taken to a one-time screen that asks them to enter and confirm a brand new password. With the above scheme you don't have to store state on the server and you don't have to generate a random password for the user. For added bonus points, instead of sending the timestamp as a full base 10 integer use hexadecimal and the number of days since the epoch - that allows you to represent the time in just a few characters which can mean your entire reset URL fits within the 72 character line limit imposed by bad e-mail clients such as Outlook (which can't handle URLs that wrap). You can try this scheme out for yourself by going through the lost password recovery process on djangopeople.net: http://djangopeople.net/lost/ I've got code for this lying round which I'd be happy to donate if people agree this is the right approach. Cheers, Simon --~--~-~--~~~---~--~~ 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
On Friday 27 June 2008 23:06:57 Collin Grady wrote: > [EMAIL PROTECTED] said the following: > 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. The problem with this is it requires state on the server, which means extra database models, and on top of that those tables will need cron jobs to clear them out or something. This is especially a problem since hostile users can cause creation of rows in those tables - as many as they like, just by making a web request - though maybe I'm just being paranoid now. I wanted to keep the dependencies for this down to the minimum, and you can always replace it with something better. I'm not familiar with James Bennet's registration app, so I can't comment on that front. Luke -- "I have had a perfectly lovely evening. However, this wasn't it." (Groucho Marx) Luke Plant || http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: MS SQL backend as a proper external backend (was: RFC: Django 1.0 roadmap and timeline)
On 12 jun, 21:37, "Leo Soto M." <[EMAIL PROTECTED]> wrote: > On Thu, Jun 12, 2008 at 8:35 PM, Ramiro Morales <[EMAIL PROTECTED]> wrote: > [...] > > > Since then I've opened ticket [2]#7420 with a patch > > I see that part of the patch deals with the fact that the underlying > adapter prefer to receive actual date and time instances for date and > time parameters, instead of strings. I have the same problem when > talking to JDBC drivers. > > To solve it I proposed[1] another strategy: delegate type conversion > to the backend. OK, I have filled #7560 with a patch which delegates date, time, datetime and decimal python -> db conversion to the database backend. It also ensures that for basic field types (IntegerField, BooleanField, ...) the backend will receive the "expected" basic python type (int, bool, ...). http://code.djangoproject.com/ticket/7560 This should help other external-backend mantainers. -- Leo Soto M. --~--~-~--~~~---~--~~ 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: More secure user password reset
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? On Jun 27, 4:01 pm, Luke Plant <[EMAIL PROTECTED]> wrote: > Hi all, > > Currently password reset is done without any confirmation, so all you > have to do is know someone's email and a Django site that they use > (assuming it uses the default password reset code) and you can change > their password. In this way, you only have to make about 1 > request/minute to completely block someone from accessing their > account. > > (Related tickets: > http://code.djangoproject.com/ticket/4235 > http://code.djangoproject.com/ticket/5272) > > I propose to change to a solution that requires clicking a link in an > email, with the link containing the username, the new password, a > timestamp and a hash to stop tampering. This link is handled by a > new view which does the resetting, and gives a limited period for the > reset, so that someone who sniffs the URL cannot keep resetting the > password. > > As I understand it, with SSL both GET and POST parameters in a request > are invisible to sniffers, so if SSL is enabled this would become a > secure solution (without SSL, GET and POST etc are of course > completely visible to sniffers, so you can't design a system that is > properly secure without SSL). > > This would be a backwards incompatible change -- if you have provided > your own templates for the password reset views then they will need > fixing. It doesn't make sense to do it to trunk, since the password > reset view has already changed in newforms-admin, so this should > probably wait for the nfa merge. > > I've actually already implemented the above system for my own site, > complete with tests. Testing is still problematic for views in > contrib, but that should be fixed shortly. > > What do people think? Did I miss any problems? > > Luke > > -- > "If your parents never had children, the chances are you won't > either." > > Luke Plant ||http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
More secure user password reset
Hi all, Currently password reset is done without any confirmation, so all you have to do is know someone's email and a Django site that they use (assuming it uses the default password reset code) and you can change their password. In this way, you only have to make about 1 request/minute to completely block someone from accessing their account. (Related tickets: http://code.djangoproject.com/ticket/4235 http://code.djangoproject.com/ticket/5272 ) I propose to change to a solution that requires clicking a link in an email, with the link containing the username, the new password, a timestamp and a hash to stop tampering. This link is handled by a new view which does the resetting, and gives a limited period for the reset, so that someone who sniffs the URL cannot keep resetting the password. As I understand it, with SSL both GET and POST parameters in a request are invisible to sniffers, so if SSL is enabled this would become a secure solution (without SSL, GET and POST etc are of course completely visible to sniffers, so you can't design a system that is properly secure without SSL). This would be a backwards incompatible change -- if you have provided your own templates for the password reset views then they will need fixing. It doesn't make sense to do it to trunk, since the password reset view has already changed in newforms-admin, so this should probably wait for the nfa merge. I've actually already implemented the above system for my own site, complete with tests. Testing is still problematic for views in contrib, but that should be fixed shortly. What do people think? Did I miss any problems? Luke -- "If your parents never had children, the chances are you won't either." Luke Plant || http://lukeplant.me.uk/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Proposal: PostgreSQL backends should *stop* using settings.TIME_ZONE
On Fri, Jun 27, 2008 at 5:55 AM, Antti Haapala <[EMAIL PROTECTED]> wrote: > > > On 25 kesä, 19:12, "Tom Tobin" <[EMAIL PROTECTED]> wrote: > >> All PostgresSQL supports in terms of *storage* is >> a fixedtimezoneoffset, not the actual zoneinfo name; this isn't >> very useful, and causes problems such as the above. > > Actually, in PostgreSQL TIMESTAMP WITH TIME ZONE does NOT store the > TIME ZONE! I found it out the hard way yesterday. Well, it stores the *offset*, which is virtually useless in real-world applications. All PostgreSQL TIMESTAMPs are stored internally as UTC. Since Django does everything with naive datetimes (a *huge* mistake IMHO, and what I'm trying to correct), the Postgres backend stores these in the database as per settings.TIME_ZONE, with that offset. It also retrieves as per that offset, back into naive datetimes. If you change settings.TIME_ZONE, you now get different naive datetimes back with no way to distinguish them. If you want to use multiple time zones at the same time ... good luck, you'll need it. ^_^ Check out the code in Bulbs (The Onion's open source code snippets) for my current crack at this problem; we're about to push a major site live with my "DateTimeZoneField", and I'd love to see something similar make its way into Django: https://launchpad.net/bulbs It could use better documentation, which is on my to-do list as soon as the APIs stabilize a tad. --~--~-~--~~~---~--~~ 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: Call for testing: streaming uploads (#2070)
Full test pass on Ubuntu Hardy Heron, with python 2.5, and sqlite3. I
also did some general testing of uploading files, which were
succesful, and I was able to observe large uploads going to my /tmp
dir.
On Jun 27, 4:41 am, David Reynolds <[EMAIL PROTECTED]>
wrote:
> Jacob,
>
> Hopefully this will be of some use..
>
> On 26 Jun 2008, at 8:14 pm, Jacob Kaplan-Moss wrote:
>
> > * Running the test suite -- coverage is quite good now, but I've only
> > been able to test on a limited set of OSes/DBs. Looks elsewhere just
> > in case, very good.
>
> I've just checked the branch and ran the test suite on the following
> setup:
>
> - Debian Lenny
> - Python 2.5.2
> - MySQLdb 1.2.2 final
> - python-sqlite 2.3.2
> - sqlite 3.5.9
> - MySQL 5.0.51a
>
> Running with sqlite backend all tests went through fine.
>
> Running with mysql backend created a few errors (I'm not sure if
> they're related so I've attached them in full, hope that's ok):
>
> /var/www/django/git/django/tests/regressiontests/templates/loaders.py:
> 14: UserWarning: Module _mysql was already imported from /var/lib/
> python-support/python2.5/_mysql.so, but /var/lib/python-support/
> python2.5 is being added to sys.path
> import pkg_resources
> /var/www/django/git/django/django/db/models/sql/query.py:1502:
> Warning: Incorrect string value: '\xE6\x9E\x97\xE5\x8E\x9F...' for
> column 'headline' at row 1
> cursor.execute(sql, params)
> ==
> FAIL: Doctest: modeltests.basic.models.__test__.API_TESTS
> --
> Traceback (most recent call last):
> File "/var/www/django/git/django/django/test/_doctest.py", line
> 2180, in runTest
> raise self.failureException(self.format_failure(new.getvalue()))
> AssertionError: Failed doctest test for
> modeltests.basic.models.__test__.API_TESTS
> File "/var/www/django/git/django/tests/modeltests/basic/
> models.py", line unknown line number, in API_TESTS
>
> --
> File "/var/www/django/git/django/tests/modeltests/basic/models.py",
> line ?, in modeltests.basic.models.__test__.API_TESTS
> Failed example:
> Article.objects.get(pk=a.id).headline
> Expected:
> u'\u6797\u539f \u3081\u3050\u307f'
> Got:
> u'?? ???'
>
> ==
> FAIL: Doctest: modeltests.custom_pk.models.__test__.API_TESTS
> --
> Traceback (most recent call last):
> File "/var/www/django/git/django/django/test/_doctest.py", line
> 2180, in runTest
> raise self.failureException(self.format_failure(new.getvalue()))
> AssertionError: Failed doctest test for
> modeltests.custom_pk.models.__test__.API_TESTS
> File "/var/www/django/git/django/tests/modeltests/custom_pk/
> models.py", line unknown line number, in API_TESTS
>
> --
> File "/var/www/django/git/django/tests/modeltests/custom_pk/
> models.py", line ?, in modeltests.custom_pk.models.__test__.API_TESTS
> Failed example:
> emp.save()
> Exception raised:
> Traceback (most recent call last):
> File "/var/www/django/git/django/django/test/_doctest.py",
> line 1267, in __run
> compileflags, 1) in test.globs
> File " [34]>", line 1, in
> emp.save()
> File "/var/www/django/git/django/django/db/models/base.py",
> line 274, in save
> self.save_base()
> File "/var/www/django/git/django/django/db/models/base.py",
> line 315, in save_base
> if manager.filter(pk=pk_val).extra(select={'a': 1}).values
> ('a').order_by():
> File "/var/www/django/git/django/django/db/models/query.py",
> line 170, in __nonzero__
> iter(self).next()
> File "/var/www/django/git/django/django/db/models/query.py",
> line 164, in _result_iter
> self._fill_cache()
> File "/var/www/django/git/django/django/db/models/query.py",
> line 586, in _fill_cache
> self._result_cache.append(self._iter.next())
> File "/var/www/django/git/django/django/db/models/query.py",
> line 612, in iterator
> for row in self.query.results_iter():
> File "/var/www/django/git/django/django/db/models/sql/
> query.py", line 200, in results_iter
> for rows in self.execute_sql(MULTI):
> File "/var/www/django/git/django/django/db/models/sql/
> query.py", line 1502, in execute_sql
> cursor.execute(sql, params)
> File "/var/lib/python-support/python2.5/MySQLdb/cursors.py",
> line 166, in execute
> self.errorhandler(self, exc, value)
> File "/var/lib/python-support/python2.5/MySQLdb/
> connections.py", line 35, in defaulterrorhandler
> raise errorclass, errorvalue
> OperationalError: (1267, "Illegal mix of co
Re: Spam detection
On Fri, Jun 27, 2008 at 11:36 AM, rskm1 <[EMAIL PROTECTED]> wrote: > >> Help me out here: how can I make it more obvious? You missed that; >> others often do to. Can you share with me some insights on how you >> missed it? > > I'll chime in. Basic rule of thumb for GUIs: > * If it's going to fail _ANYWAY_, just GRAY IT OUT!! > > In other words, make the form-input fields of the > http://code.djangoproject.com/simpleticket > page simply NOT APPEAR, or be DISABLED, if there is no user logged-in. > > That would make the message about registering and being logged-in > pretty much IMPOSSIBLE to miss =). And nobody will ever again see the > error page about attempting to create a new ticket anonymously. +1; this makes worlds of sense. :-) --~--~-~--~~~---~--~~ 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
> Help me out here: how can I make it more obvious? You missed that; > others often do to. Can you share with me some insights on how you > missed it? I'll chime in. Basic rule of thumb for GUIs: * If it's going to fail _ANYWAY_, just GRAY IT OUT!! In other words, make the form-input fields of the http://code.djangoproject.com/simpleticket page simply NOT APPEAR, or be DISABLED, if there is no user logged-in. That would make the message about registering and being logged-in pretty much IMPOSSIBLE to miss =). And nobody will ever again see the error page about attempting to create a new ticket anonymously. --~--~-~--~~~---~--~~ 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: The block tag has multiple meanings
On Fri, Jun 27, 2008 at 4:33 PM, Antonis Christofides <[EMAIL PROTECTED]> wrote: > > Hi, > > There are essentially two things that you can do with a block: > (1) define it (or redefine it); and (2) insert it somewhere in a > template. The block tag thus performs different functions depending > on circumstances: > * If a block tag with the same name exists in an inherited > template, then the block tag merely (re)defines the block. > * If no block tag with the same name is inherited, then the block tag > at the same time defines the block AND inserts it in the template. > > In my opinion, having two substantially different operations under one > label is a cause for confusion. Explicit is better than implicit. I > wonder whether it would be better the distinguish the functionality in > "insblock" and "defblock": No, please, don't. The master template has no place to "predefine" the blocks as it's structure is outputted verbatim. Child templates on the other hand have no need to define blocks outside of other blocks so it's pretty much useless and prone to infinite loops (insert a parent block in a sub-sub-sub-child block for example). -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
The block tag has multiple meanings
Hi,
There are essentially two things that you can do with a block:
(1) define it (or redefine it); and (2) insert it somewhere in a
template. The block tag thus performs different functions depending
on circumstances:
* If a block tag with the same name exists in an inherited
template, then the block tag merely (re)defines the block.
* If no block tag with the same name is inherited, then the block tag
at the same time defines the block AND inserts it in the template.
In my opinion, having two substantially different operations under one
label is a cause for confusion. Explicit is better than implicit. I
wonder whether it would be better the distinguish the functionality in
"insblock" and "defblock":
{% defblock myblock %}
This is myblock's definition. Possibly re-definition if the block
has already been defined in an inherited template. It does not
insert the block in the template.
{% enddefblock %}
{% insblock myblock %} {# This inserts myblock here. #}
{% defblock myblock2 insert %}
This is a shortcut: defines myblock2 and inserts it at the same time.
It's the same as the existing topmost block tag. Child templates
should allow it only inside other blocks, otherwise it doesn't
make sense.
{% enddefblock %}
{% block myblock3 %}
This is the old, deprecated block tag, existing for backwards
compatibility. It is not clear what it means.
{% endblock %}
I think that this would solve
http://code.djangoproject.com/ticket/4529 and other similar requests
in a much more natural and intuitive manner. In addition, the absense
of an insblock (or reuse-block) has resulted in my using strange and
unintuitive techniques in my templates (I wanted to define small
blocks in a base template and insert them in different order in child
templates - and "include" would create an undesired mess of many
files). When I tried to find a solution and see what other people had
said about that, I understood that the block tag is double-faced and
confusing.
--~--~-~--~~~---~--~~
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: Kwippy - micro-blogging using django
On Fri, Jun 27, 2008 at 1:58 PM, Dipankar Sarkar <[EMAIL PROTECTED]> wrote: > > Hey guys > > I and a coupla more django developers recently released a micro- > blogging platform called kwippy (http://kwippy.com) ... currently it > is in beta and invite only (obv mail me to get an instant invite) Wrong list. -- Patryk Zawadzki PLD Linux Distribution --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Kwippy - micro-blogging using django
Hey guys I and a coupla more django developers recently released a micro- blogging platform called kwippy (http://kwippy.com) ... currently it is in beta and invite only (obv mail me to get an instant invite) We need to get more people to use the service and help us test our infrastructure. We aim to use django and better RoR by miles (twitter is on RoR) Feel free to add your email to our beta invites if you visit the site. Dipankar Sarkar dipankar [at] kwippy.com http://kwippy.com/dipankar --~--~-~--~~~---~--~~ 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: PostgreSQL backends should *stop* using settings.TIME_ZONE
On 25 kesä, 19:12, "Tom Tobin" <[EMAIL PROTECTED]> wrote: > All PostgresSQL supports in terms of *storage* is > a fixedtimezoneoffset, not the actual zoneinfo name; this isn't > very useful, and causes problems such as the above. Actually, in PostgreSQL TIMESTAMP WITH TIME ZONE does NOT store the TIME ZONE! I found it out the hard way yesterday. BTW, what we would need at the moment in our project would be a DateTimeField with complete time zone support. It seems I have to both write the Field type completely from scratch, and it seems it has to be multi-column on MySQL (must store time in UTC, along with separate textual time zone). Anyway, I believe that that approach together with time zone aware datetime objects would get rid of lot of ambiguity and problems for good. To someone thinking about the problems involved with storing times in local time: The reason why this is bad is the DST changes: on the last Sunday of October in EU there's an extra hour added, with for example times 3:00-3:59 occuring twice in EE(S)T zone. If you don't store the time zone, hours 1:00-3:00 UTC will be ambiguous. Also, were you storing local times in database, you could pretty easily ruin the database if you decided to change the time zone in the model... --~--~-~--~~~---~--~~ 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: First day of week
I don't think that this should be included in the 'must have' list (to avoid postponing 1.0 date). What I want is to consider this feature for the may be list, so if a good patch is ready before 1.0 beta, it could be commited. So if it's not ready on that time, then we forget this feature for now, and 1.0 schedule isn't affected. The only thing is that a commiter should review the patch before commiting. Do you thing that it'll be too much? I can imagine the hectic status before the releases... On Jun 27, 11:16 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > On Fri, Jun 27, 2008 at 3:23 AM, Marc Garcia <[EMAIL PROTECTED]> wrote: > > > Could it be added to 1.0 maybe list? I think that those features are > > essential for developing not only international websites, also for > > developing non international websites for most countries (not US, of > > course ;). If it's added to list, I'll try to have a good patch before > > 1.0 beta. > > Unfortunately, everyone has a different list of 'must have' features > for v1.0. If we tried to include everything that everybody considers > 'must have', v1.0 would never ship. From that perspective, we're not > going to add anything else new to the official list. > > 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?hl=en -~--~~~~--~~--~--~---
Re: Ordered ManyToMany
> I think Django is really wonderful, but I am puzzled that it contains > so few "ordering features". We often have the case that a user wants > to select from a list of possible choices (normal select) *plus* wants > to specify an ordering. Typically in applications this is done using > up/down arrows next to the box displaying the selected values. This is indeed a very common use case and has been requested many times (e.g. here [1]). The good news is that Django has scheduled the 1.0 release early September. This means it’s very probably not going to be addressed right now. But once 1.0 is out the door the ancient ticket #13 [2] will be (hopefully) revisited :) It has a mock-up of the admin interface proposed [3] but no patch yet. On the JS-lib/flamewar issue. If I recall correctly the admin is not considered to belong to the core of Django (even though it’s _the_ killer feature for many). It's merely an application. As such it has to use the techniques necessary. Unless someone volunteers to rewrite a JS for Django from scratch this includes using a lib. I don't think that's that much of an issue though. Let's just come up witch a sensible list and have people with commit privileges vote on it :) But post 1.0 ;) Cheers, Jonas [1] http://code.djangoproject.com/ticket/6118 [2] http://code.djangoproject.com/ticket/13 [3] http://media.wilsonminer.com/images/django/related-objects-mock.gif --~--~-~--~~~---~--~~ 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: Call for testing: streaming uploads (#2070)
Jacob,
Hopefully this will be of some use..
On 26 Jun 2008, at 8:14 pm, Jacob Kaplan-Moss wrote:
> * Running the test suite -- coverage is quite good now, but I've only
> been able to test on a limited set of OSes/DBs. Looks elsewhere just
> in case, very good.
I've just checked the branch and ran the test suite on the following
setup:
- Debian Lenny
- Python 2.5.2
- MySQLdb 1.2.2 final
- python-sqlite 2.3.2
- sqlite 3.5.9
- MySQL 5.0.51a
Running with sqlite backend all tests went through fine.
Running with mysql backend created a few errors (I'm not sure if
they're related so I've attached them in full, hope that's ok):
/var/www/django/git/django/tests/regressiontests/templates/loaders.py:
14: UserWarning: Module _mysql was already imported from /var/lib/
python-support/python2.5/_mysql.so, but /var/lib/python-support/
python2.5 is being added to sys.path
import pkg_resources
/var/www/django/git/django/django/db/models/sql/query.py:1502:
Warning: Incorrect string value: '\xE6\x9E\x97\xE5\x8E\x9F...' for
column 'headline' at row 1
cursor.execute(sql, params)
==
FAIL: Doctest: modeltests.basic.models.__test__.API_TESTS
--
Traceback (most recent call last):
File "/var/www/django/git/django/django/test/_doctest.py", line
2180, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for
modeltests.basic.models.__test__.API_TESTS
File "/var/www/django/git/django/tests/modeltests/basic/
models.py", line unknown line number, in API_TESTS
--
File "/var/www/django/git/django/tests/modeltests/basic/models.py",
line ?, in modeltests.basic.models.__test__.API_TESTS
Failed example:
Article.objects.get(pk=a.id).headline
Expected:
u'\u6797\u539f \u3081\u3050\u307f'
Got:
u'?? ???'
==
FAIL: Doctest: modeltests.custom_pk.models.__test__.API_TESTS
--
Traceback (most recent call last):
File "/var/www/django/git/django/django/test/_doctest.py", line
2180, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for
modeltests.custom_pk.models.__test__.API_TESTS
File "/var/www/django/git/django/tests/modeltests/custom_pk/
models.py", line unknown line number, in API_TESTS
--
File "/var/www/django/git/django/tests/modeltests/custom_pk/
models.py", line ?, in modeltests.custom_pk.models.__test__.API_TESTS
Failed example:
emp.save()
Exception raised:
Traceback (most recent call last):
File "/var/www/django/git/django/django/test/_doctest.py",
line 1267, in __run
compileflags, 1) in test.globs
File "", line 1, in
emp.save()
File "/var/www/django/git/django/django/db/models/base.py",
line 274, in save
self.save_base()
File "/var/www/django/git/django/django/db/models/base.py",
line 315, in save_base
if manager.filter(pk=pk_val).extra(select={'a': 1}).values
('a').order_by():
File "/var/www/django/git/django/django/db/models/query.py",
line 170, in __nonzero__
iter(self).next()
File "/var/www/django/git/django/django/db/models/query.py",
line 164, in _result_iter
self._fill_cache()
File "/var/www/django/git/django/django/db/models/query.py",
line 586, in _fill_cache
self._result_cache.append(self._iter.next())
File "/var/www/django/git/django/django/db/models/query.py",
line 612, in iterator
for row in self.query.results_iter():
File "/var/www/django/git/django/django/db/models/sql/
query.py", line 200, in results_iter
for rows in self.execute_sql(MULTI):
File "/var/www/django/git/django/django/db/models/sql/
query.py", line 1502, in execute_sql
cursor.execute(sql, params)
File "/var/lib/python-support/python2.5/MySQLdb/cursors.py",
line 166, in execute
self.errorhandler(self, exc, value)
File "/var/lib/python-support/python2.5/MySQLdb/
connections.py", line 35, in defaulterrorhandler
raise errorclass, errorvalue
OperationalError: (1267, "Illegal mix of collations
(latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for
operation '='")
==
FAIL: Doctest: modeltests.serializers.models.__test__.API_TESTS
--
Traceback (most recent call last):
File "/var/www/django/git/django/django/test/_doctest.py", line
2180, in runTest
raise self.failureException(self.format_failure(
Re: First day of week
On Fri, Jun 27, 2008 at 3:23 AM, Marc Garcia <[EMAIL PROTECTED]> wrote: > > Could it be added to 1.0 maybe list? I think that those features are > essential for developing not only international websites, also for > developing non international websites for most countries (not US, of > course ;). If it's added to list, I'll try to have a good patch before > 1.0 beta. Unfortunately, everyone has a different list of 'must have' features for v1.0. If we tried to include everything that everybody considers 'must have', v1.0 would never ship. From that perspective, we're not going to add anything else new to the official list. 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?hl=en -~--~~~~--~~--~--~---
Re: DDN: Contrib apps testing their own views (#7521)
On Fri, Jun 27, 2008 at 4:29 PM, Marc Fargas <[EMAIL PROTECTED]> wrote: > El jue, 26-06-2008 a las 06:58 +0800, Russell Keith-Magee escribió: >> >> My preferred solution here would be to provide a way for test cases to >> >> substitute a top level URL pattern object for the duration of the >> >> test. For example: > > A patch in these lines is now attached to #7521, the patch right now: I saw this last night - I had a quick look at the patch, and it looked ok. Getting this into trunk is on the top of my todo list, which means it should happen in the next day or two. 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?hl=en -~--~~~~--~~--~--~---
Re: DDN: Contrib apps testing their own views (#7521)
El jue, 26-06-2008 a las 06:58 +0800, Russell Keith-Magee escribió: > >> My preferred solution here would be to provide a way for test cases to > >> substitute a top level URL pattern object for the duration of the > >> test. For example: > > A patch in these lines is now attached to #7521, the patch right now: * Adds the "urls" parameter, and a new method to TestCase called "_post_teardown", it's called at the end of __call__. * Adds a "clear_url_cache()" method to django.core.urlresolvers (To clear the resolver cache when swapping urlconfs) * Adds two TestCases to check the "urls" parameter, they must be run in order... * modifies fomtools.tests to use the urls paremeter instead of it's own hack (which should be broken somehow for the cache thing). * docs!!! The only thing not added to the patch is reverting [7726], it's on my git branch thought, http://www.marcfargas.com/gitweb/?p=django.git;a=shortlog;h=trac/7521-test-urlconfs Hope this patch is ok! Marc -- http://www.marcfargas.com -- will be finished some day. signature.asc Description: Esta parte del mensaje está firmada digitalmente
