On 06:09 pm, jacek99@gmail.com wrote:
Sorry, let me be more clear:
I have a Resource let's say CustomerRestService which is a leaf and handles everything related to '/customer' Then I want a CustomerAddressRestService Resource, which is also a leaf and should handle everything related to '/customer/<customerId>/address'.
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. Why do you think it should be one?
So I need a leaf Resource (i.e. it actually intercepts GET/POST/PUT/DELETE requests to the root '/customer' URL) with a child leaf Resource (which intercepts the GET/POST/PUT/DELETE requests to its root '/customer/<customerId>/address' URL).
Twisted does not really allow for nested leaf resources, but REST is all about nested URL schemes, e.g.
Right. Because "nested leaf resource" is self contradictory.
Customer -> Customer Address Customer -> Customer Phone Customer -> Customer Invoice -> Customer Payment
etc.
Taking CorePost out of the picture and just going back to raw twisted.web, how would you recommend that be done?
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. Jean-Paul