On Fri, 2006-09-22 at 17:17 +, wes wrote:
> I also prefer using a dispatcher in the view, its simple and flexible,
> and still allows you to use things like the @login_required decorator
> on your base view function.
>
> >I'm using that sort of view now
> >in a couple of places where I'm supp
> How are you accessing the request.PUT and request.DELETE? I would think
> those have to be added to the HttpRequest object before you could use
> them in the view.
Actually, Django doesn't have any specific machinery for handling PUT
and DELETE and even more esoteric ones like PROPGET, but it'l
I also prefer using a dispatcher in the view, its simple and flexible,
and still allows you to use things like the @login_required decorator
on your base view function.
>I'm using that sort of view now
>in a couple of places where I'm supporting POST, PUT, GET and DELETE all
>on the same resource
Since you can judge request method in
view, dispatching the same url with different methods to proper views isn't a
problem.
I did similar dispatching in http://mashup.googlecode.com/svn/trunk/mashup/views.py.
- Original Message -
From:
Simon de Haan
To: django-develop
On 9/22/06, Afternoon <[EMAIL PROTECTED]> wrote:
> James, why are context processors not able to handle exceptions and
> fall back to basic output, i.e. return an empty dictionary?
Your context processor function could, if it wanted, wrap some of its
own possibly problematic code in a try/except
I like your idea! I'll try & put something together this weekend & see how it goes.Why are you prepending handle_ on the functions instead of just having them be get(), post() etc...?Why not put them in a list & check if they exist in that list?allowed_methods = ['get','post','put'...]and thenfor x
Afternoon schrieb:
> Ivan, you're right to note that I can supply my own view. I will do
> that.
>
> James, why are context processors not able to handle exceptions and
> fall back to basic output, i.e. return an empty dictionary?
Hmm, I generally prefer a good traceback instead of getting
miss
I have an alternate suggestion, an expansion of malcomt's idea, rather
than changing the machinery of the current url handlers, and which
should work in your existing code. (note this is untested code, but I
believe it should work, barring any syntactical errors.)
First, we define a RestfulView
Ivan, you're right to note that I can supply my own view. I will do
that.
James, why are context processors not able to handle exceptions and
fall back to basic output, i.e. return an empty dictionary?
I don't mean to waste anyone's time with this, I should have looked
harder for the previous di
Malcolm Tredinnick wrote:
On Fri, 2006-09-22 at 10:20 +0200, Simon de Haan wrote:
Yeah I get it and agree with you.
So your suggestion is to not implement this in the urlpatterns and
introduce it as a dispatcher in the view?
That what works now and it's the an accepted
i renamed this thread, it was "Re: oracle backend constraint
names(_get_sql_for_pending_references)"
Carlo C8E Miron wrote:
> Ciao world_domination_kites,
> On 9/20/06, world_domination_kites <[EMAIL PROTECTED]> wrote:
> > I recon what's required is a special cursor encapsulates all that CLOB
> >
i renamed this thread, it was "Re: oracle backend constraint
names(_get_sql_for_pending_references)"
Carlo C8E Miron wrote:
> Ciao world_domination_kites,
> On 9/20/06, world_domination_kites <[EMAIL PROTECTED]> wrote:
> > I recon what's required is a special cursor encapsulates all that CLOB
> >
Hi,
I have created a little HTML form generator framework for Django. The
framework (django.contrib package) and an example application are
available at http://ohtis.net/formgenerator.tar.gz
I hope this would become (un)official part of Django distribution.
Please give some feedback.
Below some
On Fri, 2006-09-22 at 10:20 +0200, Simon de Haan wrote:
> Yeah I get it and agree with you.
>
>
> So your suggestion is to not implement this in the urlpatterns and
> introduce it as a dispatcher in the view?
That what works now and it's the an accepted Python idiom for simulating
a switch stat
Yeah I get it and agree with you.So your suggestion is to not implement this in the urlpatterns and introduce it as a dispatcher in the view? Met vriendelijke groet,Simon de HaanEight Media[EMAIL PROTECTED]+31 (0)26 38 42 440 On Sep 22, 2006, at 10:01 AM, Malcolm Tredinnick wrote:On Fri, 2006-09-22
On 9/22/06, Simon de Haan <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> Fair enough - you're free to discuss your ideas.
>
> For this thread, I'd prefer sticking to ideas on whether to implement the
> HTTP methods in the urlresolver and if the idea is any good - how this could
> be done.
>
> Right now th
On Fri, 2006-09-22 at 08:51 +0200, Simon de Haan wrote:
> 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 implementatio
Hi,Fair enough - you're free to discuss your ideas.For this thread, I'd prefer sticking to ideas on whether to implement the HTTP methods in the urlresolver and if the idea is any good - how this could be done.Right now the urlresolver works with strings or functions, not dictionaries. Adding dicti
On Fri, 2006-09-22 at 15:18 +0800, limodou wrote:
> On 9/22/06, Ahmad Alhashemi <[EMAIL PROTECTED]> wrote:
> >
> > +1 on the idea.
> >
> > It is starting to make less and less sense to treat a GET and a POST
> > the same way just because they use the same URL.
> >
> > I don't think the implementat
On Fri, 2006-09-22 at 09:15 +0200, Simon de Haan wrote:
> Malcom,
>
>
> In the ticket you mentioned that it can be pretty easily done via a
> view dispatcher - could you elaborate more on this? I'd be interested
> as to how one would go about doing this.
The URL dispatcher doesn't change from w
On 9/22/06, Simon de Haan <[EMAIL PROTECTED]> wrote:
> Hi Limodou,
>
> Not sure about your decorator idea, personally I think it goes beyond the
> scope of the url's in general and django's urlpatterns and is quite view
> specific.
>
> Any ideas about implementing the GET/POST/PUT/DELETE etc..?
>
Hi Limodou,Not sure about your decorator idea, personally I think it goes beyond the scope of the url's in general and django's urlpatterns and is quite view specific.Any ideas about implementing the GET/POST/PUT/DELETE etc..? Met vriendelijke groet,Simon de HaanEight Media[EMAIL PROTECTED]+31 (0)2
On 9/22/06, Ahmad Alhashemi <[EMAIL PROTECTED]> wrote:
>
> +1 on the idea.
>
> It is starting to make less and less sense to treat a GET and a POST
> the same way just because they use the same URL.
>
> I don't think the implementation is ugly, either. I can't see how it
> can be made cleaner, exc
Malcom,In the ticket you mentioned that it can be pretty easily done via a view dispatcher - could you elaborate more on this? I'd be interested as to how one would go about doing this. Kind regards,Simon de HaanEight Media[EMAIL PROTECTED]+31 (0)26 38 42 440 On Sep 22, 2006, at 9:04 AM, Ahmad Alha
+1 on the idea.
It is starting to make less and less sense to treat a GET and a POST
the same way just because they use the same URL.
I don't think the implementation is ugly, either. I can't see how it
can be made cleaner, except for using constants instead of strings for
GET, POST, ..etc. But
25 matches
Mail list logo
