See comments below On Wed, Feb 29, 2012 at 2:45 PM, <[email protected]> wrote:
> On 06:09 pm, [email protected] wrote: > > Well.... my first reaction is that this doesn't make sense. Leaves > don't have leaves. That's what makes them leaves. > > Your CustomerRestService is not a leaf resource. > > it handles GET/POST/PUT/DELETE requests for the Customer entity. If I am coding in raw twisted.web, that means I would need to handle the render_GET, render_POST, etc. in this class. Isn't that what classifies it as a leaf resource (i.e. one that actually handles HTTP requests instead of just passing them down to a child)? > >about nested URL schemes, e.g. > > Right. Because "nested leaf resource" is self contradictory. > Well, not in REST...nested resources under another other is the norm in defining URL schemes in REST apps. Or does the concept of a REST service for an entity simply not map at all to what Twisted Web defines as a Resource? Apart from what I said above, and still not really understanding why you > want this, the implementation of the traversal mechanism is exposed as > `twisted.web.resource.getChildForRequest`. After you stop traversal > with your first "leaf" resource, you can finish it by calling > `getChildForRequest` manually, and then manually rendering the resulting > resource. > > Let me look at that. But it seems counter-intuitive for a typical REST app structure.... Jacek
_______________________________________________ Twisted-web mailing list [email protected] http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
