On Sep 12, 5:06 am, Paul Carduner <paulcardu
...@gmail.com> wrote:
> I heard others and spoke myself about doing some work on piston during
> the djangocon sprints. I haven't gotten around to anything piston
> related yet, but I'm hoping to do a bit tonight and more tomorrow.
Hah, very cool that someone is sprinting on it :-)
> Anything in particular I can contribute too? What hg repositories are
> good to follow on bitbucket?
The canonical repo is jespern/django-piston, and there's a list of
forks/queues in the "descendants" tab. The joestump fork has seen a
lot of action lately, and I've just merged it in. It needs testing!
> I was thinking about working on and/or learning about configurable
> logging and form validation and documentation. I see there is support
> for form validation but I don't understand from the docs how they
> work.
They work in the way that you can decorate a method with @validate
(FormThingie) and it will throw a validation error and never execute
your handler if it fails. It would be nice if you wouldn't have to the
validation twice though, you can look into that, if you want. Possibly/
preferably by adding the form to the kwargs of the function, so you
can access it inside the view.
Logging would be nice, and I've also spoken to Adam (I believe you met
him) about some other stuff you guys can work on. You should talk to
him. Otherwise, I think improving the documentation would be a great
idea.
> Also a quick question: why read/create/update/delete instead of
> GET/POST/PUT/DELETE or get/post/put/delete (a la app engine)?
Semantics, really. It's GET/POST etc. on the protocol layer, but if
you follow CRUD semantics, it's CREATE/READ/UPDATE/DELETE, which it's
called in piston :-)
I'm on #bitbucket on irc.freenode.net, so if you don't want to wait
for my slow email replies, come bug me there.
Jesper
> On Thu, Sep 10, 2009 at 1:19 AM, jespern <jno...@gmail.com> wrote:
> > On Sep 10, 8:04 am, Paul Carduner <paulcardu...@gmail.com> wrote:
> >> I just started playing around with piston tonight after hearing good
> >> things about the talk at djangocon (though I didn't go... shame on
> >> me).
> >> I've encountered something that seems a bit confusing to me? Maybe I
> >> am doing it wrong.
> >> In several of my handlers, I need to fetch an object from the database
> >> based on a url slug and then do some additional processing to build
> >> the result set. I'd like to use get_object_or_404 to do the initial
> >> query, but it seems like piston is interpreting the Http404 exception
> >> that gets raised as a regular internal exception and turns it into a
> >> 500 internal error. I was expecting the Http404 exception to be
> >> caught in the Resource calling the handler and turned into an
> >> rc.NOT_FOUND response.
> >> Is this the intended behavior? And if so, what is the reasoning
> >> behind it?
> > This is a missing feature. We should of course catch Http404's, to let
> > people use the get_object_or_404 shortcut. I'll fix this in my fork
> > later today, which will be the coming 0.2.3 release. I've had good
> > results from people running their testsuite on it, so it should be
> > 100% backwards compatible.
> > Thanks for reporting this!
> > Jesper
> --
> Paul Cardunerhttp://www.carduner.net
