Extend URL resolver support for HTTP Methods / REST support

2006-09-21 Thread Simon de Haan
Hello everyone, I've posted a patch in trac which will allow the urlresolver to select a view depending on the HTTP method (GET,POST,PUT,DELETE, etc..) Its posted at http://code.djangoproject.com/ticket/2784 My implementation has been hacked together in a few minutes and isn't pretty by any

Re: Re: Ticket #2773: django.views.defaults.server_error should use RequestContext

2006-09-21 Thread James Bennett
On 9/21/06, Afternoon <[EMAIL PROTECTED]> wrote: > At the same time middleware such as the session mechanics are still > invoked, performing complex actions. Why are these safer than the > context processors? In part because it depends on when the exception happens, and in part because middleware

Re: Compacting SQL queries

2006-09-21 Thread Michael Radziej
Malcolm Tredinnick schrieb: > What is the advantage of doing this? The only saving you're making here > is the amount of data you are sending from your client to the database > server. Since that is generally going to be no worse than over a local > network, the difference between, say, 2K and 1.5

Re: Compacting SQL queries

2006-09-21 Thread Eric Walstad
Hawkeye wrote: > === > (100 chars ~ 25% reduction) ... > My second question is... if we can, is there any real value > (specifically for very large sites)? Our site isn't huge, but it's not small, either (~8M records). Network bandwidth between the web and data servers is very near

Re: Compacting SQL queries

2006-09-21 Thread Malcolm Tredinnick
On Thu, 2006-09-21 at 08:09 -0700, Hawkeye wrote: [...] > Or in the general case (without .values(), all entries are requested): > === > SELECT * FROM `app_object` as `a` WHERE (`a`.`id` = 1) > === > (54 chars ~ 60% reduction) This is generally a bad idea, because it relie

Compacting SQL queries

2006-09-21 Thread Hawkeye
Hi all, I'm wondering if there's a way to generate more compact queries in the DB layer. For example, when I have a model: === class Object(models.Model): bar = models.ForeignKey(...) foo = models.CharField(...) something = models.DateTimeField(...) === Objec

Re: Ticket #2773: django.views.defaults.server_error should use RequestContext

2006-09-21 Thread Ivan Sagalaev
Afternoon wrote: > I disagree. For background, I have a context processor which simply > pushes a dictionary of standard items, such as URLBASE for media and > links, to all templates. It's very unlikely that an error will have > occurred which makes this a bad thing to do. Other people may have

Re: single-row database tables for properties

2006-09-21 Thread [EMAIL PROTECTED]
Here's my example then: class Property(models.Model): class Admin: pass showGone = models.BooleanField(default=False) goneGroup = models.CharField(maxlength=100) def save(self): """ save, but set id to 1 """ self.id=1 super(Property, self).save()

Re: single-row database tables for properties

2006-09-21 Thread Ned Batchelder
[EMAIL PROTECTED] wrote: > No you dont need a different table for each property, one table stores > all the properties that you want to collect together. > > The problem with the (name,value) approach is that all the values have > to be the same type, so you cant present some properties as text, s

Re: mod_python's request.META["SERVER_PORT"] small bug

2006-09-21 Thread skink
sure, see: #2782 --~--~-~--~~~---~--~~ 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 [EMAI

Re: single-row database tables for properties

2006-09-21 Thread [EMAIL PROTECTED]
No you dont need a different table for each property, one table stores all the properties that you want to collect together. The problem with the (name,value) approach is that all the values have to be the same type, so you cant present some properties as text, some as boolean, and some as drop-d

Re: mod_python's request.META["SERVER_PORT"] small bug

2006-09-21 Thread Malcolm Tredinnick
On Thu, 2006-09-21 at 00:11 -0700, skink wrote: > Seems I have found small bug in core/handlers/modpython.py. > > Namely request.META["SERVER_PORT"] under apache is always set to 0. > > This is because its set to self._req.server.port in modpython.py line > 88. > > mod_python's docs say > (http

Re: Ticket #2773: django.views.defaults.server_error should use RequestContext

2006-09-21 Thread Michael Radziej
Afternoon wrote: > Just a quick note to say I've added a ticket and patch to modify > django.views.defaults.server_error to use RequestContext instead of > Context, thus making context-processor-generated context available to > 500 pages. This was discussed ago and rejected because building

Re: Ticket #2773: django.views.defaults.server_error should use RequestContext

2006-09-21 Thread Afternoon
> 500 errors are bad; it's bail out time when they happen. I disagree. For background, I have a context processor which simply pushes a dictionary of standard items, such as URLBASE for media and links, to all templates. It's very unlikely that an error will have occurred which makes this a bad

Best website design that could offer you..

2006-09-21 Thread laura
Hi! How's everyone doing? I hope every thing's fine. Anyway, let me introduce myself.. I'm newbie here and you can call me Francine, I'm 21 years old. I work as an SEO Specialist. I optimize websites and let them appear at the top portion of the search engines. I also do website promotion to incre

mod_python's request.META["SERVER_PORT"] small bug

2006-09-21 Thread skink
Seems I have found small bug in core/handlers/modpython.py. Namely request.META["SERVER_PORT"] under apache is always set to 0. This is because its set to self._req.server.port in modpython.py line 88. mod_python's docs say (http://www.modpython.org/live/current/doc-html/pyapi-mpsrv-mem.html#l2