slow response when using manage runserver without Internet connection
Hi, I am using the Django built-in web server. The server's reponse time is nomal when connecting to Internet, once it's offline, the speed is extremely slow. Does anyone have experience how to fix it? 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: Improved Norwegian translation files
On 22-Aug-06, at 11:46 AM, Lisa wrote: > Can I email these 4 files to someone and have them incorporated into > the latest Django release? If so, please provide me with an e-mail > address. Thanks in advance. create a ticket on the wiki and attach the files with your comments -- regards kg http://lawgon.livejournal.com http://nrcfosshelpline.in/web/ --~--~-~--~~~---~--~~ 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: Improved Norwegian translation files
On 8/22/06, Lisa <[EMAIL PROTECTED]> wrote: > > Excuse me if this is not the appropriate place for this post. I am > using Django's i18n feature (which works fantastic). But there are > both errors and omissions from the Norwegian translations files > (django.po, django.mo, djangoja.po & djangoja.mo). > > I have improved these files for my own use, but it would be nice to > submit them back to the current Django development version. I am not a > serious core Django developer, and I don't even know the process for > submitting updates, so I need to know how I can do this. > > Can I email these 4 files to someone and have them incorporated into > the latest Django release? If so, please provide me with an e-mail > address. Thanks in advance. > > I think you should make a new ticket in http://code.djangoproject.com/newticket, and upload the updated files in the ticket. And anything about i18n should be discussed in django-i18n maillist. -- I like python! My Blog: http://www.donews.net/limodou My Django Site: http://www.djangocn.org NewEdit Maillist: http://groups.google.com/group/NewEdit --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Improved Norwegian translation files
Excuse me if this is not the appropriate place for this post. I am using Django's i18n feature (which works fantastic). But there are both errors and omissions from the Norwegian translations files (django.po, django.mo, djangoja.po & djangoja.mo). I have improved these files for my own use, but it would be nice to submit them back to the current Django development version. I am not a serious core Django developer, and I don't even know the process for submitting updates, so I need to know how I can do this. Can I email these 4 files to someone and have them incorporated into the latest Django release? If so, please provide me with an e-mail address. Thanks in advance. --~--~-~--~~~---~--~~ 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: XSS comments from PHP Creator
On 8/22/06, Ian Holsman <[EMAIL PROTECTED]> wrote: > On 21/08/2006, at 9:24 PM, [EMAIL PROTECTED] wrote: > > @ Ahmad - mod_security (modsecurity.org) is fantastic, and I highly > > recommend installing it on all apaches, but filtering content at the > > webserver level is a sledgehammer approach and should only be done for > > *really* bad content (e.g. known exploits, spam bots etc) > > > you should be doing filtering exactly the opposite way than this. > > You deny everything by default, and have holes added when you need them. > and when you poke a hole you have a reference to why it is required > (ie what module needs a particular variable unfiltered) > > Things which you don't know will hurt you unfortunately. and by > using deny by default with a big sledgehammer will > stop a lot of these things before they even touch your code. > > doing it the other way requires a conscious effort to maintain the > firewall, and you won't know when you are failing. Obviously, mod_security is not the only solution, it will just provide some extra security. I don't think that it is a flawed method of security by itself, this is the same model used in anti-virus, anti-spyware and spam protection. You maintain a long list of known threats that you test against. I can argue that the kind of passive security you are talking about, as in everything is denied by default, is already present in Django. It is not like variables are passivly going all the way to your templates and being randomly embedded in there. You are actively passing a variable to the template through context and embedding it at certain places. You are just poking a hole in this firewall. But if you keep poking holes in all the wrong places, then it is not the frameworks fault. Autoescaping might be a nice DRY feature, but I don't think it has anything to do with being secure by default. --~--~-~--~~~---~--~~ 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: XSS comments from PHP Creator
On 21/08/2006, at 9:24 PM, [EMAIL PROTECTED] wrote: > > @ Ahmad - mod_security (modsecurity.org) is fantastic, and I highly > recommend installing it on all apaches, but filtering content at the > webserver level is a sledgehammer approach and should only be done for > *really* bad content (e.g. known exploits, spam bots etc) > you should be doing filtering exactly the opposite way than this. You deny everything by default, and have holes added when you need them. and when you poke a hole you have a reference to why it is required (ie what module needs a particular variable unfiltered) Things which you don't know will hurt you unfortunately. and by using deny by default with a big sledgehammer will stop a lot of these things before they even touch your code. doing it the other way requires a conscious effort to maintain the firewall, and you won't know when you are failing. > --Simon > --Ian -- Ian Holsman [EMAIL PROTECTED] http://personalinjuryfocus.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 -~--~~~~--~~--~--~---
[Fw]The Python Web Framework
http://www.cmlenz.net/blog/2006/08/the_python_web_.html Some points I think are reasonable, for example: django configuration -- I like python! My Blog: http://www.donews.net/limodou My Django Site: http://www.djangocn.org NewEdit Maillist: http://groups.google.com/group/NewEdit --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
New Manipulators and Validation Aware models.
I have built a proposal for a new Manipulator system. Here are some
of the benefits of this new system:
- Custom form views become very simple, and intuitive.
- Validation aware models are harnessed.
- Forms are raised as an exception. This allows the writer to assume
the data is correct the whole way through. However, when there is a
validation exception, it is handled easily.
The proposal can be found here:
http://code.djangoproject.com/wiki/NewManipulators
Here is a sample view using a default CreateManipulator:
def create_poll(request):
try:
m = Poll.CreateManipulator()
poll = m.process(request)
return HttpResponseRedirect('/poll/%d/' % poll.id)
except Form, form:
return render_to_response('poll/create.html', {'form': form})
Feedback and criticism would be greatly appreciated.
--~--~-~--~~~---~--~~
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: Default escaping -- again!
On 7/29/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> We are trying to keep the auto-escaping environment completely within
> the control of the template author.
Thanks.
This is really important as even a plain old HTML file can require
several different kinds of escaping in different parts (e.g inside an
href attribute, in Javascript) and some parts that you never want to
escape (e.g {{ form.field }}). I'd hate to have to be switching back
and forth between the template and the view code each time there's a
little tweak to the UI.
I'm looking forward to seeing how it works in my templates,
Alan.
--
Alan Green
[EMAIL PROTECTED] - http://bright-green.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: Default escaping -- again!
James Bennett wrote: > On 7/28/06, Roland van Laar <[EMAIL PROTECTED]> wrote: > > Would it be better to couple it with the mimetype? A text/plain should > > by default not be excaped. > > What would be *best* is for there to be no magical implied > escaping/unescaping of anything, only explicit escaping/unescaping > based on a template tag. Like this: http://code.djangoproject.com/wiki/AutoEscape%20alternative ? --~--~-~--~~~---~--~~ 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: Flush HttpResponse content
[EMAIL PROTECTED] wrote: > For example, if I wanted to build a malling application, I have to > display the email address each time an email is sent, say every 2 sec. > Processing can be quite long, so I cannot accumulate the output and > return the HttpResponse at the end, because the connection would > timeout. I need to keep the HTTP connection open, and regularly flush > the data. HttpResponse can accept an iterator instead of a string. For your case it can look like this: def send_mails(): for address in addresses: send_mail(address) yield '%s' % address ... def send_mails_view(request): return HttpResponse(send_mails()) This will sent an address each time it is processed right through all the web stack to the client. --~--~-~--~~~---~--~~ 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: django unicode-conversion, beginning
Adrian Holovaty wrote: > On 8/8/06, gabor <[EMAIL PROTECTED]> wrote: >> i think unicodizing django can be done in 4 easily separated steps/parts: >> >> 1. request/response >> 2. templating-system >> 3. database-system >> 4. "overall unicode-conversion". this is mostly about replacing >> bytestrings with u"bla" in the code, and switching __str__ to __unicode__ >> >> my biggest problem currently is, that i do not know how to continue... >> should i just write more and more patches to increase the >> "unicode-coverage" to more parts of django? or maybe a more coordinated >> approach would be better? > > Hey gabor, > > Sorry for the slow response on this -- I'm just now wading through a > couple of weeks' worth of django-users and django-developers messages. > This patch is a great step forward! > > Are you interested in a Subversion branch devoted to Unicoding Django? > Let me know... > (to make sure my original response is not caught up in a spam-filter or such, sending this to the list too) hi, yes, i'm interested :) cannot really promise how long it will take to convert the whole django to unicode, but will try. it's not hard. as i wrote, the changes are simple, it's just that many changes have to be done. thanks, gabor --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Flush HttpResponse content
Hello, I'm trying to write a view in Django that outputs data for a long period of time, and returns it to the client as it gets produced. For example, if I wanted to build a malling application, I have to display the email address each time an email is sent, say every 2 sec. Processing can be quite long, so I cannot accumulate the output and return the HttpResponse at the end, because the connection would timeout. I need to keep the HTTP connection open, and regularly flush the data. If I understood correctly, the way Django works is that the view builds a HttpResponse object with the response content, and only when the HttpResponse is returned is the HTTP request sent to Apache (for the mod_python handler that is). So there is a clear separation between Django's HttpResponse and the server's reponse, which is necessary if we want to have multiple handlers. Is there a way to do this in Django without breaking the abstraction layer? -- Arnaud --~--~-~--~~~---~--~~ 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: Proposal: Search Manipulator
Here is my code for the AutomaticSearchManipulator:
from django.db.models.manipulators import *
from django.db.models.query import Q
class AutomaticSearchManipulator (AutomaticManipulator):
"""
A generic manipulator for searching. It does all the work for
"query by
example" queries.
Typical view usage:
def address_search(request):
Address.add_to_class('SearchManipulator',
AutomaticSearchManipulator)
manipulator = Address.SearchManipulator()
if request.GET:
new_data = request.GET.copy()
manipulator.do_html2python(new_data)
query_set = manipulator.search(new_data)
return render_to_response('address_list.html',
{'object_list': query_set})
else:
errors = new_data = {}
form = forms.FormWrapper(manipulator, new_data, errors)
return render_to_response('address_search.html', {'form':
form})
"""
change = False
SEARCH_TYPES = {
'iexact': '=',
'exclude': '≠',
'istartswith': 'starts with',
'iendswith': 'ends with',
'icontains': 'contains',
'gt': '>',
'gte': '>=',
'lt': '<',
'lte': '<=',
'in': 'one of',
'range': 'range of',
}
def search_types(self):
"""
Generate the search type drop-down widget. Currently doesn't
work,
need to figure out how to adjust the name of the widget to
correspond
with the field.
Meant to be used in forms (added as an extra context) to
allow more
flexible searching.
"""
output = ['' % ()]
str_data = str(data) # normalize to string
for value, display_name in self.SEARCH_TYPES:
selected_html = ''
if str(value) == str_data:
selected_html = ' selected="selected"'
output.append('%s' % \
(escape(value), selected_html, escape
(display_name)))
output.append(' ')
return '\n'.join(output)
def save(self, new_data):
"""
Does nothing. Doesn't make sense to have a save method.
Raise NotImplementedError
"""
raise NotImplementedError
def search(self, new_data, default_search='iexact'):
"""
Search for the object or objects specified by new_data.
"""
where_clause = {}
posted_values = new_data.lists()
for k, v in posted_values:
if len(v) > 1:
where_clause['%s__in' % k] = v
else:
if v[0]:
where_clause['%s__%s' % (k, default_search)] = v[0]
if where_clause:
q = Q(**where_clause)
return self.manager.filter(q)
else:
return self.manager.all()
On Aug 20, 2006, at 2:51 PM, Corey wrote:
>
> I had a need to provide a "Search by example" form, and I thought that
> a new type of manipulator similar to an AddManipulator and
> ChangeManipulator.
>
> I've started the code, and would be happy to submit when I'm done if
> you guys/glas think it Django-ish enough.
>
> The idea is that a view to handle searching could look like:
>
> def address_search(request):
> manipulator = Address.SearchManipulator()
> if request.GET:
> new_data = request.GET.copy()
> manipulator.do_html2python(new_data)
> query_dict = manipulator.search(new_data)
> return render_to_response('address_list.html', {'query_dict':
> query_dict})
> else:
> errors = new_data = {}
>
> form = forms.FormWrapper(manipulator, new_data, errors)
> return render_to_response('address_search.html', {'form': form})
>
> Thanks,
>
> Corey
>
>
> >
--~--~-~--~~~---~--~~
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: XSS comments from PHP Creator
I haven't RTFA - so take this with a grain of salt, but this depends on what you mean by data sanitisation. If you're talking application arguments - then yes, these should be white listed. If however, you're talking about user submitted content, then no. Why? security in web applications is very simple - all you have to do is filter input, and escape output. The problem is working out what filtering and escaping are appropriate. If I'm outputting (x)html then I want to escape things like <, > and &. If however, I'm sending data to, say, email or PDF, or XML, or next weeks format of choice then I want DIFFERENT things escaped. The stored data should be "raw" until it leaves the application and is formatted appropriately for the receiving resource. The application layer should not try to guess this in any brute force manner- anyone who's experienced the sheer *joy* of PHP's magic quotes setting will probably agree with me here! @ Ahmad - mod_security (modsecurity.org) is fantastic, and I highly recommend installing it on all apaches, but filtering content at the webserver level is a sledgehammer approach and should only be done for *really* bad content (e.g. known exploits, spam bots etc) --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 -~--~~~~--~~--~--~---
Re: Safe settings context processor
SmileyChris wrote: > But Ivan, you need to access the STYLE_URL setting. Having access to > settings via SafeSettings could be useful still, right? Not much. Adding couple of needed settings in my own project's context processor (which I already have anyway) is not a big deal. SafeSettings then has some questionable gains bu also some questionable danger: it filters out only settings with 'SECRET' and 'PASSWORD' in its name but there can be settings that should be kept hidden that don't contain these words (and vice versa). To my personal taste this is not enough ground to recommend it as default behavior. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
