I still think traversal-based resources lend themselves to RESTful mappings
better than route-based routines.
GET /notes # get a listting of all notes
POST /notes # create a new note
GET /notes/firstnote# get full information on the "firstnote" note
PUT /notes/firstno
IMO the only thing we need for configuration is a 100% compatible, no extra
features version of Paster that is easier to read and extend, and that runs
on Python 3.2. Call it 'baster'. It will understand Paster entry points,
paste deploy .ini files and be able to 'baster serve'. The templating
feat
Sorry hit enter by mistake without finishing the message.
config.add_view('myproject.views.view2', route_name='page')
does not invoke view2.
I have no idea what I can do to resolve this. I don't even know
whether what I am doing is actually possible.
Any insight will be greatly appreciated.
On Sun, Mar 13, 2011 at 10:33 PM, ZHUO Qiang wrote:
> Hi All,
>
> I'm right now developing a new RESTful web service project using Pyramid.
> The problem is that there seems little info about how to do RESTful route in
> Pyramid (on the contrary there is pretty good support about how to build
> R
Just to add:
config.add_view('myproject.views.view2', route_name='page')
results in a conflict error. (I've done some reading about this in the
documentation)
config.add_view('myproject.views.view2', route_name='page')
On Mar 14, 10:05 pm, AwaisMuzaffar wrote:
> I have the following vie
I have the following view:
def view1(request):
varOne = 'test string'
return render_to_response('page.mak', {'varOne':varOne},
request=request)
Which gets invoked with:
config.add_route('page', '/mypage/', view='myproject.views.view1')
Next, I have another view:
def view2(request)
Thank you everyone for your insightful comments. I would really love to see
code examples (if available) of each of these different solutions you all
are describing. I feel like I'm wading into the deep end of the pool here.
For the record (and for those wondering), I'm using mod_wsgi (daemon mo
On Mon, Mar 14, 2011 at 12:37 PM, danjac...@gmail.com
wrote:
> Migration to Python 3 aside (which has to happen, sooner or later) my
> concern here is that moving to Pyramid 2 so quickly is a bit premature
> given the paint is barely dry on Pyramid 1.
We aren't moving quickly but just capturing p
On Mar 14, 2011, at 4:13 PM, Stephen Lacy wrote:
> Yeah, implicitly breaking HEAD sucks. :)
Using the request_method to explicitly only handle a single request method with
a single view isn't implicit. One explicitly has to set that predicate. As
using a custom predicate for a limited set of
Yeah, implicitly breaking HEAD sucks. :)
Implicitly allowing POST data into GET requests also sucks. :)
Steve
On Mon, Mar 14, 2011 at 12:37 PM, Reed L O'Brien wrote:
> On Mar 14, 2011, at 3:13 PM, Stephen Lacy wrote:
>
> >
> >
> > On Fri, Mar 11, 2011 at 6:16 AM, Graham Dumpleton <
> graham.dump
Personally, I vote against YAML if that means yet another dependency to
Pyramid. INI works fine if you have only or mostly scalar types, json is
ugly and pure Python code should work too, however I believe importing a
config module would bring a lot of grief and dependency on globals, so
it s
On Mar 14, 2011, at 3:13 PM, Stephen Lacy wrote:
>
>
> On Fri, Mar 11, 2011 at 6:16 AM, Graham Dumpleton
> wrote:
>
>
> It would seem to be that a bit more documentation is in order here, and I
> might even suggest that the default behavior for request_method='GET' would
> be to implicitly
Migration to Python 3 aside (which has to happen, sooner or later) my
concern here is that moving to Pyramid 2 so quickly is a bit premature
given the paint is barely dry on Pyramid 1.
Should we not wait until there are some actual projects built with
Pyramid, and we get feedback from real world u
Just my quick 2c:
YAML vs. INI? Just use Python.
Why depend on another component and parser (think: user debugging of
configuration errors with mis-typed config files).
Why fuss over "how does this support lists" and other similar issues?
And, for me, the most important issue is that when I se
On Fri, Mar 11, 2011 at 6:16 AM, Graham Dumpleton <
graham.dumple...@gmail.com> wrote:
>
>
> On Thursday, March 10, 2011 1:44:17 PM UTC-5, Steve Lacy wrote:
>>
>> What's the recommended way to get proper HEAD request support using
>> pyramid + mod_wsgi?
>>
>> Right now, with my "vanilla" mod_wsgi
Just a quick note, I've managed to convince GitHub to grant me the
marrow account name (which was previously parked), so urls starting
with:
https://github.com/pulp/
Should now reference:
https://github.com/marrow/
Thank you,
— Alice.
--
You received this message because you are s
On 2011-03-13 15:58:20 -0400, Mike Orr said:
On Sun, Mar 13, 2011 at 11:08 AM, Alice Bevan–McGregor
wrote:
* marrow.wsgi.objects (WebOb) request/response/exceptions
These are fully WebOb compatible? WebOb has become essentially the only
multi-framework Request/Response, so I dont' want to i
On 2011-03-13 16:32:14 -0400, Mike Orr said:
- marrow.server.http is asynchronous. I don't think we want to make
such a large leap from multithreaded to asynchronous in the default
server. People have just gotten used to making their apps thread-safe;
I don't think we want to force them to mak
On 2011-03-13 16:50:01 -0400, Mike Orr said:
On Sun, Mar 13, 2011 at 1:40 PM, Andrey Popp
<8may...@gmail.com> wrote:
Hello,
On Mar 13, 2011, at 3:29 PM, Mike Orr wrote:
- Replace the INI file with an YAML file?
YAML is not as good as it can be for config file format:
* It has slow parsers.
On Mon, Mar 14, 2011 at 02:03:33PM +0800, Wichert Akkerman wrote:
> On 2011-3-14 01:53, Thomas G. Willis wrote:
> >i like ini files so much better than yaml.
>
> Same for me.
Are we collecting votes here? Because I'd like to add a +1 for INI and
against YAML.
Marius Gedminas
--
This is the Loc
20 matches
Mail list logo
