Sorting out 'default'
Something I've noticed that trips up a lot of people, both new Django users and old, is the way the 'default' argument for model fields works; there's a disconnect between what it actually does and what people commonly assume it does, based largely in when the default value is filled in: 1. The way it actually works is that the default value is stuffed into the field in a FormWrapper, so that when you display it it has the value pre-filled. 2. The way people commonly *expect* it to work is that it should fill in the default value "after the fact" if the form is submitted without a value for that field. Pre-filling in the FormWrapper, and then not touching it again, makes logical sense and is good for an application's end users, because it lets them see what value a field will take if they don't do anything to it, but is tricky for developers because it means you can't rely on the default value to save you if you have a required field that you never display to end users (and frustrates *everybody* when it results in a "please correct the errors below" that doesn't show any errors). "Post-filling" the value after submission also makes logical sense, and is better for developers because it means they can specify default values for one or more fields, and then "hide" those fields by leaving them out of end-user displays, but is problematic for the end users because they can't see what the default value will be if they leave the field alone. Doing both a "pre-fill" and a "post-fill" can somewhat alleviate that, but either way we also get into a big can of worms with trying to second-guess the form submission -- did that field get left out because the user intentionally submitted it blank (in which case it should stay blank), or because it was never displayed (in which case it should get the default value)? Personally, I think the way we do it now -- pre-filling the value and then leaving it alone if it comes back blank -- is the better option, and that the developer-related issues can largely be solved by better documentation (i.e., telling people that if they want to "hide" a field but still require it to be filled in, they should give it 'blank=True' and fill in a value in a custom save method), but judging from the fact that it keeps coming up in tickets and on IRC I think we need to settle on exactly what the behavior will be and document it clearly, preferably with examples. -- "May the forces of evil become confused on the way to your house." -- George Carlin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Caching issue cache.py line 161
Hello all, I'm face an issue while using the cache middleware : [Fri Aug 18 13:00:52 2006] [error] [client 10.0.0.199] PythonHandler django.core.handlers.modpython: File "/usr/lib/python2.4/site-packages/django/utils/cache.py", line 161, in learn_cache_key\ncache.set(cache_key, headerlist, cache_timeout) [Fri Aug 18 13:00:52 2006] [error] [client 10.0.0.199] PythonHandler django.core.handlers.modpython: File "/usr/lib/python2.4/site-packages/django/core/cache/backends/filebased.py", line 48, in set\npickle.dump(now + timeout, f, 2) [Fri Aug 18 13:00:52 2006] [error] [client 10.0.0.199] PythonHandler django.core.handlers.modpython: TypeError: unsupported operand type(s) for +: 'float' and 'str' Changing /usr/lib/python2.4/site-packages/django/middleware/cache.py line 161 to self.cache_timeout = int(settings.CACHE_MIDDLEWARE_SECONDS) solved the problem. I'm running : mod_python 3.1.4-r1 apache 2.0.58-r2 python 2.4.3-r1 Settings : #CACHE_BACKEND = 'memcached://127.0.0.1:22162/' CACHE_MIDDLEWARE_SECONDS = '300' CACHE_MIDDLEWARE_KEY_PREFIX = 'djan_' CACHE_BACKEND = 'file:///home/django/cache' I've just svn django source from trunk Regards, xav --~--~-~--~~~---~--~~ 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: Caching issue cache.py line 161
On Fri, 2006-08-18 at 11:14 +, xgdlm wrote: [...] > [Fri Aug 18 13:00:52 2006] [error] [client 10.0.0.199] PythonHandler > django.core.handlers.modpython: TypeError: unsupported operand type(s) > for +: 'float' and 'str' This almost always means you're passing a string where an integer is expected. > > Changing /usr/lib/python2.4/site-packages/django/middleware/cache.py > line 161 to > > self.cache_timeout = int(settings.CACHE_MIDDLEWARE_SECONDS) solved the > problem. And this confirms that CACHE_MIDDLEWARE_SECONDS should be an integer. However, you don't need this line. Undo it. > Settings : > #CACHE_BACKEND = 'memcached://127.0.0.1:22162/' > CACHE_MIDDLEWARE_SECONDS = '300' So stop passing it as a string. Set CACHE_MIDDLEWARE_SECONDS = 300 (no quotes) and you will be fine. 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: Caching issue cache.py line 161
Malcolm Tredinnick wrote: > On Fri, 2006-08-18 at 11:14 +, xgdlm wrote: > So stop passing it as a string. Set CACHE_MIDDLEWARE_SECONDS = 300 (no > quotes) and you will be fine. Thanks for your answer Malcom. This was the trick. I was pretty sure to have done the test before posting, but now I realize that I'm running on apache2 and not on the dev server (must have forgotten to reload it). Of course it's working fine now :) Sorry for the noise, xav --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Graham Dumpleton about mod_python
Hi folks, Have you read the following from Django Comments, what do you think of it ? Graham Dumpleton August 17, 2006 at 11:59 p.m. You really need to provide an explanation of why the worker MPM cannot be used and the prefork MPM must be used. The reason is that this doesn't make a lot of sense. On a Win32 system, how Apache works is not much different to a worker MPM on a UNIX system with the exception that there is only one Apache child process, whereas on UNIX there can be multiple Apache child processes. In other words, both on Win32 and when worker MPM on UNIX is used there can be multiple concurrent requests being handled in separate threads within the same Apache child process. Thus, if the problem is related to multithreading, if it doesn't work with the worker MPM, it probably shouldn't work on Win32 systems either. The only thing I can think of is that this advice is based on the use of a version of mod_python prior to version 3.2.8. These older versions had a number of issues in relation to multithreaded MPMs which could cause problems. But then, this would have affected both Win32 and UNIX worker MPM. So, please explain. Also, if it is believed that not being able to use worker MPM is related to mod_python, as opposed to Django, you really should communicate with the mod_python folks about it. Keeping up to date with what the mod_python folks are up to would also be a good idea with mod_python 3.3 getting near to be finished. This is because it will have a completely new module importer and there is always a small risk that it may not play well with Django. You may therefore want to ensure you do some testing with the development version in advance of mod_python 3.3 actually being released. --~--~-~--~~~---~--~~ 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: Graham Dumpleton about mod_python
On Fri, 2006-08-18 at 05:54 -0700, olive wrote: > Hi folks, > > Have you read the following from Django Comments, what do you think of > it ? This seems to be in response to some question. What is the context, though? What was the original question and where was this posted? Was there a particular point you wanted to know about? 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: posibility of generalize AdminMediaHandler ?
Karen Tracey wrote: > > If what works for admin can't/shouldn't/won't be generalized, then > maybe some documentation enhancements would help out people like me. See the page "How to serve static files"[1] in the docs. Then, be sure to read "The big, fat disclaimer" on that page. That should answer your questions for you. I would imagine the reason the ticket was marked won't fix is because there is already a mechanism in place to do this. [1] http://www.djangoproject.com/documentation/static_files/ --~--~-~--~~~---~--~~ 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: JavaScript and Changeset 3541
On 8/17/06, Max Derkachev <[EMAIL PROTECTED]> wrote: > >I have not looked at this branch at all, but I'll strongly suggest > > that you remove the YUI stuff. > > Adrian, could You explain your opinion a bit more? > Does that mean that there are plans to bundle another toolkit? If yes, > what toolkit? Hey Max, Sure, I'd be happy to explain -- my (very strong) preference is to bundle *no* JavaScript toolkit. That's partially because we shouldn't limit which toolkit developers use, and partially because it's unnecessary bloat within the Django distribution. Adrian -- Adrian Holovaty holovaty.com | djangoproject.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 -~--~~~~--~~--~--~---
Re: Graham Dumpleton about mod_python
On 18 aug 2006, at 15.07, Malcolm Tredinnick wrote: > > On Fri, 2006-08-18 at 05:54 -0700, olive wrote: >> Hi folks, >> >> Have you read the following from Django Comments, what do you >> think of >> it ? > > This seems to be in response to some question. What is the context, > though? What was the original question and where was this posted? Was > there a particular point you wanted to know about? The comments is from http://www.djangoproject.com/documentation/ modpython/ - Daniel --~--~-~--~~~---~--~~ 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: Graham Dumpleton about mod_python
Malcom, The context of this comment is http://www.djangoproject.com/documentation/modpython/#c2029 What I would like to know is if something has been done or will be to ensure that Django works along with mod_python 3.3. As far as I understand this will allow us to run any taste of Apache in any case (this worker prefork MPM blahblah which is gibberish to me). --~--~-~--~~~---~--~~ 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: JavaScript and Changeset 3541
On 8/18/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > Sure, I'd be happy to explain -- my (very strong) preference is to > bundle *no* JavaScript toolkit. That's partially because we shouldn't > limit which toolkit developers use, and partially because it's > unnecessary bloat within the Django distribution. What about something like django.contrib.client? This leads me to wonder whether there should be release flavors (a la slackware vs. ubuntu) down the road. --~--~-~--~~~---~--~~ 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: JavaScript and Changeset 3541
Hi Adrian, Thanks for explanation. I am also against bundling any JS toolkit with *core* framework. -- Regards, Max --~--~-~--~~~---~--~~ 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: Graham Dumpleton about mod_python
olive wrote: > Graham Dumpleton August 17, 2006 at 11:59 p.m. > > You really need to provide an explanation of why the worker MPM cannot > be used and the prefork MPM must be used. Uhm... I would not say that it 'cannot' be used. It can (after some long time ago threading issues with db connections were resolved). I see the chooice between prefork and worker to not be related to Django at all. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Patch review #2070
http://code.djangoproject.com/attachment/ticket/2070/3581-streaming_uploads_and_uploadprogress_middleware_code_cleanup_review.diff --~--~-~--~~~---~--~~ 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: posibility of generalize AdminMediaHandler ?
Hi all, waylan schrieb: > > Karen Tracey wrote: >> If what works for admin can't/shouldn't/won't be generalized, then >> maybe some documentation enhancements would help out people like me. > > See the page "How to serve static files"[1] in the docs. Then, be sure > to read "The big, fat disclaimer" on that page. That should answer your > questions for you. I would imagine the reason the ticket was marked > won't fix is because there is already a mechanism in place to do this. > > [1] http://www.djangoproject.com/documentation/static_files/ > as of the writing of the email and the ticket I wasn't aware of that. As I read the source code of django/views/static.py document_root should be an absolute path. Is this correct ? Regards, Dirk -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer --~--~-~--~~~---~--~~ 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: Row Level Permissions Update
I noticed in the patch(3609,
http://code.djangoproject.com/changeset/3609) that you seem to grant
permissions automatically to the creator of an object. Is there any
way we can set this behavior? In my circumstance, I don't want the
writer of an article to be able to delete it.
Chris Long wrote:
> I'm considering doing what you describe, it shouldn't be too hard to
> implement and will probably be updating the branch with the code
> tomorrow depending on any unforeseen problems.
>
> Chris
>
>
> Joe wrote:
> > I'm not sure if this is more relevant to the Generic Authorization
> > branch, but has anyone looked at implementing the owner permissions
> > (the user who creates the object automatically has delete/modify
> > permissions)? For example, a META field sort of like the following:
> >
> > class Meta:
> > row_level_permissions = True
> > grant_creator = (('edit'),('delete'),)
> >
> > This way we can specify what permissions the creator of an object has
> > on objects he or she creates through the Django administration
> > interface.
> >
> > Chris Long wrote:
> > > Hi,
> > >
> > > I'm the GSoCer working on row level permissions.
> > >
> > > Row level permissions are now implemented and, in my test cases, are
> > > working.
> > >
> > > I wanted to find out if anyone has had an opportunity to try the row
> > > level permissions (per-object-permission) branch or read my wiki pages
> > > on it. Are there any comments on RLPs? Any features that are missing
> > > that you wish to be added?
> > >
> > > Thanks,
> > >
> > > Chris
--~--~-~--~~~---~--~~
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: Row Level Permissions Update
It's determined by the settings under the admin options. By default both are set to false, so no permissions will be creation. To do what you want: ... class Admin: grant_change_row_level_perm = True ... That should just set the change row levle permission and not set any delete row level permission. Chris --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
get_current_user into django distro ?
Hi all, I came across http://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser Since this middleware depends on django.contrib.auth.middleware.AuthenticationMiddleware and its context is very related to the request.user object I was wondering if this is related enought to become an own standard distro middleware in django.contrib.auth ? Was this every discussed ? I would call it django.contrib.auth.middleware.CurrentUserMiddleware :) Regards, Dirk -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer --~--~-~--~~~---~--~~ 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: get_current_user into django distro ?
On 8/18/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > I came across http://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser > > Since this middleware depends on > django.contrib.auth.middleware.AuthenticationMiddleware and its context is > very related > to the request.user object I was wondering if this is related enought to > become an own > standard distro middleware in django.contrib.auth ? > > Was this every discussed ? I'd rather not add that middleware to the Django distribution, because the implementation (using threadlocal) is hackish. We're still waiting on a cleaner solution to the problem. You can, of course, feel free to use that middleware in your own projects -- it's just not officially sanctioned, for what that's worth. Adrian -- Adrian Holovaty holovaty.com | djangoproject.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 -~--~~~~--~~--~--~---
Re: posibility of generalize AdminMediaHandler ?
At 12:07 PM 8/18/2006, Dirk wrote: >waylan schrieb: > > > > Karen Tracey wrote: > >> If what works for admin can't/shouldn't/won't be generalized, then > >> maybe some documentation enhancements would help out people like me. > > > > See the page "How to serve static files"[1] in the docs. Then, be sure > > to read "The big, fat disclaimer" on that page. That should answer your > > questions for you. I would imagine the reason the ticket was marked > > won't fix is because there is already a mechanism in place to do this. > > > > [1] http://www.djangoproject.com/documentation/static_files/ > > > >as of the writing of the email and the ticket I wasn't aware of that. I don't think I was clear in my original post. I had managed to get things working for my app using the static file filter as described on that page. I just wished it had been easier to find. Dirk's note that he was unaware of this option before going down the path of generalizing the AdminMediaHandler reinforces my impression that it is a bit too well hidden. Given the prominence of admin in the Tutorial I think it is worth pointing out to readers that admin has special code for serving static files like stylesheets, and that other apps need to use this other thing during development. (I do understand that it is only for use during development, but at this point I don't even have a web server installed so that's exactly where I am.) That's all. >As I read the source code of django/views/static.py document_root >should be an absolute path. Is this correct ? Yes, it should be an absolute path. At least that is what is working for me. Cheers, Karen --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
an 'empty' block tag
Hi,
I have a suggestion (with a patch) to save a few key clicks :-)
Do you ever write a template with {% block ... %}{% endblock %} tags
solely as placeholders to be overridden by other templates? I find I am
doing this a lot... and I am too lazy to type the {% endblock %} each
time :-) so I added the {% eblock ... %} tag that does not require an
end tag.
And here is the patch. I am posting it here to see if people think this
is a good idea... if it is, I will create a ticket.
--
Thanks a lot,
Medhat
Index: loader_tags.py
===
--- loader_tags.py (revision 3611)
+++ loader_tags.py (working copy)
@@ -1,5 +1,5 @@
from django.template import TemplateSyntaxError, TemplateDoesNotExist,
resolve_variable
-from django.template import Library, Node
+from django.template import Library, Node, NodeList
from django.template.loader import get_template,
get_template_from_string, find_template_source
from django.conf import settings
@@ -112,27 +112,32 @@
return ''
except:
return '' # Fail silently for invalid included templates.
-
-def do_block(parser, token):
-"""
-Define a block that can be overridden by child templates.
-"""
-bits = token.contents.split()
-if len(bits) != 2:
-raise TemplateSyntaxError, "'%s' tag takes only one argument"
% bits[0]
-block_name = bits[1]
-# Keep track of the names of BlockNodes found in this template, so
we can
-# check for duplication.
-try:
-if block_name in parser.__loaded_blocks:
-raise TemplateSyntaxError, "'%s' tag with name '%s'
appears more than once" % (bits[0], block_name)
-parser.__loaded_blocks.append(block_name)
-except AttributeError: # parser.__loaded_blocks isn't a list yet
-parser.__loaded_blocks = [block_name]
-nodelist = parser.parse(('endblock',))
-parser.delete_first_token()
-return BlockNode(block_name, nodelist)
-
+
+def do_block_func(empty=False):
+def do_block(parser,token):
+"""
+Define a block that can be overridden by child templates.
+"""
+bits = token.contents.split()
+if len(bits) != 2:
+raise TemplateSyntaxError, "'%s' tag takes only one
argument" % bits[0]
+block_name = bits[1]
+# Keep track of the names of BlockNodes found in this
template, so we can
+# check for duplication.
+try:
+if block_name in parser.__loaded_blocks:
+raise TemplateSyntaxError, "'%s' tag with name '%s'
appears more than once" % (bits[0], block_name)
+parser.__loaded_blocks.append(block_name)
+except AttributeError: # parser.__loaded_blocks isn't a list
yet
+parser.__loaded_blocks = [block_name]
+if empty:
+nodelist = NodeList()
+else:
+nodelist = parser.parse(('endblock',))
+parser.delete_first_token()
+return BlockNode(block_name, nodelist)
+return do_block
+
def do_extends(parser, token):
"""
Signal that this template extends a parent template.
@@ -172,6 +177,7 @@
return ConstantIncludeNode(path[1:-1])
return IncludeNode(bits[1])
-register.tag('block', do_block)
+register.tag('block', do_block_func())
+register.tag('eblock', do_block_func(True))
register.tag('extends', do_extends)
register.tag('include', do_include)
--~--~-~--~~~---~--~~
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: Row Level Permissions Update
Oops, I see it now. Thanks! --~--~-~--~~~---~--~~ 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: an 'empty' block tag
On 8/18/06, medhat <[EMAIL PROTECTED]> wrote:
> I have a suggestion (with a patch) to save a few key clicks :-)
> Do you ever write a template with {% block ... %}{% endblock %} tags
> solely as placeholders to be overridden by other templates? I find I am
> doing this a lot... and I am too lazy to type the {% endblock %} each
> time :-) so I added the {% eblock ... %} tag that does not require an
> end tag.
>
> And here is the patch. I am posting it here to see if people think this
> is a good idea... if it is, I will create a ticket.
Hey Medhat,
I don't think this is something we want in the Django distrubution
proper, but you should feel free to add it to the Django wiki at
http://code.djangoproject.com/wiki .
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.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
-~--~~~~--~~--~--~---
Re: Row Level Permissions Update
My pleasure :D --~--~-~--~~~---~--~~ 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: Patch review #2070
[EMAIL PROTECTED] wrote: > http://code.djangoproject.com/attachment/ticket/2070/3581-streaming_uploads_and_uploadprogress_middleware_code_cleanup_review.diff One thing I disagree with is that streaming on disk is done unconditionally. This is very good for files the size of tens of megabytes but for many small files this would be sometimes slower than keeping them in memory. My original patch used a boolean setting STORE_UPLOAD_ON_DISK to switch it on or off. However now I think it would be better to set a maximum size of upload file that can be stored in memory and store on disk only larger files. And also this same setting should be used for buffer size instead of now hard-coded 64000. P.S. I'm know as an inventor of very poor settings names but I would propose something like UPLOAD_BUFFER_SIZE. --~--~-~--~~~---~--~~ 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: Patch review #2070
Streaming uploads is now a middleware, so you can choose to load it or not. But a setting for buffer size is a good idea. --~--~-~--~~~---~--~~ 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: Patch review #2070
http://code.djangoproject.com/attachment/ticket/2070/3581-streaming_uploads_and_uploadprogress_middleware_code_cleanup_review_buffer_size_setting.diff Added setting to middleware. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Safe settings context processor
Way back in ticket http://code.djangoproject.com/ticket/1278, Adrian declared that a settings context processor was not going to happen. The reason being that it could give template authors direct access to the db password / secret key. Recently I coded up http://code.djangoproject.com/wiki/SafeSettingsContextProcessor, which uses the same get_safe_settings which the debug error page shows. Is this still too dangerous? As long as it's off by default, isn't it safe enough? On a side note, most people just want access to media_url, so I actually would be happy with just http://code.djangoproject.com/ticket/2532. Every web site wanting to use static CSS will need to access this variable somehow, won't they? Otherwise it has to be hard coded and that's not very Djangoish... --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
