On Tue, Mar 29, 2011 at 4:06 AM, karantan wrote:
> Hi,
>
> So is there any news if pyramid will have anything like "from
> pylons.decorators import validate"? i tried to use formencode but it's
> not so easy to implement in pyramid. i will try formish next and i
> hope i'll have more success with
The @validate decorator was an appallingly bad idea and one of the
most detested features of Pylons. I don't think anyone wants to bring
it back.
On Mar 29, 12:06 pm, karantan wrote:
> Hi,
>
> So is there any news if pyramid will have anything like "from
> pylons.decorators import validate"? i tr
Hi,
So is there any news if pyramid will have anything like "from
pylons.decorators import validate"? i tried to use formencode but it's
not so easy to implement in pyramid. i will try formish next and i
hope i'll have more success with it...
I would also like to say that it is great that you imp
On Mar 9, 2011, at 5:00 AM, ZHUO Qiang wrote:
> Hi,
>
> Since I find the old pylons's way of RESTful HTTP "_method" tunnel very
> handy, I have the following customize predicts to emulate the same effects in
> Pyramid:
>
> # this predicts will using the both real HTTP method and "_method" for
Hi,
Since I find the old pylons's way of RESTful HTTP "_method" tunnel very
handy, I have the following customize predicts to emulate the same effects
in Pyramid:
# this predicts will using the both real HTTP method and "_method" for
prediction. And it will also convert the request.method with
On Fri, 2011-01-21 at 17:18 -0500, Chris McDonough wrote:
> On Fri, 2011-01-21 at 17:10 -0500, Chris McDonough wrote:
> > On Fri, 2011-01-21 at 13:58 -0800, Mike Orr wrote:
>
> > If the problem is distinguishing here, two routes are not necessary
> > here. Just a single route and two views (or ha
On Fri, 2011-01-21 at 17:10 -0500, Chris McDonough wrote:
> On Fri, 2011-01-21 at 13:58 -0800, Mike Orr wrote:
> If the problem is distinguishing here, two routes are not necessary
> here. Just a single route and two views (or handler actions).
>
> config.add_route('thename', '/foo/put', 'thevie
On Fri, 2011-01-21 at 13:58 -0800, Mike Orr wrote:
> On Fri, Jan 21, 2011 at 1:13 PM, Daniel Holth wrote:
> > I think it is very relaxing that my view handles unedited requests. I'm
> > confused about the problem you are having. Since the framework keeps GET
> > requests out, why does the PUT-hand
On Fri, Jan 21, 2011 at 1:13 PM, Daniel Holth wrote:
> I think it is very relaxing that my view handles unedited requests. I'm
> confused about the problem you are having. Since the framework keeps GET
> requests out, why does the PUT-handler have to check request.method at all?
There are two iss
I think it is very relaxing that my view handles unedited requests. I'm
confused about the problem you are having. Since the framework keeps GET
requests out, why does the PUT-handler have to check request.method at all?
--
You received this message because you are subscribed to the Google Grou
On Fri, Jan 21, 2011 at 12:38 PM, Chris McDonough wrote:
> On Fri, 2011-01-21 at 12:30 -0800, Mike Orr wrote:
>> On Fri, Jan 21, 2011 at 12:15 PM, Chris McDonough wrote:
>> >> config.add_view(some_method)
>> >> config.add_view(some_method_PUT, request_method='PUT')
>> >> config.add_view(some_meth
On Fri, 2011-01-21 at 12:30 -0800, Mike Orr wrote:
> On Fri, Jan 21, 2011 at 12:15 PM, Chris McDonough wrote:
> > On Fri, 2011-01-21 at 12:13 -0800, Daniel Holth wrote:
> >> I always setup two view functions, one for GET and one for POST.
> >>
> >> I don't do PUT, but if you want Pyramid lets you
On Fri, Jan 21, 2011 at 11:55 AM, Mike Orr wrote:
> How does Pyramid handle HTTP method tunneling? Where the formal method
> is POST and the actual method is in a '_method' param? it's not really
> a form library issue because you'd want it uniform across all
> libraries. How does Pylons do it?
P
On Fri, 2011-01-21 at 12:20 -0800, Mike Orr wrote:
> It's a tradition in Pylons to use the Atom REST protocol for model
> objects with add/modify/delete forms. I've been half questioning that
> myself because there's little advantage if all the clients are
> interactive web browsers. But regardless
On Fri, Jan 21, 2011 at 12:15 PM, Chris McDonough wrote:
> On Fri, 2011-01-21 at 12:13 -0800, Daniel Holth wrote:
>> I always setup two view functions, one for GET and one for POST.
>>
>> I don't do PUT, but if you want Pyramid lets you condition a view on
>> both the request method and parameters
It's a tradition in Pylons to use the Atom REST protocol for model
objects with add/modify/delete forms. I've been half questioning that
myself because there's little advantage if all the clients are
interactive web browsers. But regardless of whether it's been
oversold, it's the way most Pylons us
On Fri, 2011-01-21 at 12:13 -0800, Daniel Holth wrote:
> I always setup two view functions, one for GET and one for POST.
>
> I don't do PUT, but if you want Pyramid lets you condition a view on
> both the request method and parameters. The second function should
> only be called for a PUT, or a P
I always setup two view functions, one for GET and one for POST.
I don't do PUT, but if you want Pyramid lets you condition a view on both
the request method and parameters. The second function should only be called
for a PUT, or a POST with _method=PUT in the parameters:
def some_method(reques
It doesn't handle it. I need to see credible examples use cases for it,
I think.
Various folks have wanted to add e.g. to a Pyramid form post in my tenure in
#pylons, but it's beyond me why someone would try to be emulating a
"REST client" when using a browser, as the access patterns and expect
How does Pyramid handle HTTP method tunneling? Where the formal method
is POST and the actual method is in a '_method' param? it's not really
a form library issue because you'd want it uniform across all
libraries. How does Pylons do it? Is it in WebOb? Is it something we
need to add?
--
Mike Orr
Hello,
I am very interested in this topic since in my experience form
handling is always a pain.
Did you consider the "flatland" form processing package (http://
discorporate.us/projects/flatland/). I know this is a young project
but I think its a balanced compromise of schema creation, validation
Hello Mike,
On Mon, Jan 17, 2011 at 11:23 AM, Mike Orr wrote:
> So this email is to
> collect feedback for that: what are people using, and what do they
> think makes sense for Pyramid.
>
I'm still using formencode for validation/conversion. I use a custom class
that encapsulates the minimum f
On 2011-1-17 20:23, Mike Orr wrote:
So, for those who've used them, is this true? Are they equivalent to
FormEncode, or are they missing any of FormEncode's functionality?
I have used formencode a lot in a Pylons 0.x context, and I've used a
lot of formish in repoze.bfg/Pyramid contexts. I hav
As part of the Pylons-to-Pyramid howto I'm writing, I need to make
some recommendations for form handling. This covers the sprawling
topic of form generation, validation, error display, usage pattern in
the view, and side topics such as database records,
internationalization, and REST resources.
P
24 matches
Mail list logo
