On 06:09 pm, [email protected] 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 _______________________________________________ Twisted-web mailing list [email protected] http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
